Request: Hard Coded Subtitles

Hi,
Is it possible to add support for .sup files when hard coding. Currently only SRT, ASS and VobSub are supported.
Hopefully it wont me to hard as both .sup and VobSub are both image based subtitles.
Thanks for the great work.

I don't think there is a filter for this.

VapourSynth already comes with such a plugin. (sub.ImageFile())
http://www.vapoursynth.com/doc/plugins/subtext.html
Until Stax has this properly integrated you should be able to use the following workaround:

Open file with a VapourSynth source filter
Tools > Advanced > Hard Coded Subtitle and select the .sup or .idx file
Click "Filters">"Edit" and there
change e.g. "TextSubMod("C:\movies\subtitle_file.sup")" to "clip = core.sub.ImageFile(clip, file="C:/movies/subtitle_file.sup")"
(note the change of backwards to forwards slashes)
Encode like usually

Next test build supports srt, ass, idx and sup using vapoursynth and Tools > Advanced > Hard Coded Subtitle
@sneaker
Thanks for the help with it.


Force builds to use main

Docs Build status updates of commit acaa58d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Instructions in Readme have a significant typo for Motion-Lora

In Readme instructions:
Optionally, you can use Motion LoRAs to influence movement of v2-based motion models like mm_sd_v15_v2.
[Google Drive](https://drive.google.com/drive/folders/1EqLC65eR1-W-sGD0Im7fkED6c8GkiNFI?usp=sharing) | [HuggingFace](https://huggingface.co/guoyww/animatediff) | [CivitAI](https://civitai.com/models/108836/animatediff-motion-modules)

Place Motion LoRAs in ComfyUI/custom_nodes/ComfyUI-AnimateDiff-Evolved/motion-lora. They can be renamed if you want.

ComfyUI-AnimateDiff-Evolved/motion-lora
This path is not correct, it is actually ComfyUI-AnimateDiff-Evolved/motion_lora
Underscore, not dash.

I'd say calling it significant is a bit overblowing it, since the motion_lora folder is included in the files when the repo is pulled and can be found easily, but thanks for the heads up, I'll fix the readme the next time I'm merging something into main branch!

Fixed now, closing issue.


Syntax colors removed after VSC update...

Issue Type: Bug
I updated visual studio code, and now my syntax colors are gone...yet the theme's background color remains, just white text now
VS Code version: Code 1.30.1 (dea8705087adb1b5e5ae1d9123278e178656186a, 2018-12-18T18:12:07.165Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz (8 x 1896)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
7.86GB (3.40GB free)

Process Argv
-n

Screen Reader
no

VM
0%

Extensions (13)

Extension
Author (truncated)
Version

vscode-eslint
dba
1.7.2

githistory
don
0.4.4

gitlens
eam
9.2.4

prettier-vscode
esb
1.7.3

auto-close-tag
for
0.5.6

beautify
Hoo
1.4.7

team
ms-
1.144.1

debugger-for-chrome
msj
4.11.1

color-highlight
nau
2.3.0

vetur
oct
0.14.4

LiveServer
rit
5.3.1

trailing-spaces
sha
0.2.11

vuetify-vscode
vue
0.2.0

(2 theme extensions excluded)

@laurengranada

and now my syntax colors are gone...yet the theme's background color remains, just white text now

For what language? Do you see the same behaviour for other languages?
Please provide detailed steps so that we can reproduce the problem.

The language specified is 'Vue'. I just changed it to others to test out the syntax coloring, and it is not an issue for them...seems to be only happening in Vue.
As for steps...I'm not sure what to list out...I literally did nothing but opt in for the VSC update hahah

Coloring for vue is provided by the veture extension, please report the issue against this extension.

Okay, thank you for your help!


Error in processing task tags

Bug description
Tags written with non-Latin characters are not removed from the header.
And they are duplicated every time a task is moved or changed.
Steps to reproduce the behavior:

Create a task with a tag Тест
Move the task or change the duration
See error

Expected behavior
The header must be without tags and they shouldn't be duplicated
Version:

Obsidian Desktop - 1.4.13
Time Ruler - 1.3.3

Additional context
The problem is in the regular expression TAG_SEARCH = /#[\w-\/]+ */g which does not take non-Latin characters into account.
It can be replaced by TAG_SEARCH = /#[\p{Letter}\/\d_-]+/gu
The variant is quite simple, but it fits better to what is described in obsidian documentation.
https://help.obsidian.md/Editing+and+formatting/Tags#Tag+format

Changed the regex in upcoming release!


allow customization of suggest widget height

Currently, the (maximal) number of items shown in the completion (quick-suggest) widget is 12:
https://github.com/microsoft/vscode/blob/7ba867b19ad4efa6012df64a914f237021d33bcb/src/vs/editor/contrib/suggest/browser/suggestWidget.ts#L900
Could that number be made configurable, for users who would prefer to show fewer (or more) items in the completion list by default? Perhaps as an editor option; e.g. EditorOption.suggestWidgetMaximumItemsToDisplay or something slightly less verbose?

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Show Lighthouse CI results

Pull Request Test Coverage Report for Build 937

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 100.0%

Totals

Change from base Build 936:
0.0%

Covered Lines:
41

Relevant Lines:
41

💛  - Coveralls

The PR still has issue to upload the Lighthouse CI results as GitHub status checks. Asked at https://stackoverflow.com/questions/59026591/lighthouse-ci-must-provide-token-for-lhci-target

Fixed by https://github.com/Hongbo-Miao/hongbomiao.com/pull/378


[Bug]: Validation of Column during Inline editing inside a Table widget does not work properly

Is there an existing issue for this?

[X] I have searched the existing issues

Description
I am using Inline Editing inside a Table and I wanted to do some validations during column edits.
I am using currentRow.columnName as the input value to validate. I realised that even if the validation fails while I am typing the value the first time, I am still able to click outside the cell and click on Save.
Only when I edit it again does the error message pop up.
I tried the same when adding a new row and this issue does not occur. I see the error message while typing itself if the validation fails.
Steps To Reproduce

Introduce a Table widget and connect to some data
Make one of the columns editable
Inside the column, give an expression for the validation field. Something as simple as
{{currentRow..length > 3}}
Now edit that particular column of any row in the table.
Purposefully type in a value that fails the validation you have set

Notice that on the first time you edit the row with the wrong value, no error message shows up and you are able to click outside the cell to go ahead and click Save button.
Public Sample App
No response
Environment
Production
Severity
Medium (Frustrating UX)
Issue video log
https://www.loom.com/share/abc1cb8ad63e449295f644c8e8901411?sid=35c6422c-9b93-4363-841a-fdf7df3d6f78
Version
Cloud/Self Hosted 1.26

@tomjose92
This isn't working because currentRow property that is available in autocomplete always points to unedited values. We also have another argument: editedValue available that you can use to validate upon.
Let me know if this works out as a solution for you or if you have any more questions.

Closing this, based on above comment. @harshilp24 to ensure that our documentation is updated with required information.


Need help running JIRA collector

Hi,
I have been trying to get the JIRA connector to work but I can't figure out why I get a 401 error.
Error:  **RestClientException{statusCode=Optional.of(401), errorCollections=[]} **
I verified the URL and Id/Password being pasted are correct in the browser. (FYI I am using the cloud versions of JIRA)
Can you give me a hint/pointer on how to debug this?
public List<BasicProject> getJiraTeams() {
	Iterable<BasicProject> jiraRawRs = null;
	List<BasicProject> issues = new ArrayList<BasicProject>();
	if (client != null) {
		Promise<Iterable<BasicProject>> promisedRs = client.getProjectClient().getAllProjects();
		try {

//this is where i fail with 401 error
jiraRawRs = promisedRs.claim();
			if (jiraRawRs != null) {
				issues = Lists.newArrayList(jiraRawRs);
			} else {
				issues = new ArrayList<BasicProject>();
			}
		} catch (Exception e) {
			issues = new ArrayList<BasicProject>();
			LOGGER.warn("No result was available from Jira unexpectedly - defaulting to blank response. The reason for this fault is the following:"
					+ e.getCause());
		}

Using the clear text password for api key or the actual ali key
Regards,
Keyur
On Feb 10, 2016, at 7:25 PM, Jim Zucker <notifications<EMAIL_ADDRESS>wrote:
Hi,
I have been trying to get the JIRA connector to work but I can't figure out why I get a 401 error.
Error: *RestClientException{statusCode=Optional.of(401), errorCollections=[]} *
I verified the URL and Id/Password being pasted are correct in the browser. (FYI I am using the cloud versions of JIRA)
Can you give me a hint/pointer on how to debug this?
public List getJiraTeams() {
Iterable jiraRawRs = null;
List issues = new ArrayList();
if (client != null) {
--> Promise> promisedRs = client.getProjectClient().getAllProjects();
try {
jiraRawRs = promisedRs.claim();
if (jiraRawRs != null) {
issues = Lists.newArrayList(jiraRawRs);
} else {
issues = new ArrayList();
}
} catch (Exception e) {
issues = new ArrayList();
LOGGER.warn("No result was available from Jira unexpectedly - defaulting to blank response. The reason for this fault is the following:"

e.getCause());
}

—
Reply to this email directly or view it on GitHubhttps://github.com/capitalone/Hygieia/issues/326.

Hmm, I am not sure where to specify the api key, here is my properties file from the test instance of JIRA I created.. the login is jim:password
Sorry to be dense, can you give me the step by step to get this up and running?
➜  Hygieia git:(java18) ✗ cat /tmp/hygieia-jira-feature-collector.properties
#Database Name
database=dashboard
#Database HostName - default is localhost
dbhost=<IP_ADDRESS>
#Database Port - default is 27017
dbport=27017
#Database Username - default is blank
dbusername=db
#Database Password - default is blank
dbpassword=dbpass
#Collector schedule (required)
feature.cron=0 * * * * *
#Page size for data calls (Jira maxes at 1000)
feature.pageSize=1000
#In-built folder housing prepared REST queries (required)
feature.queryFolder=jiraapi-queries
#Jira API Query file names (String template requires the files to have .st extension) (required)
feature.storyQuery=story
feature.epicQuery=epic
feature.projectQuery=projectinfo
feature.memberQuery=memberinfo
feature.sprintQuery=sprintinfo
feature.teamQuery=teaminfo
feature.trendingQuery=trendinginfo
#Jira Connection Details
feature.jiraProxyUrl=
feature.jiraProxyPort=
Trending Query:  Number of days in a sprint (not-required)
feature.sprintDays=60
Trending Query:  Length of sprint week (not-required)
feature.sprintEndPrior=7
#Scheduled Job prior minutes to recover data created during execution time (usually, 2 minutes is enough)
feature.scheduledPriorMin=2
#Delta change date that modulates the collector item task - should be about as far back as possible, in ISO format (required)
feature.deltaCollectorItemStartDate=2008-01-01T00:00:00.000000
#Jira Connection Details
feature.jiraBaseUrl=http://<IP_ADDRESS>:9200/
feature.jiraQueryEndpoint=rest/api/2/
#64-bit encoded credentials with the pattern username:password
#on a mac you con create them with : echo "username:password" | base64
#reference:  https://www.base64decode.org/
feature.jiraCredentials=amltOnBhc3N3b3JkCg==
#OAuth2.0 token credentials (currently not supported in this version)
feature.jiraOauthAuthtoken=sdfghjkl==
feature.jiraOauthRefreshtoken=sdfagheh==
feature.jiraOauthRedirecturi=uri.this.is.test:uri
feature.jiraOauthExpiretime=234567890987
#Start dates from which to begin collector data, if no other data is present - usually, a month back is appropriate (required)
feature.deltaStartDate=2015-03-01T00:00:00.000000
feature.masterStartDate=2008-01-01T00:00:00.000000
In Jira, general IssueType IDs are associated to various "issue"
attributes. However, there is one attribute which this collector's
queries rely on that change between different instantiations of Jira.
Please provide a numerical ID reference to your instance's IssueType for
the lowest level of Issues (e.g., "user story") specific to your Jira
instance.  Note:  You can retrieve your instance's IssueType ID
listings via the following URI:  https://[your-jira-domain-name]/rest/api/2/issuetype/
feature.jiraIssueTypeId=7
In Jira, your instance will have its own custom field created for "sprint" or "timebox" details,
which includes a list of information.  This field allows you to specify that data field for your
instance of Jira. Note: You can retrieve your instance's sprint data field name
via the following URI, and look for a package name com.atlassian.greenhopper.service.sprint.Sprint;
your custom field name describes the values in this field:
https://[your-jira-domain-name]/rest/api/2/issue/[some-issue-name]
feature.jiraSprintDataFieldName=customfield_10007
In Jira, your instance will have its own custom field created for "super story" or "epic" back-end ID,
which includes a list of information.  This field allows you to specify that data field for your instance
of Jira.  Note:  You can retrieve your instance's epic ID field name via the following URI where your
queried user story issue has a super issue (e.g., epic) tied to it; your custom field name describes the
epic value you expect to see, and is the only field that does this for a given issue:
https://[your-jira-domain-name]/rest/api/2/issue/[some-issue-name]
feature.jiraEpicIdFieldName=customfield_10400

Sure will check in few and get back
Regards,
Keyur
On Feb 10, 2016, at 9:18 PM, Jim Zucker <notifications<EMAIL_ADDRESS>wrote:
Hmm, I am not sure where to specify the api key, here is my properties file from the test instance of JIRA I created.. the login is jim:password
Sorry to be dense, can you give me the step by step to get this up and running?
➜ Hygieia git:(java18) ✗ cat /tmp/hygieia-jira-feature-collector.properties
#Database Name
database=dashboard
#Database HostName - default is localhost
dbhost=<IP_ADDRESS>
#Database Port - default is 27017
dbport=27017
#Database Username - default is blank
dbusername=db
#Database Password - default is blank
dbpassword=dbpass
#Collector schedule (required)
feature.cron=0 * * * * *
#Page size for data calls (Jira maxes at 1000)
feature.pageSize=1000
#In-built folder housing prepared REST queries (required)
feature.queryFolder=jiraapi-queries
#Jira API Query file names (String template requires the files to have .st extension) (required)
feature.storyQuery=story
feature.epicQuery=epic
feature.projectQuery=projectinfo
feature.memberQuery=memberinfo
feature.sprintQuery=sprintinfo
feature.teamQuery=teaminfo
feature.trendingQuery=trendinginfo
#Jira Connection Details
feature.jiraProxyUrl=
feature.jiraProxyPort=
Trending Query: Number of days in a sprint (not-required)
feature.sprintDays=60
Trending Query: Length of sprint week (not-required)
feature.sprintEndPrior=7
#Scheduled Job prior minutes to recover data created during execution time (usually, 2 minutes is enough)
feature.scheduledPriorMin=2
#Delta change date that modulates the collector item task - should be about as far back as possible, in ISO format (required)
feature.deltaCollectorItemStartDate=2008-01-01T00:00:00.000000
#Jira Connection Details
feature.jiraBaseUrl=http://<IP_ADDRESS>:9200/
feature.jiraQueryEndpoint=rest/api/2/
#64https://github.com/capitalone/Hygieia/pull/64-bit encoded credentials with the pattern username:password
#on a mac you con create them with : echo "username:password" | base64
#reference: https://www.base64decode.org/
feature.jiraCredentials=amltOnBhc3N3b3JkCg==
#OAuth2.0 token credentials (currently not supported in this version)
feature.jiraOauthAuthtoken=sdfghjkl==
feature.jiraOauthRefreshtoken=sdfagheh==
feature.jiraOauthRedirecturi=uri.this.is.test:uri
feature.jiraOauthExpiretime=234567890987
#Start dates from which to begin collector data, if no other data is present - usually, a month back is appropriate (required)
feature.deltaStartDate=2015-03-01T00:00:00.000000
feature.masterStartDate=2008-01-01T00:00:00.000000
In Jira, general IssueType IDs are associated to various "issue"
attributes. However, there is one attribute which this collector's
queries rely on that change between different instantiations of Jira.
Please provide a numerical ID reference to your instance's IssueType for
the lowest level of Issues (e.g., "user story") specific to your Jira
instance. Note: You can retrieve your instance's IssueType ID
listings via the following URI: https://[your-jira-domain-name]/rest/api/2/issuetype/
feature.jiraIssueTypeId=7
In Jira, your instance will have its own custom field created for "sprint" or "timebox" details,
which includes a list of information. This field allows you to specify that data field for your
instance of Jira. Note: You can retrieve your instance's sprint data field name
via the following URI, and look for a package name com.atlassian.greenhopper.service.sprint.Sprint;
your custom field name describes the values in this field:
https://[your-jira-domain-name]/rest/api/2/issue/[some-issue-name]
feature.jiraSprintDataFieldName=customfield_10007
In Jira, your instance will have its own custom field created for "super story" or "epic" back-end ID,
which includes a list of information. This field allows you to specify that data field for your instance
of Jira. Note: You can retrieve your instance's epic ID field name via the following URI where your
queried user story issue has a super issue (e.g., epic) tied to it; your custom field name describes the
epic value you expect to see, and is the only field that does this for a given issue:
https://[your-jira-domain-name]/rest/api/2/issue/[some-issue-name]
feature.jiraEpicIdFieldName=customfield_10400
—
Reply to this email directly or view it on GitHubhttps://github.com/capitalone/Hygieia/issues/326#issuecomment-182684049.

@softwareklinic - any update?

HI, can I get some help wth this?    I have not been able to get JIRA to work.
Here are the current details:

This is how I created JIRA:
docker create --restart=no --name "jira-server"  --publish "9200:8080" --env "CATALINA_OPTS= -Xms256m -Xmx512m" cptactionhank/atlassian-jira-software:latest

I updated my config file based on the log from the lira instance:
feature.jiraIssueTypeId=10001
feature.jiraSprintDataFieldName=customfield_10005
feature.jiraEpicIdFieldName=customfield_10003

This is what I get in my log of the Hygiena collector
2016-03-16 05:17:00,001 INFO  c.c.d.collector.CollectorTask - Running Collector: Jira
2016-03-16 05:17:00,015 INFO  c.c.d.collector.FeatureCollectorTask - Starting Feature collection...
2016-03-16 05:17:00,026 INFO  c.c.d.c.team.TeamDataClientSetupImpl - Beginning collection of team data at Wed Mar 16 05:17:00 UTC 2016
2016-03-16 05:17:00,062 WARN  c.c.d.d.jira.JiraDataFactoryImpl - No result was available from Jira unexpectedly - defaulting to blank response. The reason for this fault is the following:RestClientException{statusCode=Optional.of(401), errorCollections=[]}
2016-03-16 05:17:00,062 ERROR c.c.d.c.team.TeamDataClientSetupImpl - The response from Jira was blank or non existant - please check your property configurations
2016-03-16 05:17:00,065 INFO  c.c.d.c.team.TeamDataClientSetupImpl - Process took :0.039186197 seconds to update
2016-03-16 05:17:00,069 INFO  c.c.d.c.p.ProjectDataClientSetupImpl - Beginning collection of project data at Wed Mar 16 05:17:00 UTC 2016
2016-03-16 05:17:00,099 WARN  c.c.d.d.jira.JiraDataFactoryImpl - No result was available from Jira unexpectedly - defaulting to blank response. The reason for this fault is the following:RestClientException{statusCode=Optional.of(401), errorCollections=[]}
2016-03-16 05:17:00,099 ERROR c.c.d.c.p.ProjectDataClientSetupImpl - The response from Jira was blank or non existant - please check your property configurations
2016-03-16 05:17:00,102 INFO  c.c.d.c.p.ProjectDataClientSetupImpl - Process took :0.032059929 seconds to update
2016-03-16 05:17:00,107 INFO  c.c.d.c.s.FeatureDataClientSetupImpl - Beginning collection of feature data at Wed Mar 16 05:17:00 UTC 2016
2016-03-16 05:17:00,134 WARN  c.c.d.d.jira.JiraDataFactoryImpl - No result was available from Jira unexpectedly - defaulting to blank response. The reason for this fault is the following:RestClientException{statusCode=Optional.of(401), errorCollections=[]}
2016-03-16 05:17:00,136 INFO  c.c.d.c.s.FeatureDataClientSetupImpl - Process took :0.028106076 seconds to update
2016-03-16 05:17:00,136 INFO  c.c.d.collector.FeatureCollectorTask - Feature Data Collection Finished

@amp5208 can you look at this?

@jimzucker , Thank you for reaching out regarding your Jira collector question.  Currently, the implementation of JiraFeatureCollector only accepts a base64-encoded basic authentication string in the following format:  username:password.  This should be entered at the following property:  feature.jiraCredentials=dXNlcm5hbWU6cGFzc3dvcmQK
Currently, Jira authentication tokens are not accepted.  Please let me know if you have any additional questions.

@amp5208 i am using that format and i login but have not been able to figure out how to get this to work. I think upu are saying something is wrong with my properties?

Yes:  You need to update your property files to be more like what is described at this current/open issue:  https://github.com/capitalone/Hygieia/issues/276#issuecomment-195399194

@jimzucker , please let me know if you have resolved your issue.

@amp5208  yes I am still having an issue, I will document tomorrow exactly where it is occurring.

@jimzucker , please provide details on your connectivity issue.

Ran into same issue.. Please advise if any progress...

@tonyvilliams , Sorry to hear you are also having this issue.. @jimzucker or @tonyvilliams :  Just to validate, are you able to run the collectors without using Docker? 😕   e.g.:
java -jar jira-feature-collector.jar --spring.config.name=jira-feature-collector --spring.config.location=$PROPERTY_PATH/jira-feature-collector.properties

If you have already validated the following, I start to think this is related to Docker:

Jira credentials are accurate and have permissions to read from all projects
Jira implementation is within a non-restricted region to your Hygieia implementation
Jira public certificate has been added to the Java keystore
The following properties have been configured based on your Jira implementation:

feature.jiraIssueTypeId=Story
feature.jiraSprintDataFieldName=customfield_10000
feature.jiraEpicIdFieldName=customfield_10001

@amp5208 I am testing now in Eclipse, so I think that takes docker out of the picture.  Reviewing today, it looks like my base64 creation of my id and password is adding a '\n' !  I am going to add a bit of code to trim this to make it more resilient..

@jimzucker , Thank you for discovering this:  And also thank you in advance for the contribution 👍 !  @tabladrum :  Please review @jimzucker's contribution once it comes it; I expect a one or two line change for the string trimming.
@jimzucker :  Other than this, have we answered your configuration question?  Can this issue be closed after your impending code contribution?

@amp5208 lets keep this open until I get the darn thing running..

@amp5208 the /n was a problem but I fixed that and I still get a 401 error, line 249 gets the exceptions, any hints on how to debug this?

hmm... that line of code is resolving your authorization header and request body against Jira's API using the Jira SDK, "claiming" the response, treating it almost like a promise.  The only thing that would cause an HTTP 401: Unauthorized response here would be if your credentials are still not being mapped properly.  Have you tried debugging that client variable to expose your message header information?
I believe the problem is how you are establishing your authentication (i.e., what is being transformed and read from your property config), or your Jira implementation does not allow basic authentication (username:password).  Have you verified your Jira authentication capabilities with your Jira admin?

@amp5208 I stepped into the factory.createWithBasicHttpAuthentication to verify my credentials are OK and the URL is the correct https url..  I think I need a way to verify credentials are OK in the contractor JiraDataFactoryImpl so that we can give a clear error at that time.  I dont know the JIRA apis, do you have a suggestion ?

@amp5208 I saw a thread about installing the JIRA cert in the java keystore, that is what I think is wrong, researching it now...

@amp5208 no luck, I put this code in the constructor to ensure ids are correct, I think it has to do with certs or something, I haven't been able to figure it out yet.. any pointers?
jiraServerUri = new URI("https://stratengllc.atlassian.net");
client = factory.createWithBasicHttpAuthentication(jiraServerUri, "xxxx", "xxx");

Not including the Jira certificate would cause problems, but not this one; I would expect it to throw x509 or PKIX Certificate errors at the Java runtime level.  You will need that installed to your Java keystore regardless, however.
Just to check my theory, can you try and cURL and authenticated Jira API request to your Jira implementation from your computer?  I believe that your command should ultimately look like this:
# 1) This will give the HTTP code response back; it will not return the actual message:
curl --cacert /path/to/your/jira/cert.pem -I -X GET --header "Content-Type: application/json"<EMAIL_ADDRESS>
# You may need to include the following parameter flag if your Jira certificate is signed using TLS:
--tlsv1

# 2) Then, try and run this version of the cURL command; let me know which one worked and which one did not:
curl --cacert /path/to/your/jira/cert.pem -I -X GET --header "Authorization: Basic [base64encoded_user:pass]" --header "Content-Type: application/json" https://stratengllc.atlassian.net/rest/api/2/issue/VALIDSTORY-12

# Note:  You may also have to included your proxy authorization header explicitly if behind an auth-proxy.  Here is the parameter syntax to add to the above calls:
--header "Proxy-Authorization: Basic [base64encoded_user:pass]"

It is worth mentioning that I also had trouble authenticating using the second option which uses an explicit authorization header.  The issue was related to Mac's implementation of base64, which seems to add something invisible to the ASCII result.  I would suggest re-validating your base64 not use the base64 encoder on Mac.
If that gets denied for the same HTTP 401 error you were seeing in Hygieia, this is a large problem of your implementation of Jira not allowing for basic authentication.  You would ultimately have 2 options at that point:  1) Contact your Jira admin and ask them to enable nosso option of authentication; 2) Update the JiraFeatureCollector to use token-based authentication (token or OAuth2.0).  The latter may be the only option.  Please let me know how this goes for you.

Thanks this strategy worked.  The real issue was I was passing emailaddress:password, seems the API requires you use the real userid, email does not work!
I will update the file with a good error message and submit it…
On May 19, 2016, at 9:36 AM, Arnold Pelka <notifications<EMAIL_ADDRESS>wrote:
Not including the Jira certificate would cause problems, but not this one; I would expect it to throw x509 or PKIX Certificate errors at the Java runtime level. You will need that installed to your Java keystore regardless, however.
Just to check my theory, can you try and cURL and authenticated Jira API request to your Jira implementation from your computer? I believe that your command should ultimately look like this:
1) This will give the HTTP code response back; it will not return the actual message:
curl --cacert /path/to/your/jira/cert.pem -I -X GET --header "Content-Type: application/json" https://$JIRA_USER:$JIRA_PASS@stratengllc.atlassian.net/rest/api/2/issue/VALIDSTORY-12http://stratengllc.atlassian.net/rest/api/2/issue/VALIDSTORY-12
You may need to include the following parameter flag if your Jira certificate is signed using TLS:
--tlsv1
2) Then, try and run this version of the cURL command; let me know which one worked and which one did not:
curl --cacert /path/to/your/jira/cert.pem -I -X GET --header "Authorization: Basic [base64encoded_user:pass]" --header "Content-Type: application/json" https://stratengllc.atlassian.net/rest/api/2/issue/VALIDSTORY-12
Note:  You may also have to included your proxy authorization header explicitly if behind an auth-proxy.  Here is the parameter syntax to add to the above calls:
--header "Proxy-Authorization: Basic [base64encoded_user:pass]"
It is worth mentioning that I also had trouble authenticating using the second option which uses an explicit authorization header. The issue was related to Mac's implementation of base64, which seems to add something invisible to the ASCII result. I would suggest re-validating your base64 not use the base64 encoder on Mac.
If that gets denied for the same HTTP 401 error you were seeing in Hygieia, this is a large problem of your implementation of Jira not allowing for basic authentication. You would ultimately have 2 options at that point: 1) Contact your Jira admin and ask them to enable nosso option of authentication; 2) Update the JiraFeatureCollector to use token-based authentication (token or OAuth2.0). The latter may be the only option. Please let me know how this goes for you.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/capitalone/Hygieia/issues/326#issuecomment-220381172

see pull request #581

Reviewing PR now.  Thank you for your patience and contribution!!

For those that come here after the merged fix is implemented, it is important to note that the "ghost" \n return carriage that is included in a base64 encoded string on a Mac is avoidable easily by using the Mac implementation of echo correctly.  Instead of the following command:
echo username:password | base64

... Use this command:
echo -n username:password | base64

The -n option explicitly tells the Mac implementation of echo to not print the trailing new line character.

Hi I am getting below error while trying to get projects data:
Jira Api Plugin : 3.0.0
Jira version:  7.3
The issue might be due to missing value like Url or Description of a project but is there any fix for this or workaround?It would be great if you can help with this.
RestClientException{statusCode=Optional.absent(), errorCollections=[]}
com.atlassian.jira.rest.client.internal.async.DelegatingPromise.claim(DelegatingPromise.java:47)
com.capitalone.dashboard.client.DefaultJiraClient.getProjects(DefaultJiraClient.java:152)
com.capitalone.dashboard.client.project.ProjectDataClientImpl.updateProjectInformation(ProjectDataClientImpl.java:58)
com.capitalone.dashboard.collector.FeatureCollectorTask.collect(FeatureCollectorTask.java:113)
com.capitalone.dashboard.collector.FeatureCollectorTask.collect(FeatureCollectorTask.java:28)
com.capitalone.dashboard.collector.CollectorTask.run(CollectorTask.java:63)
org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
org.springframework.scheduling.concurrent.ReschedulingRunnable.run(ReschedulingRunnable.java:81)
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)


--json for handlr list

It would be useful to have a --json switch for handlr list command, just like on get and mime.
Current (tabular) output is so stripped down to fit columns it's not very useful.

I agree, it would be useful. I'll add it when I have the time.
I'll also see what I can do about the table output.

Table output could fit the terminal size, it seems to have a constant width no matter the terminal size right now.

Sorry for forgetting about this for like a month. handlr list now has support for --json. I also made the tabular output a bit more useful.


Add password change validation to Validation documentation

Hi everyone,
There isn't much of a concencus online on how to use Bootstrap validation to compare two new password fields (new password, retype new password).
I think that this type of form is so ubiquitous now that an example should be mentioned in the documentation.
I propose showing a form with three fields - Old Password, New Password, Retype New Password.
The example could then show how comparison/validation of the New Passwords should be handled.
Thanks for condsidering!

Hi am I am new to the open-source side of Coding I have heard of Bootstrap a million Times and now I want to contribute to this project , It would be really helpful if you could help me in getting this issue solved and making my first contribution on Github


Add trademarks attribution

According to https://www.elastic.co/legal/trademarks you must clearly attribute the brand names. This or a similar text should probably be added to the footer of every single page in both the webpage and documentation?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

My patch is probably wrong, have not tried to build the site. Guess such a text should go as a new variable in footer.yml and be included in footer.html instead.

Thank you, @janhoy, we are reviewing this request.


github-pages:deploy, baseHref should be case-sensitive

Please provide us with the following information:

OS?
Windows 10, Ubuntu 16.04.1 LTS
Versions.
angular-cli: 1.0.0-beta.24
node: 6.9.2
os: linux x64
@angular/common: 2.4.1
@angular/compiler: 2.4.1
@angular/core: 2.4.1
@angular/forms: 2.4.1
@angular/http: 2.4.1
@angular/material: 2.0.0-beta.1
@angular/platform-browser: 2.4.1
@angular/platform-browser-dynamic: 2.4.1
@angular/router: 3.4.1
@angular/comdpiler-cli: 2.4.1
Repro steps.
ng new SWPenguin
(Work on project)
ng github-pages:deploy
The log given by the failure.

https://icepeng.github.io/swpenguin/main.4e5996aaa2ffa03b9c5b.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found)
https://icepeng.github.io/swpenguin/styles.a6c71221f2dfc2c6c594.bundle.css Failed to load resource: the server responded with a status of 404 (Not Found)
https://icepeng.github.io/swpenguin/inline.8030da0a7ffa279deb05.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found)
https://icepeng.github.io/swpenguin/main.4e5996aaa2ffa03b9c5b.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found)
https://icepeng.github.io/swpenguin/favicon.ico Failed to load resource: the server responded with a status of 404 (Not Found)
https://icepeng.github.io/swpenguin/styles.a6c71221f2dfc2c6c594.bundle.css Failed to load resource: the server responded with a status of 404 (Not Found

)
Mention any other details that might be useful.
https://github.com/angular/angular-cli/blob/290c6e779b799f36f02ae68d51b0c8792b42ea25/packages/angular-cli/commands/github-pages-deploy.ts#L97
I found that this line has a problem. package.json generated by ng new command would be lowercase. But if project name has uppercase letters, a problem occurs.

Thanks! We'll be in touch soon.

Dupe of https://github.com/angular/angular-cli/issues/3146


docs(ee/34) remove introduction section

NOTE: Please read the CONTRIBUTING.md guidelines before submitting your patch,
and ensure you followed them all:
https://github.com/Kong/docs.konghq.com/blob/master/CONTRIBUTING.md
Summary
Removes the Introduction section. There are multiple motivations for this decision, but primarily that the page's tone and content imply an audience of curious first-time users--not Enterprise customers.

Checklist:

[x] Commit message & atomicity checked
[x] Documentation
[x] Spellchecked my updates
[ ] Ready to be merged

How many versions back should we go?

(Going into 0.35)


Can't support SpringSecurity4.0+

I use grails websocket,  but need springsecurity4.0+, how to update springsecurity4.0+

The 3.0.0 plugin uses Spring Security 4.0.3

release time?

About 20 hours ago: https://bintray.com/grails/plugins/spring-security-core/3.0.0/view - docs are at https://grails-plugins.github.io/grails-spring-security-core/

very good


usb: device: hid: correct bcdHID to v1.11 spec

bcdHID is intended for the spec version of USB HID. It was pointing to the v1.1 bcdUSB define which happens to be the same value for the v1.10 hid spec version. This corrects it to use the v1.11 HID spec.
Signed-off-by: Ryan McClelland<EMAIL_ADDRESS>

I just realized that I forgot to add #include <class/hid.h> in core.c, but somehow the CIs are all passing :fearful:

I just realized that I forgot to add #include <class/hid.h> in core.c, but somehow the CIs are all passing fearful

include/zephyr/usb/class/usb_hid.h does it.


Updating SAM CLI on AWS Cloud9 - Issue with Loading Remote Functions after upgrade

Description:

Steps to reproduce the issue:

Follow Updating SAM CLI on AWS Cloud9 steps
Try to load remote functions
Fails with "Failed to Load Remote Functions" error on the right side of cloud9

Observed result:
"Failed to Load Remote Functions" error on the right side of cloud9
Expected result:
Should load remote functions
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
Cloud9
Output of sam --version:
Optional Debug logs:
Add --debug flag to command you are running

SAM CLI doesn't do anything with "loading remote functions". This seems like a Cloud9 Issue.
Closing as this is not related to this project.


More informative message at ONNX export

For example, now warn:
The ONNX export succeeded with the warning: The maximum absolute difference between the output of the reference model and the ONNX exported model is not within the set tolerance 1e-05:
- present.7.key: max diff = 1.3113021850585938e-05
- present.11.value: max diff = 1.5974044799804688e-05. The exported model was saved at: gpt2_onnx

instead of:
An error occured, but the model was saved at: gpt2_onnx

Fixes https://github.com/huggingface/optimum/issues/607

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Is "lzip" (.lz) supported?

Are lzip tarballs supported?

My brief understanding from reading wikipedia is that lzip is simply a tool which uses the LZMA algorithm, which yes is supported: https://docs.rs/async-compression/latest/async_compression/?search=lzma


Refactor module and directory structure

This PR introduces a significant reorganization of the structure of modules and directories. It addresses a couple of the points in #4.
EPP request/response models are merged into a single module and are made available at the root of the crate. Everything in /epp has been refactored out into the root of the crate as well. const values in xml have been relocated next to their relevant message groups.
This is a big change but nothing has functionally changed. I want to introduce this change first before I move on to fleshing out what was proposed in #21.

Ok thanks. Makes sense in the context of the planned reorganization of the request/respose structure. Merging.


OpenTelemetry issues; timestamp drift, and LOGGING_SAMPLED_KEY is not treated as boolean

Environment details

OS: OSX Ventura 13.4.1
Node.js version: v14.18.0
npm version: 7.21.1
@google-cloud/logging-winston version: 5.3.0

Steps to reproduce

Create a  simple logger

const logger = Winston.createLogger({
  level: 'info',
  transports: [
    new Winston.transports.Console({
      format: Winston.format.combine(
        Winston.format.timestamp(),
        Winston.format.simple()
     )
    }),
    new LoggingWinston({
      format: Winston.format.combine(
        Winston.format.timestamp(),
        Winston.format.json()
      ),
      serviceContext: {
        service: config.serviceName,
        version: config.serviceVersion
      },
      projectId: config.googleCloudProjectId
    })
  ]
})

Use logger in a simple express app.

const app = express()
const logger = require('./logger')

app.get('/hello', (req, res) => {
  logger.info('hello called', { stuff: 'yep' })
  res.status(200).json({ message: 'hello' })
})

Notice in Cloud Logging and the console that the timestamps differ.

This has a big impact when using OpenTelemetry since the link to "View Logs" relies on the log entries having a timestamp that lies within the timespan of a span during a trace. There is often a drift of a few 100ms in Cloud Logging vs the timespans in Cloud Trace.
By investigating the code I found that info.timestamp is intended to be a Date instance in LoggingCommon#log. So to remedy I had to do this:
const logger = Winston.createLogger({
  level: 'info',
  format: Winston.format.timestamp(),
  transports: [
    new Winston.transports.Console({
      format: Winston.format.simple()
    }),
    new LoggingWinston({
      format: Winston.format.combine(
        // Ensure timestamp is a Date instance
        Winston.format((info) => {
          info.timestamp = new Date(info.timestamp)
          return info
        })(),
        Winston.format.json()
      ),
      serviceContext: {
        service: config.serviceName,
        version: config.serviceVersion
      },
      projectId: config.googleCloudProjectId
    })
  ]
})

The code that expects timestamp to be a Date is within LoggingCommon:

An additional issue is that the key LoggingWinston.LOGGING_SAMPLED_KEY should be expected to be a boolean, but the LoggingCommon class expects it to be a string like "1". In OpenTelemetry this is stored in the traceFlags of the span context as a number, not a string. And typically we can convert to boolean via span.spanContext().traceFlags === OpenTelemetry.TraceFlags.SAMPLED. It's really odd to have this documented as needing to be a boolean but in the code it expects a string.
As a remedy I had to set this key to String(span.spanContext().traceFlags).

Hi @dschnare, Thank you for reporting the issue. I was able to repro it and I have sent out PRs to address the two concerns mentioned above:

Timestamps drift in logging library: https://github.com/googleapis/nodejs-logging-winston/pull/827
2.LoggingWinston.LOGGING_SAMPLED_KEY expecting boolean value: https://github.com/googleapis/nodejs-logging-winston/pull/830


Bacalhau only supports the use of 1 GPU

Only 1 GPU can be used at a time: https://github.com/filecoin-project/bacalhau/blob/dev/pkg/executor/docker/executor.go#L225
The Docker API expects you to specify the exact GPU you want to run on by ID or by device number.
At the time of writing this code I didn’t know how to or whether we wanted to support maintaining the state of what GPUs are in use by that particular node. Maybe there’s a way now, but that was considered future work. Hence the todo.
In summary, only GPU 0 can be used and the docs are correct.
In the future, we need to support both running multiple jobs on multiple GPUs and single jobs on multiple GPUs. But this is very tied to how GPU jobs are specified and state is maintained so there's probably some dependent work that is required first. See the main GPU improvement issue for this.

We need this to support compute providers who are showing up with multi-GPU servers


CPU works without cudf installed

I added a tests that runs a workflow with cpu.
It works without cudf (and with cudf too).

rerun tests

rerun tests

rerun tests


Validations text annotation

Proposed Changes
This pull request adds new validations to the TextAnnotation model and updates the corresponding tests to ensure data integrity. Specifically, it ensures that:

The line_start and line_end attributes must be greater than or equal to 1.
The column_start and column_end attributes must be greater than or equal to 0.

Motivation
These changes are motivated by the need to prevent invalid values for line and column numbers in the TextAnnotation model, ensuring that the data stored is always within a valid range. This enhancement improves the robustness and reliability of the application.
Type of Change
(Write an X or a brief description next to the type or types that best describe your changes.)

Type
Applies?

🚨 Breaking change (fix or feature that would cause existing functionality to change)

✨ New feature (non-breaking change that adds functionality)
X

🐛 Bug fix (non-breaking change that fixes an issue)

🎨 User interface change (change to user interface; provide screenshots)

♻ Refactoring (internal change to codebase, without changing functionality)

🚦 Test update (change that only adds or modifies tests)
X

📦 Dependency update (change that updates a dependency)

🔧 Internal (change that only affects developers or continuous integration)

Checklist
(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)
Before opening your pull request:

[x] I have performed a self-review of my changes.

Check that all changed files included in this pull request are intentional changes.
Check that all changes are relevant to the purpose of this pull request, as described above.

[x] I have added tests for my changes, if applicable.

This is required for all bug fixes and new features.

[x] I have updated the project documentation, if applicable.

This is required for new features.

[x] If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

[x] I have updated the project Changelog (this is required for all changes).
[x] I have verified that the pre-commit.ci checks have passed.
[x] I have verified that the CI tests have passed.
[x] I have reviewed the test coverage changes reported by Coveralls.
[x] I have requested a review from a project maintainer.

Questions and Comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

18 of 18 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 91.426%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
40014

Relevant Lines:
43093

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
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

18 of 18 (100.0%)  changed or added relevant lines in 2 files are covered.
31 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.05%) to 91.378%

Files with Coverage Reduction
New Missed Lines
%

app/assets/javascripts/Components/Result/submission_selector.jsx
2
90.48%

app/assets/javascripts/Components/Result/notebook_viewer.jsx
7
0.0%

app/assets/javascripts/Components/Helpers/range_selector.js
22
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.05%

Covered Lines:
40018

Relevant Lines:
43114

💛  - Coveralls

Good job, @umututku03 🎉


Upgrading from 4.0.3 to 5.0.0 does not delete old rsyslog.d/client.conf

I just upgraded from 4.0.3 to 5.0.0
I was using the two classes: rsyslog, and rsyslog::client
This managed two files: /etc/rsyslog.conf, and /etc/rsyslog.d/client.conf
After upgrading to 5.0.0, a puppet agent -t run creates a new client config file  /etc/rsyslog.d/00_client.conf , but does not delete the previously managed /etc/rsyslog.d/client.conf. So both files are existing in rsyslog.d/ now.
Running a diff on the two files yields no differences. And rsyslog does not appear to be having an issue with both files existing. So this does not break rsyslog. However, I would assume problems would start arising once new changes are made to rsyslog::client, and these two files begin to differ.
Can the older file be removed?
Or let the behavior be that when split_config=false then rsyslog::client only manages the client config as /etc/rsyslog.d/client.conf, and when true performs as documented?

This is just a rename of the config file.
Can you show the parameters passed to both classes?
Sent using Boxer
On 2 Dec 2016 5:19 PM, rglaue<EMAIL_ADDRESS>wrote:
I just upgraded from 4.0.3 to 5.0.0
I was using the two classes: rsyslog, and rsyslog::client
This managed two files: /etc/rsyslog.conf, and /etc/rsyslog.d/client.conf
After upgrading to 5.0.0, a puppet agent -t run creates a new client config file /etc/rsyslog.d/00_client.conf , but does not delete the previously managed /etc/rsyslog.d/client.conf. So both files are existing in rsyslog.d/ now.
Running a diff on the two files yields no differences. And rsyslog does not appear to be having an issue with both files. So this does not break rsyslog. However, I would assume problems would start arising once new changes are made to rsyslog::client, and these two files begin to differ.
Can the older file be removed.
Or let the behavior be that when split_config=false then rsyslog::client only manages the client config as /etc/rsyslog.d/client.conf, and when true performs as documented?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

parameters passed to both classes:
class { 'rsyslog':
    preserve_fqdn        => true,
    gnutls_package_name  => false,
    relp_package_name    => false,
    rsyslog_package_name => false
}
class { 'rsyslog::client':
    log_local            => true,
    remote_type          => udp,
    server               => syslog.example.com
}

And here is the output on a client node:
[root@server1 ~]# ls -l /etc/rsyslog.d/
-rw-------.  1 root root 1542 Dec  2 10:04 client.conf

# Performed puppet module upgrade from 4.0.3 to 5.0.0

[root@server1 ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: NetworkManager is not running.
Info: Caching catalog for server1.example.com
Info: Applying configuration version '1480694817'
Notice: /Stage[main]/Rsyslog::Client/Rsyslog::Snippet[00_client]/File[/etc/rsyslog.d/00_client.conf]/ensure: created
Info: /Stage[main]/Rsyslog::Client/Rsyslog::Snippet[00_client]/File[/etc/rsyslog.d/00_client.conf]: Scheduling refresh of Class[Rsyslog::Service]
Info: Class[Rsyslog::Service]: Scheduling refresh of Service[rsyslog]
Notice: /Stage[main]/Rsyslog::Service/Service[rsyslog]: Triggered 'refresh' from 1 events
Notice: Finished catalog run in 1.14 seconds

[root@server1 ~]# ls -l /etc/rsyslog.d/
-rw-------.  1 root root 1542 Dec  2 10:07 00_client.conf
-rw-------.  1 root root 1542 Dec  2 10:04 client.conf

I just ran into this issue as well

Have you tried the purge_rsyslog_d parameter of Class["Rsyslog"]?

This would work as long as it can be done safely. In my situation, this is an unknown. There are a few  workarounds and the major version bump indicates backwards incompatibility. Based on that, it seems reasonable that this could be closed as a non-issue but I'll leave that up to @rglaue.

On the merits of the issue alone, I would agree with @walkamongus . However, then the resolution is not a code change, but a documentation change. Documentation related to upgrade incompatibility warnings. The system admin needs to be aware of this before they upgrade.
I had deployed the checked-out code at HEAD a week or so before 5.0.0 release to test a resolution to a previous submitted bug. This issue did not pop up in that test. So it is an unexpected issue.
If the documentation can be added to warn of this upgrade and version incompatibility issue, then it would be satisfactory to resolve the issue.
For me, I'll have to go through 300+ servers to perform a cleanup. The undocumented purge_rsyslog_d parameter is too forceful. For example, we have services that log to local syslog, and the RPM drops an rsyslog configuration file in /etc/rsyslog.d/ directory. So ... can't use the undocumented purge_rsyslog_d parameter.

I now this wasn't a good change and I'm sorry for any inconvenience. I'll try to release a fixed version tomorrow.
Saz
Sent using Boxer
On 20 Dec 2016 8:46 PM, rglaue<EMAIL_ADDRESS>wrote:
On the merits of the issue alone, I would agree with @walkamongus . However, then the resolution is not a code change, but a documentation change. Documentation related to upgrade incompatibility warnings. The system admin needs to be aware of this before they upgrade.
I had deployed the checked-out code at HEAD a week or so before 5.0.0 release to test a resolution to a previous submitted bug. This issue did not pop up in that test. So it is an unexpected issue.
If the documentation can be added to warn of this upgrade and version incompatibility issue, then it would be satisfactory to resolve the issue.
For me, I'll have to go through 300+ servers to perform a cleanup. The undocumented purge_rsyslog_d parameter is too forceful. For example, we have services that log to local syslog, and the RPM drops an rsyslog configuration file in /etc/rsyslog.d/ directory. So ... can't use the undocumented purge_rsyslog_d parameter.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


banshee: Consider the hartid offset in the wfi implementation

The wfi vector storing which core has a pending wake-up request did not consider the base-hartid. This led to out-of-bound array accesses if base-hartid > 0.
This should fix the failing CI.

The SW on banshee (Container) test still fails, I assume we just have to rerun the tests to use the updated container? And from then on, no failing container should make it into master?

Yes, exactly. After we merged this into master everything should work again. Thanks!


Remove notice on 404 pages (or any page where there isn't a post object)

If there is a 404 page, or any page where the post object isn't present, a notice no longer displays that $post isn't an object.
Fixes #19

+1

Closing this PR due to mode changes on all the files, but I've integrated the fix into master. Thanks!


Android production crash

Description
Hello, I received few crashes from Crashlytics. They appears only in production and I can't reproduce it locally. Probably stacktrace   may be useful here
Stacktrace
Fatal Exception: com.facebook.react.common.JavascriptException: TypeError: Cannot read property 'x' of null, js engine: hermes, stack:
./node_modules/@openspacelabs/react-native-zoomable-view/src/ReactNativeZoomableView.tsx:603:_handlePinching
./node_modules/@openspacelabs/react-native-zoomable-view/src/ReactNativeZoomableView.tsx:537:ReactNativeZoomableView
./node_modules/react-native/Libraries/Interaction/PanResponder.js:522:panHandlers.onResponderMove
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:22:invokeGuardedCallbackImpl
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:40:invokeGuardedCallback
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:53:invokeGuardedCallbackAndCatchFirstError
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:73:executeDispatch
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1125:executeDispatchesAndReleaseTopLevel
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:361:forEachAccumulated
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1160:batchedUpdates$argument_0
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:8427:batchedUpdatesImpl
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1106:batchedUpdates
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1137:_receiveRootNodeIDEvent
./node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js:1209:ReactNativePrivateInterface.RCTEventEmitter.register$argument_0.receiveTouches
./node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:423:__callFunction
./node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:113:__guard$argument_0
./node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:368:__guard
./node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:112:callFunctionReturnFlushedQueue

Environment

react: 18.1.0
react-native:  0.70.6
@openspacelabs/react-native-zoomable-view: 2.2.0

The line in question
I think the right solution here might just be to do something like:

Seems like that function returns a null but isn't getting type-checked properly. This indicates a problem with the typescript setup

We experienced a similar issue in our production app on Android device:
Stack trace as reported to Sentry:
TypeError Cannot read property 'x' of null
<EMAIL_ADDRESS>in _handlePinching at line 603:28
    }
    const gestureCenterPoint = calcGestureCenterPoint(e, gestureState);
    const zoomCenter = {
      x: gestureCenterPoint.x - this.state.originalPageX,
      y: gestureCenterPoint.y - this.state.originalPageY,
    };
    // Uncomment to debug
    this.props.debug && this._setPinchDebugPoints(e, zoomCenter);

<EMAIL_ADDRESS>in anonymous at line 513:27
/node_modules/react-native/Libraries/Interaction/PanResponder.js in onResponderMove at line 522:36
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in invokeGuardedCallbackImpl at line 22:15
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in invokeGuardedCallback at line 40:34
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in invokeGuardedCallbackAndCatchFirstError at line 53:30
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in executeDispatch at line 73:42
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in executeDispatchesAndReleaseTopLevel at line 1125:24
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in forEachAccumulated at line 361:35
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in anonymous at line 1160:25
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in batchedUpdatesImpl at line 8457:14
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in batchedUpdates at line 1106:30
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in _receiveRootNodeIDEvent at line 1137:17
/node_modules/react-native/Libraries/Renderer/implementations/ReactNativeRenderer-prod.js in receiveTouches at line 1209:30
/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js in __callFunction at line 433:34
/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js in anonymous at line 113:26
/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js in __guard at line 368:11
/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js in callFunctionReturnFlushedQueue at line 112:17


HTML ( ejs ) support

Could you add those formats?

feel free to open a PR ;-)

@flosse Ok. Thank you but a little bit later. You've written amazing module. Thank you!


bokeh backend with string xaxis yields empty plot with xticks in opts

Works with matplotlib but not bokeh
import holoviews as hv
import hvplot.pandas
import pandas as pd

hv.extension('matplotlib')
df1 = pd.DataFrame({'coords': ['(0, 1)', '(0, 2)'], 'values': [0, 1]})
df1.hvplot('coords', 'values').opts(xticks=[(0, '(0, 1)N')])

hv.extension('bokeh')
df1 = pd.DataFrame({'coords': ['(0, 1)', '(0, 2)'], 'values': [0, 1]})
df1.hvplot('coords', 'values').opts(xticks=[(0, '(0, 1)N')])

I don't get an empty plot here, but I also don't understand what you're trying to do. The main issue here is that bokeh does not support custom ticking on categorical axes, but from a holoviews perspective everything is working as intended.


LVM deep storage mod is not compatible with RimThreaded; items scatter out of containers

Seems to be a problem in GenSpawn.Spawn. Probably needs to be transpiled, rather than prefix'd. Only 2 lines are added, both are simple null checks.
https://github.com/cseelhoff/RimThreaded/blob/master/Source/GenSpawn.cs#L63-L67
        //added null check
        if (null != newThing)
        {
            //added null check
            if (null != newThing.def)

After checking the Deep Storage mod I found a Transpiler for the GenSpawn.Spawn method. Your prefix returns false, thus preventing the original method (which was transpiled) from being run.
Since this is just a null check, I suggest changing the prefix to just contain the check and prevent further execution only in case newThing is null.
It's probably also sensible to figure out what's calling GenSpawn.Spawn with newThing set to null.


BRL based conversion inconsistency

Hi!
I'm using your API and really enjoying the result, by the way.
Just a detail that I realized is that when I use the BRL currency as the basis for conversion, the result is not accurate.
For example, with the base date 1/14/2021, the USD to BRL conversion is as follows:
1 USD = 5.269548004 BRL (https://api.exchangeratesapi.io/latest?base=USD)
However, I need my base to be the BRL. When I try to do the conversion based on BRL, the result is the following:
1 BRL = 0.1897695968 USD (https://api.exchangeratesapi.io/latest?base=BRL)
The ideal would be: 1 BRL = 5.269548004 USD.
Clearly, the API is dividing 1 (BRL) by 5.269548004 (USD) while it should only show 5.269548004, which is the value of the Brazilian real against the US dollar.
Could you please analyze that?

Hi Marcelo.
By chance I saw this.
The API is correct, because 1BRL worths around 18 cents US Dollar.
When you see a pair, like USDBRL or EURBRL, you will get the value that the first currency buys of the second one.
So 1 USD buys 5.26 BRL, 1 EUR buys 6.6421 BRL.
I think you need to iterate over the bases you want againt BRL

Thank's!


ARROW-11755: [R] Add tests from dplyr/test-mutate.r

1st version

pending: why it fails on windows

a few questions
should we skip tests on grouped data (not supported in Arrow) or pass it to R with warning?
https://github.com/pachamaltese/arrow/blob/arrow11755v2/r/tests/testthat/test-dplyr-mutate.R#L557
I'm 0 sure about tests with 0 rows, how would you sketch that?
https://github.com/pachamaltese/arrow/blob/arrow11755v2/r/tests/testthat/test-dplyr-mutate.R#L522
the same about not overwriting variables, does this look ok?
https://github.com/pachamaltese/arrow/blob/arrow11755v2/r/tests/testthat/test-dplyr-mutate.R#L514


Question: How to deploy scheduler?

I don't see a deployment guide for this. Can you point me to one or give some idea how you are deploying this?

Since scheduler is a library, deployment details are left to the user and can be quite varied. That said, Scheduler does depend on Cassandra and Kafka, so you need to have those two things running.


Debouncing example

Debouncing example with a simple search bar with useEffect written in Typescript

Hello @albseb511!
Unfortunately the examples section is no longer maintained or even included in the docs, so this PR is outdated.
Let me close it, but please feel invited to create new contributions addressing open issues.
Thank you!

hey no worries. this is years ago :p


柱状图的图例选择用系列的data怎么做

柱状图的图例选择用系列的data怎么做

Can not understand

How to Choose Legend of Histogram with Series Data,sorry,My English is not good


pythonPackages.redis-py: init at 3.1.0

Motivation for this change
Required for a project.
This is a nearly identical copy of pythonPackages.redis which uses a different module name "redis-py". There seems to have been disagreement among users of the module, some of whom believed that the name "redis" did not properly distinguish itself from the actual application "redis". In any case other modules that I required need the module to use "redis-py" as it's name.
Things done
A copy of 'pythonPackages.redis' was made and renamed. The proper license was also added.

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Another solution was found by renaming the package in the depender.


Translated contributing.md

I translated 'contributing.md' into english. If there are any awkward parts, please point out.

@scarecrow21 Akshaj, could you please review this patch?
You seem an expert in English. :)
(or, after merging this patch as-is, you can send follow-up PR.)

@romandev , can you guide me through reviewing this patch? I'm new to all this.

@scarecrow21 Thank you for reply.
It's very easy. You can just leave some inline comments in Files Changed Tab in this patch if you think some point is wrong.
But I think it's better for you to make a new patch instead of reviewing this patch. WDYT?
(Because I welcome your contribution :) )

@scarecrow21, So, if you want a new patch, I'll merge this ASAP.

Yep. Merge it. I'll take a new patch.

So, I'll create a new branch, edit the docs/contributing.md file and submit a pull request?

@scarecrow21 Sure. Thanks!

I have a doubt. The docs/contributing.md file has changed here on github but not on my local machine. What should I do so that the updated file is present on my local machine as well?

You can pull all changes as follows:
git pull

@scarecrow21 If you clone your own repo (scarecrow21/absolute instead of lunchclass/absolute), you can rebase as follows:
FYI, your own repo is scarecrow21/absolute and the repo is foked from lunchclass/absolute.
Therefore upstream repo is lunchclass/absolute.
You can set upstream repo as follows:
$ git remote add upstream https://github.com/lunchclass/absolute.git

Then, you can fetch upstream's changes into your .git internal storage as follows:
$ git fetch upstream

And then, you can rebase your repo based on upstream as follows:
$ git checkout master
$ git rebase upstream/master

And then, you can push your local repo to Github.
$ git push origin master -f

Then, you can see latest history in your Github repo.
Also, you can checkout a new branch to make a new patch.
If you have some question, please ping me anytime.
(Also, if you join our team's slack, I or others help you more.
Thank you very much!

FYI, this is Slack invitation link: https://bit.ly/lunchclass_slack


Add items counter

Hello
In this branch, I added all movie card counters on the home page.

Status: Aproved
Highlights
✅Good use of modules
✅Linters pass
There's nothing else to say other than it's time to merge!


Node-sass made a breaking change without tagging a major version update

The reason semver exists, and is important in public modules is that if you make a change that breaks functionality, consumers of the module won't immediately pick it up by opting into minor or patch changes.
Yesterday, node-sass updated to 3.5 and with that change, fixed a bug that allowed users to declare a function inside of a conditional clause. Fixing this bug would break any code that declared functions in conditional clauses, which is exactly what happened in compass-mixins.
In the future, when code is shipped that could potentially break code, it needs to be shipped under a major version update.

had this same issue :(  went back to "node-sass": "~3.4.2"

This is also currently biting my project, which uses gulp-sass. gulp-sass depends on node-sass#^3.4.1 which just automatically updated to 3.5.3 which is a breaking release.

This project is an implementation of the Sass language. Our goal is to be 100% compatible with Sass. These issues you mention are a result of invalid Sass. Node Sass has no way to know that these breakages because we assume valid Sass is being compiled. This is no different to depending on an undocumented API. For that reason we do not consider these breaking changes.
If valid Sass started breaking we would consider that a breaking change. We don't claim responsibility for bugs in the Sass code being compiled.
If you wish to suggest features of file bugs in the Sass language please open an issue with Sass - https://github.com/sass/sass
In closing if your code does not compile with the official Sass project you should not expect it to compile with Node Sass.

I have blogged about this for more details - https://medium.com/@xzyfer/why-node-sass-broke-your-code-and-semver-1b3e409c57b9

I understand and appreciate the goals of node-sass and this is my attempt to contribute. If you fix something that's broken (e.g. A bug that allows invalid code to no longer compile) that is considered a major change under any interpretation of semver. I only ask that maintainers consider changes and version tagging more closely. If they need help, feel free to add me to the list of maintainers.

Since you bring up SemVer, see this point http://semver.org/#spec-item-6 emphasis

A bug fix is defined as an internal change that fixes incorrect behavior.

@nschonni you seemed to have accidentally left out this first part of that section "Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced."

@dclowd9901 you're missing an integral part which I covered in my blog post. There is simply no way we can know we're breaking invalid Sass code. It's impossible to account for every possible thing or combination of things someone is trying to compile as Sass.
We expect that the code being compiled is valid Sass code. If we break valid Sass code it's a breaking change. If your code was invalid we cannot make any guarantees.


Fixed object release operation when maintaining coherency

the fix does not fix the problem...

What problem? Is there a filed issue?


⚠ Bofrost.be has degraded performance

In 298587f, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1211 ms

Resolved: Bofrost.be performance has improved in f492ee3.


KAFKA-7077: Use default producer settings in Connect Worker

In KAFKA-7077 and the associated KIP-318, there's a desire to a) enable producer idempotence and b) set max in flight requests to 5 to improve throughput, as opposed to the previous hardwired 1.
With the change of producer defaults in Kafka 3.0.0 (acks = all, enable.idempotence = true, max.in.flight.requests.per.connection=5) all this behaviour comes for free if the explicit producer configuration in the Worker is removed.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@LiamClarkeNZ , thanks for the PR. LGTM. But there's a bug cause the default idempotent producer is not enabled and get fixed recently. (ref: #11691 ) Could you rebase to the latest trunk and trigger jenkins build again?
Also, I was wrong in this comment: https://github.com/apache/kafka/pull/11691/files#r791886361 , I checked again and found there's only KafkaStatusBackingStore class cannot enable idempotent producer because it implement its own retry logic, to include deleted record here.
Anyway, looks like even if we don't have this PR, the kafka connect will use idempotent producer by default (with just 1 in-flight request only). cc @mimaison

Thanks @showuon, I have rebased onto trunk and force pushed. I appreciate the review :)

Failed tests are unrelated:
Build / ARM / org.apache.kafka.streams.integration.NamedTopologyIntegrationTest.shouldRemoveOneNamedTopologyWhileAnotherContinuesProcessing
Build / JDK 8 and Scala 2.12 / org.apache.kafka.connect.integration.RebalanceSourceConnectorsIntegrationTest.testDeleteConnector
Build / JDK 8 and Scala 2.12 / kafka.server.KRaftClusterTest.testCreateClusterAndPerformReassignment()
Build / JDK 8 and Scala 2.12 / org.apache.kafka.streams.integration.NamedTopologyIntegrationTest.shouldRemoveOneNamedTopologyWhileAnotherContinuesProcessing
Build / JDK 11 and Scala 2.13 / kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize()
Build / JDK 11 and Scala 2.13 / kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize()
Build / JDK 11 and Scala 2.13 / org.apache.kafka.streams.integration.NamedTopologyIntegrationTest.shouldRemoveOneNamedTopologyWhileAnotherContinuesProcessing
Build / JDK 17 and Scala 2.13 / kafka.admin.LeaderElectionCommandTest.[1] Type=Raft, Name=testElectionResultOutput, Security=PLAINTEXT
Build / JDK 17 and Scala 2.13 / kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize()
Build / JDK 17 and Scala 2.13 / kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize()

@kkonstantine @rhauch Is it OK to enable idempotence by default in this case? Are there any compatibility or behavior concerns?

@showuon We should add a note to upgrade.html for this (and similar types of changes).

@ijuma , I see. Thanks for the reminder. Will do.
@LiamClarkeNZ , please help add a note in 3.2 notable change in upgrade.html. Thanks

Thanks for bring this to our attention @ijuma. This change should be fine from Connect's perspective. acks=all is now implied instead of explicitly defined and idempotence has been enabled since 3.0.0 and we had decided not to override this setting in Connect.
The property that would give someone pause is the value for max.in.flight.requests.per.connection that now is greater than 1. The reassurance that this will work comes from KAFKA-5494 which unfortunately is not mentioned in the original KIP-98 (I see it mentioned in the KIP-318 that is relevant to Connect).
Having said that, I think it would have been a good idea to leave a comment in the code that would say that Connect requires these configs which are now enabled by default with the idempotent producer.
I also agree that this should go as a notable change in the docs.

@kkonstantine , thanks for the comment. I agree we add comments in the code to say the idempotent producer is enabled by default.
cc @LiamClarkeNZ
Thank you.

Hi Luke, Ismael et al,
No worries on adding a comment to that effect in the upgrade docs - but I'm
not sure how to word it, as the idempotent producer was never explicitly
disabled by default in the Kafka Connect Worker. I realise, based on Luke's
recent work to fix KAFKA-13598, that the intended enabling of idempotence
by default with Kafka 3.0 didn't happen either.
So while I just removed the setting of max inflight requests to 1, allowing
the default of 5 to be used, . (I also removed the explicit setting of
acks=all for the same reason), I guess this will be the first version where
Kafka Connect uses idempotent producers by default. So I was thinking of
wording it like this?
Kafka Connect now uses [idempotent producers](http://link.to.docs.here
http://link.to.docs.here) by default, and now defaults to a maximum of 5
inflight requests (five is the uppermost limit supported by idempotent
producers). You can override producer settings controlling this behaviour
using the properties producer.enable.idempotence and
producer.max.inflight.requests
Actually, do we need to add similar documentation to the upgrade
documentation for 3.0.1, 3.1.1 also? As KC workers based on those version
will now be defaulting to idempotent enabled. The workers in those versions
will still have max.inflight.requests set to 1, but it could be set to 5 by
producer.* overrides, I could add commentary to that regard.
Thanks,
Liam
On Tue, 22 Mar 2022 at 19:07, Luke Chen @.***> wrote:

@kkonstantine https://github.com/kkonstantine , thanks for the comment.
I agree we add comments in the code to say the idempotent producer is
enabled by default.
cc @LiamClarkeNZ https://github.com/LiamClarkeNZ
Thank you.
—
Reply to this email directly, view it on GitHub
https://github.com/apache/kafka/pull/11475#issuecomment-1074774576, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AC2Q2JGE4E2XYPJ5LINUMNDVBFPQDANCNFSM5HRTSEYA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks @LiamClarkeNZ !
The wording overall LGTM! Please submit a PR when available. We can comment on the wording there.

Actually, do we need to add similar documentation to the upgrade
documentation for 3.0.1, 3.1.1 also?

Yes, please add them to 3.0.1 and 3.1.1, too.
Thanks.

Cheers Luke, will do :)
On Tue, 22 Mar 2022 at 19:43, Luke Chen @.***> wrote:

Thanks @LiamClarkeNZ https://github.com/LiamClarkeNZ !
The wording overall LGTM! Please submit a PR when available. We can
comment on the wording there.
Actually, do we need to add similar documentation to the upgrade
documentation for 3.0.1, 3.1.1 also?
Yes, please add them to 3.0.1 and 3.1.1, too.
Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/apache/kafka/pull/11475#issuecomment-1074794074, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AC2Q2JD2ZYB6NDBBCRAQLPDVBFTXNANCNFSM5HRTSEYA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@kkonstantine A related question in this other PR https://github.com/confluentinc/ce-kafka/pull/5905#issuecomment-1075167825

One other thing: the IDEMPOTENT_WRITE ACL is required for the Connect worker principal if the kafka cluster is older than 2.8.

@showuon I noticed that you recently disable idempotency for the status backing store. Now that we remove acks=all should we add it there? Is this something we missed with the changes here? And taking an even closer look at the status backing store implementation, I see that retries are handled by that class. So we disable idempotence but are we sure max.in.flight.requests.per.connection=1 is there?
Also, re:

@kkonstantine , thanks for the comment. I agree we add comments in the code to say the idempotent producer is enabled by default.

my intention was actually to add a comment in the code to say what are the configs that we definitely require for the producers in Connect to work as intended. And these are acks=all, max.in.flight.requests.per.connection=1 unless idempotency is enabled given that we have KAFKA-5494 and infinite retries. These requirements were reflected in actual code until this PR was merged. But now they are implied by the defaults of the idempotent producer and that's something I'd like to leave a trail of, so we know what works for Connect.

@ismael you're bringing up a good point, which I missed in your latest comment before I send my recent reply.
In light of the requirement to explicitly add the IDEMPOTENT_WRITE ACL for Connect workers when talking to Kafka brokers older 2.8 (which I wasn't aware of), I'd like to suggest changing course here as follows:

Revert KAFKA-7077 from all the branches that has been merged.
Return to KIP-318, update it and actually vote for it. @LiamClarkeNZ you referred to this KIP in the description of this PR but I missed that this KIP hasn't been approved and is actually currently marked as inactive. I think we should raise it again after we update it to include all the compatibility requirements and have it target the next major version (4.0).
Issue a new PR that will explicitly disable idempotency by default in Connect and will allow users to override the setting via the worker and/or the connector configs like we allow it today.
In the same PR, update our docs to say that despite the Kafka producer enabling idempotency by default in 3.0, due to compatibility requirements Connect chooses to disable idempotency for all the producers that instantiates by default.

That sounds good to me. Let's make sure we include these changes in 3.0.x and 3.1.x as well. For the latter, we still have time to make it for 3.1.1.

Sounds good to me, too. Thanks, @kkonstantine.

Thanks @kkonstantine !

Hi Konstantine, please note that reverting KAFKA-7077 won't disable
producer idempotence in Kafka Connect, as it never explicitly enabled or
disabled it. You'll still need to make changes in code to explicitly
disable producer idempotence to achieve your aims, whether 7077 is reverted
or not.
On Wed, 23 Mar 2022 at 11:15, Konstantine Karantasis <
@.***> wrote:

@Ismael https://github.com/Ismael you're bringing up a good point,
which I missed in your latest comment before I send my recent reply.
In light of the requirement to explicitly add the IDEMPOTENT_WRITE ACL for
Connect workers when talking to Kafka brokers older 2.8 (which I wasn't
aware of), I'd like to suggest changing course here as follows:

Revert KAFKA-7077 https://issues.apache.org/jira/browse/KAFKA-7077
from all the branches that has been merged.
Return to KIP-318
https://cwiki.apache.org/confluence/display/KAFKA/KIP-318%3A+Make+Kafka+Connect+Source+idempotent,
update it and actually vote for it. @LiamClarkeNZ
https://github.com/LiamClarkeNZ you referred to this KIP in the
description of this PR but I missed that this KIP hasn't been approved and
is actually currently marked as inactive. I think we should raise it again
after we update it to include all the compatibility requirements and have
it target the next major version (4.0).
Issue a new PR that will explicitly disable idempotency by default
in Connect and will allow users to override the setting via the worker
and/or the connector configs like we allow it today.
In the same PR, update our docs to say that despite the Kafka
producer enabling idempotency by default in 3.0, due to compatibility
requirements Connect chooses to disable idempotency for all the producers
that instantiates by default.

—
Reply to this email directly, view it on GitHub
https://github.com/apache/kafka/pull/11475#issuecomment-1075693990, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AC2Q2JFYOJFUFYW7QRLZP23VBJA6JANCNFSM5HRTSEYA
.
You are receiving this because you were mentioned.Message ID:
@.***>


Logs failed to download

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az webapp log download
Errors:
('Connection broken: IncompleteRead(25 bytes read)', IncompleteRead(25 bytes read))
Traceback (most recent call last):
lib/python3.8/http/client.py, ln 556, in _get_chunk_left
    chunk_left = self._read_next_chunk_size()
lib/python3.8/http/client.py, ln 523, in _read_next_chunk_size
    return int(line, 16)
ValueError: invalid literal for int() with base 16: b''

...

python3/dist-packages/urllib3/response.py, ln 443, in _error_catcher
    raise ProtocolError("Connection broken: %r" % e, e)
urllib3.exceptions.ProtocolError: ('Connection broken: IncompleteRead(25 bytes read)', IncompleteRead(25 bytes read))

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az webapp log download --name {} --resource-group {}

Expected Behavior
Environment Summary
Linux-5.13.0-40-generic-x86_64-with-glibc2.29
Python 3.8.10
Shell: bash

azure-cli 2.0.81

Extensions:
azure-devops 0.17.0

Additional Context

@cisarpavel I see that you are using an older version of Azure CLI. Could you update your AzCLI to the most recent version and test the download again ?
On a side note, ensure that you are using a reliable network which has a better download speed while testing the command.
Awaiting your reply.

@navba-MSFT  Thanks, I used default repo version. Newer one works well.

For me the issue persists also with version 2.37.0. In the meantime, 2.38.0 was released so I'll try to re-test with that one too.
Just one interesting observation: About every 3rd query via az webapp log download actually worked without any problem. But then I would re-run the pipeline (with the command) and it would fail again.

Ok, I can confirm the issue persists in version 2.38.0. Sometimes it works, sometimes it doesn't...

@MrMCake, I'm unable to repro this. Can you provide more info about the app you're using (OS, SKU, app kind, etc.)?


Optional monitors

This PR introduces optional monitors feature.
The whole idea is that Object doesn't contain __monitor field anymore.
TypeInfo_Class will hold a monitor offset, if a class has one (by marking class declaration with @monitor attribute), or 0.
Monitor lookup is done with a hash map, if monitorOffset is 0.
The hash map is protected by a primitive RW spin lock.
Monitor finalization will only lookup for monitors, if a monitor was allocated at least once for the type of object being finalized.
druntime counterpart: https://github.com/D-Programming-Language/druntime/pull/789
discussion<EMAIL_ADDRESS>

I'm in favor of this. The current backward-compatible approach is the way to go, though I agree with @MartinNowak in the long run we may envision complete deprecation.
Please rebase and let's push this through. Thanks!

Half a year later w/o merging this patch the idea still looks sexy to me.
@MartinNowak any plans to move on this in any of 2 competing plans?

Well what's going on?

"All checks have failed"

Half a year later w/o merging this patch the idea still looks sexy to me.
@MartinNowak any plans to move on this in any of 2 competing plans?

Yes, I'm still opposed to adding a global hash and the outlined plan still makes sense.
Furthermore having monitor support on all classes creates ownership/attribute issue for the monitor (https://github.com/MartinNowak/phobos/commit/8cf0ec29ad65ac2a13bd6917b4ff3da0fdea5ab0#diff-4e008aedb3026d4a84f58323e53bf017R4883).
I don't have the capacity to pull this story, but starting by adding an @(Object.Monitor) UDA and recognizing that in the compiler should be fairly trivial (e.g. look at the objective-c changes).

recognize monitor UDA and deprecate synchronizing on classes without it

Let's proceed with stage 1 for when 2.071 opens then?
Do we have available documentation / rationale on the deprecated features page?  Or a DIP?

Do we have available documentation / rationale on the deprecated features page? Or a DIP?

Sure, a small entry on http://dlang.org/deprecate.html would be nice, a DIP is overkill though.


Make users_controller works with new account and profile page

In branch user-account please

[ ] Split organization and standard user controllers.
[ ] Send errors when account update fails
[ ] Make it work for standard and organization users
[ ] Send flash notifications when needed

Issue https://github.com/CartoDB/cartodb/issues/2542 makes hard to fully test the new routes.
I'm going to build all routing, test GETs etc. but probably actions won't work until urls are fixed.

Another issue: Password change is not working correctly because the field is not  being sent to the user model, but this raises an issue from my point of view.
Right now Central has user password management and CartoDB only receives a new one and stores, so for example has no validation methods (min. length and the like). By adding this stuff we're going to duplicate logic from Central into the Editor. Are we ok with this @juanignaciosl @xavijam ?

There's some logic and code duplication between them. Maybe we should invest in packaging that common code, but it's expensive (decoupling from libraries and so on).
I'm not ok with code duplication between CartoDB and Central, but I'm afraid we can't get rid of it right now.

Profile photo uploads page is broken due to the wrong urls (issue #2542) http://admin.localhost.lan:4000/uploads/development/kartones/assets/20150302170014test.png


print_field should recursively ignore href

Not a problem anymore. The main yaas functions will never return hrefs, so the parsers won't have to deal with them.

The main yaas functions will never return hrefs

Still meh about this... but let's run with it for a bit to see if it raises any issue


docs(website): restructure the IbisML landing page

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.42%. Comparing base (99ed8ad) to head (5a0782a).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #81   +/-   ##
=======================================
  Coverage   84.42%   84.42%
=======================================
  Files          21       21
  Lines        1541     1541
=======================================
  Hits         1301     1301
  Misses        240      240

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


New brush should start empty

User Harry on workshop suggested that it would be more intuitive if the new brush option would make the new brush not have any trees in it

Added this as an option.


Wayfinder init local docker tests

Description
This PR includes the following proposed change(s):

{List all the changes, if possible add the jira ticket #}

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Updating Testing Framework(s)
[ ] Version change

How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Frontend Development Changes

[x] N/A
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to project documentation or diagrams that reflect my changes
[ ] New and existing unit tests pass locally with my changes
[ ] My code follows Airbnb React Style Guidelines

API Development Changes

[ ] N/A
[x] I have performed a self-review of my own code
[ ] My code follows standards and practices outlined in the BC Government API Development Guidelines
[ ] New and existing unit tests pass locally with my changes
[ ] My changes includes Swagger documentation updates that reflect the changes I am introducing

Make sure to click "resolve conversation" when you've addressed feedback and it's been confirmed.
It also looks like we've got some merge conflicts, so lets get those addressed before we merge to main. If you need help with doing so, message me and we can do it over a call.


Failure to extract dependencies to ~/.pex/install if they already exist with some Python version

Specifically on a host running Python 2.7.5 we ran into the following stack trace:
Traceback (most recent call last):
  File ".bootstrap/_pex/pex.py", line 309, in execute
  File ".bootstrap/_pex/pex.py", line 78, in _activate
  File ".bootstrap/_pex/environment.py", line 132, in activate
  File ".bootstrap/_pex/environment.py", line 176, in _activate
  File ".bootstrap/_pex/environment.py", line 121, in update_candidate_distributions
  File ".bootstrap/_pex/environment.py", line 107, in load_internal_cache
  File ".bootstrap/_pex/environment.py", line 95, in write_zipped_internal_cache
  File ".bootstrap/_pex/util.py", line 177, in cache_distribution
OSError: [Errno 17] File exists

In this case we're on a slightly older version of pex, line 177 in util.py is: https://github.com/pantsbuild/pex/blob/ba58a854d561dcf6963c0097cad544bfe2861c5a/pex/util.py#L177
So, the rename fails because the directory exists. In this case it's raising EEXIST, whereas pex only expects ENOTEMPTY to be a continuable error code.
Pex should handle EEXIST with the same behavior as ENOTEMPTY in this case.

tl;dr if you're catching the exception, use the broader OSError and discover why it happened yourself.  Error code returned in e.errno is filesystem-dependent and unreliable.
Python invokes system calls, in the case of os.rename(), that's rename(2) (see man 2 rename). This will trigger the behavior that os.rename() does:
mkdir from to
touch from/contents to/contents
strace mv -T from to

OSError will reflect in its errno  attribute whatever the operating system (kernel) reports back when the C library invokes rename(2), but this is filesystem-dependent. In the case of NFS on CentOS 5, or XFS on CentOS 7 running a stock kernel, it can be EEXIST, which is error 17.
lstat("from", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("to", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rename("from", "to")                    = -1 EEXIST (File exists)

ext3 on CentOS 5 running kernel 3.10, may raise ENOTEMPTY (error 39), like util.py catches: https://github.com/pantsbuild/pex/blob/ba58a854d561dcf6963c0097cad544bfe2861c5a/pex/util.py#L177
lstat("from", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("to", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rename("from", "to")                    = -1 ENOTEMPTY (Directory not empty)

Anyway, you'll want a more robust approach that is kernel and filesystem agnostic.

it'd be great to get your repro for this. afaict, this is actually a race condition vs a simple pex bug.
there is logic in: https://github.com/pantsbuild/pex/blob/ba58a854d561dcf6963c0097cad544bfe2861c5a/pex/util.py#L167


WARNING non stop errors in searching some stars (e.g: HR1996)

try:
pixels = lk.search_targetpixelfile('HR1996').download_all()
pixels = lk.search_targetpixelfile('HIP31592').download_all()
Problem:
WARNING: The following header keyword is invalid or follows an unrecognized non-standard convention:
C
??s&????????$???m? [astropy.io.fits.card]????z???\I???
WARNING:astropy:The following header keyword is invalid or follows an unrecognized non-standard convention:
C
??s&????????$???m????C??g???;????????$???????z???\I???
Environment:

platform (OSX - Python 3.6.4):
lightkurve==1.0b29
installation method (pip):

@saeedm31 Many thanks for reporting!  I'm sorry to hear you are encountering this problem.  We are going to try to look into this asap.

I seem unable to reproduce this issue (cf. screenshot below).  My best guess is that the error is caused by the presence of a corrupt file in the download cache.
@saeedm31 Would you be willing to try removing the contents of ~/.lightkurve-cache and/or ~/.astropy/mastDownload in your home directory, try again, and let us know if that resolves the issue?  Thanks+++!
Screenshot from my attempt:

@barentsen Thank you very much for your prompt reply and support. Your solution solved the issue.

@saeedm31 No problem!  We need to modify Lightkurve to produce a clear error message when this type of problem occurs!

@barentsen Is there a way to call these files inside ~/.lightkurve-cache (*.fits files) and use lightkurve functions ? (and not download every time searching for a target) ? Thanks

@saeedm31 I would recommend downloading the files once and explicitly storing them in a directory of your choice.  Here is example code to do this for Kepler-10:
import lightkurve as lk
tpfs = lk.search_targetpixelfile("Kepler-10").download_all()
for tpf in tpfs:
    filename = os.path.basename(tpf.path)
    tpf.to_fits("/your/custom/directory/" + filename)

In the future we will hopefully improve our caching mechanism so that search_targetpixelfile is much faster for previous queries, but that is not the case yet.

@saeedm31 Actually, perhaps an easier solution is to do this:
import lightkurve as lk
MYDIR = "/your/favorite/directory"
lk.search_targetpixelfile('kepler-10').download_all(download_dir=MYDIR)
for filename in glob.glob(MYDIR+"/**/*fits*", recursive=True):
    tpf = lk.open(filename)

Thank you very much @barentsen . "tpf = lk.open(filename)" is exactly what I was looking for because then you can use the functions of light-curve analysis inside lk.

Over on #512 we have now merged an enhancement which ensures that a more-informative error message is shown when a corrupt file is present in the cache.
Thanks again for reporting this issue.  Feel free to open new issues if you have any questions or encounter new issues!  I think this one can be closed!