text:
Reference file is wrong on option analyzer/skipExcluded

Reference configuration file at https://github.com/oss-review-toolkit/ort/blob/7315bb3c065555fc0429055d41e57451eb1de134/model/src/main/resources/reference.yml
states that we can use skipExcluded: true in config.yml, but when trying it we get the following error:
Exception in thread "main" com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "skip_excluded
" (class org.ossreviewtoolkit.model.config.AnalyzerConfiguration), not marked as ignorable (5 known properties: "sw360_configu
ration", "allow_dynamic_versions", "disabled_package_managers", "enabled_package_managers", "package_managers"])
 at [Source: (File); line: 57, column: 6] (through reference chain: org.ossreviewtoolkit.model.OrtResult["analyzer"]->org.ossr
eviewtoolkit.model.AnalyzerRun["config"]->org.ossreviewtoolkit.model.config.AnalyzerConfiguration["skip_excluded"])
        at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:61)
        at com.fasterxml.jackson.databind.DeserializationContext.handleUnknownProperty(DeserializationContext.java:1127)
        at com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty(StdDeserializer.java:2023)
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty(BeanDeserializerBase.java:1700)
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperties(BeanDeserializerBase.java:1650)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:540)
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase
.java:1405)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
        at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:542)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapping(BeanDeserializer.java:564)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:439)
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase
.java:1405)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
        at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:542)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapping(BeanDeserializer.java:564)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:439)
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase
.java:1405)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
        at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java
:323)
        at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4674)
        at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3514)

org.ossreviewtoolkit.model.config.AnalyzerConfiguration["skip_excluded"]

This looks like you were using skip_excluded instead of skipExcluded, could this be?
Because we have actually a test in place that ensure reference.yml can be parsed:
https://github.com/oss-review-toolkit/ort/blob/eb34b0dd11ee08ddbb537aa3c7eb54ecb7ff5bd7/model/src/test/kotlin/JsonSchemaTest.kt#L82-L89

This looks like you were using skip_excluded instead of skipExcluded, could this be?

Nope, I'm indeed using skipExcluded. Note that all options in that log use snake cake [1] whereas they should be camel case according to the reference file. But (and I double-checked) the config file used here really uses skipExcluded.
[1] (5 known properties: "sw360_configuration", "allow_dynamic_versions", "disabled_package_managers", "enabled_package_managers", "package_managers"])

I'm clueless as
./gradlew :cli:run --args="config --check-syntax ../model/src/main/resources/reference.yml"

also passes. Can it be that you're using an ORT version before  eb09951d8b28d19be52f8ea29e8998ac3278265b where AnalyzerConfiguration.skipExcluded was introduced about two weeks ago?

I pulled from ort/main around 9am CET, this morning.

And the rebuild of your Docker image also went fine this time? 😉 Please verify the version output of your running ORT.

genie.infra@ortstaging-vm1:/ort/ort$ docker run ort --version
eb34b0dd11-dirty

Oh, interestingly, the error keeps happening even after removing skipExcluded from the config.yml file.
So it might well having nothing to do with the skipExcluded of the reference file - but then, where would that come from?

Link to a public Jenkins job where the error happens: https://foundation.eclipse.org/ci/infra/job/ort/job/Staging/job/staging_run_ort/765/console

Looking at the reference chain again:

through reference chain: org.ossreviewtoolkit.model.OrtResult["analyzer"]

So this happens when reading an ORT result file, not when reading the ORT config file. So maybe you've created an ORT result file with a contained analyzer result (and analyzer configuration), and then you're further processing this result on another build node that has a loewr version of ORT installed, that cannot yet parse skipExcluded as part of the ORT result file.

Ouch, it's becoming tricky. I don't see how this could happen. I execute this on a single host.
The error happens on the staging host (executed from Jenkins w/ a single node, or directly on the host), and all steps of the run_ort.sh script should use the same Docker image, right? I'll rm all docker images but the latest one and retry it.

Oh wait, both servers (prod, old ort, and staging, new ort) use the same Postgres server/db for their storage.
Does that mean that the Postgres DB has to be reinitialised when upgrading with this breaking change, or that we cannot mix different ort instances in the PG DB? That would explain it all..

Are you also storing analyzer results (not just scan results) in the DB?

I think I'm storing only scanner results (all storages are defined under ort/scanner in config.yml).

Yes, unless you're explicitly using UploadResultToPostgresCommand, analyzer results don't end up in the DB, and the DB does not have to be reinitialized.

Does eb34b0dd11-dirty mean that it's not eb34b0dd11 but some un-commited changes on top?
If so, maybe it's worth using a non-dirty version and verify again.

Here's some more context from the log:
Writing analyzer result to '/output/analyzer-result.json'.
14:26:15.280 [main] INFO  org.ossreviewtoolkit.cli.commands.AnalyzerCommand - Wrote ORT result to 'analyzer-result.json' (0.30 MiB) in 449.990072ms.
The analysis took 26.618897436s.
Found 2 project(s) and 223 package(s) in total (not counting excluded ones).
Applied 0 curation(s) from 3 provider(s).
Resolved issues: 0 errors, 0 warnings, 0 hints.
Unresolved issues: 0 errors, 1 warning, 0 hints.

real	0m31.670s
user	0m0.063s
sys	0m0.069s
* Finish analyzer at 2023-02-16 14:26

* Updating .ort.yml file at [/ort/eclipsefdn-ort/conf/repositories/ecd.che/che/].
Exception in thread "main" com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "skip_excluded" (class org.ossreviewtoolkit.model.config.AnalyzerConfiguration), not marked as ignorable (5 known properties: "sw360_configuration", "allow_dynamic_versions", "disabled_package_managers", "enabled_package_managers", "package_managers"])
 at [Source: (File); line: 57, column: 6] (through reference chain: org.ossreviewtoolkit.model.OrtResult["analyzer"]->org.ossreviewtoolkit.model.AnalyzerRun["config"]->org.ossreviewtoolkit.model.config.AnalyzerConfiguration["skip_excluded"])
	at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:61)
	at com.fasterxml.jackson.databind.DeserializationContext.handleUnknownProperty(DeserializationContext.java:1127)
	at com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty(StdDeserializer.java:2023)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty(BeanDeserializerBase.java:1700)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperties(BeanDeserializerBase.java:1650)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:540)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1405)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:542)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapping(BeanDeserializer.java:564)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:439)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1405)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
	at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:542)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapping(BeanDeserializer.java:564)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:439)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1405)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
	at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4674)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3514)
	at org.ossreviewtoolkit.helper.utils.UtilsKt.readOrtResult(Utils.kt:367)
	at org.ossreviewtoolkit.helper.commands.repoconfig.GenerateScopeExcludesCommand.run(GenerateScopeExcludesCommand.kt:61)
	at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:198)
	at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:211)
	at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:211)
	at com.github.ajalt.clikt.parsers.Parser.parse(Parser.kt:18)
	at com.github.ajalt.clikt.core.CliktCommand.parse(CliktCommand.kt:400)
	at com.github.ajalt.clikt.core.CliktCommand.parse$default(CliktCommand.kt:397)
	at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:415)
	at com.github.ajalt.clikt.core.CliktCommand.main(CliktCommand.kt:440)
	at org.ossreviewtoolkit.helper.HelperMainKt.main(HelperMain.kt:67)

* Start scanner at 2023-02-16 14:26
docker run -v /data/results/ecd.che/che/202302161425:/output -v /data/cache/ort/:/ort_cache/ -v /ort/eclipsefdn-ort/conf:/home/ort/.ort/config/ --rm -e JAVA_OPTS=-Xmx10g --env-file /ort/eclipsefdn-ort/run_env.txt ort --info scan -f JSON --scanners ScanCode -i /output/analyzer-result.json -o /output

So the UnrecognizedPropertyException occurs after writing the analyzer result but before running the scanner. Now the big question is: What command you running in between there, @borisbaldassari?

@sschuberth Well done! I had almost forgotten about this intermediate step. For infrmation, it was recommended by tsteenbe to improve the analysis scope, and I have to admit I didn't see the format change coming and forgot to update the binaries. The problem seems to have vanished, as far as I can see. I'll close this issue now.
Thanks a lot for the hint!

authors: borisbaldassari fviernau sschuberth

repo: oss-review-toolkit/ort


text:
Issue 43: Implementing Card View for Recently Used Manifest Dropdown

Issue #43
What is done:

Added functions that will fetch details of a manifest, generate a card for a given manifest, generate the list of saved manifests, and toggle the dropdown visibility and render cards.

What remains unresolved:

proper implementation of these functions into tools.html.

Next Steps:

Implementing these functions in manifestStorage.js into the tools.html dropdown script.

Fully implemented the card-view as intended. I need more manifest links to test my work to ensure card-view works as intended.
Screenshot of rerum playground with card-view:

screenshot of the tested manifest to demonstrate correct metadata is displayed:

source: gharchive/pull-request

repo: oss-slu/rerum-playground

license: MIT

license_type: permissive

license_source: github-api


text:
Repair NPM namespace issues after Reversing Labs import

Fixes #555.
For reports for previously unreported NPM packages, the reports have been moved to the correct location.
TBD: reports that overlap with existing NPM packages

This PR is broken. I discovered some issues with my existing approach, and I need to repeat this work.

repo: ossf/malicious-packages


text:
scorecard seems to create the "/tmp/repo*" directories it doesn't remove

I ran scorecard quite a few times and at some point bash started to complain that it could't autocomplete commands due "no space left on device". I removed all the "/tmp/repo" directories manually but it would be great if scorecard could delete its temporary files itself. As far as I can see, it keeps at least two repositories there: the repository of projects passed via the "repo" flag and the OSS-Fuzz repository:
48818  scorecard          8   0 /tmp/repo4045678267/githubrepo1466773899.tar.gz
48818  scorecard          8   0 /tmp/repo4045678267/githubrepo1466773899.tar.gz
48818  scorecard          9   0 /tmp/repo4045678267/.clang-format
48818  scorecard          9   0 /tmp/repo4045678267/.ctags
48818  scorecard          9   0 /tmp/repo4045678267/.dir-locals.el
48818  scorecard          9   0 /tmp/repo4045678267/.editorconfig
48818  scorecard          9   0 /tmp/repo4045678267/.gitattributes
48818  scorecard          9   0 /tmp/repo4045678267/.github/FUNDING.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/ISSUE_TEMPLATE/Bug_report.md
48818  scorecard          9   0 /tmp/repo4045678267/.github/ISSUE_TEMPLATE/Feature_request.md
48818  scorecard          9   0 /tmp/repo4045678267/.github/dependabot.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/labeler.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/build_test.sh
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/build_test.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/cifuzz.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/codeql-analysis.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/coverity.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/labeler.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/linter.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/mkosi.yml
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/test_mkosi_boot.py
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/unit_tests.sh
48818  scorecard          9   0 /tmp/repo4045678267/.github/workflows/unit_tests.yml
...
48818  scorecard         11   0 /tmp/repo4167035271/projects/swift-protobuf/Dockerfile
48818  scorecard         11   0 /tmp/repo4167035271/projects/swift-protobuf/build.sh
48818  scorecard         11   0 /tmp/repo4167035271/projects/swift-protobuf/project.yaml
48818  scorecard         11   0 /tmp/repo4167035271/projects/systemd/Dockerfile
48818  scorecard         11   0 /tmp/repo4167035271/projects/systemd/build.sh
48818  scorecard         11   0 /tmp/repo4167035271/projects/systemd/project.yaml
48818  scorecard         11   0 /tmp/repo4167035271/projects/syzkaller/Dockerfile
48818  scorecard         11   0 /tmp/repo4167035271/projects/syzkaller/build.sh
48818  scorecard         11   0 /tmp/repo4167035271/projects/syzkaller/project.yaml

@azeemsgoogle FYI

It would be great if scorecard could also react to SIGTERM and SIGINT (Ctrl-C)

source: gharchive/issue

authors: evverx laurentsimon

repo: ossf/scorecard


text:
BUG: Code-review check result is wrong

Hello Team,
I see that the code review check is not providing the right result,

{
"Details": [
"found pr with committer different than author: 1",
"found pr with committer different than author: 2",
"found pr with committer different than author: 9",
"found pr with committer different than author: 33",
"Gerrit code reviews found for 0 commits out of the last 30",
"Prow code reviews found for 0 commits out of the last 4"
],
"Score": 10,
"Reason": "GitHub code reviews found for 4 commits out of the last 4 -- score normalized to 10",
"Name": "Code-Review"
},

Here the pr number 33 is having bhuvi11 as the author and committer, but it is mentioned as different.
Why is it so?
PR for reference

https://github.com/bhuvi11/ecom-service/pull/33/commits

Thanks in advance

The GitHub API returns the committer of the PR as null which leads to Scorecard recognizing author and committer as different. Giving a score of 10 here seems like the wrong behavior. @laurentsimon this is an interesting corner case to look into.

@bhuvi11 thanks for the report!
Can you give me the steps to reproduce the problem (and how the PR was merged)? Example:

Create a branch on the same repo
XXX
etc

I need to figure out why the committer is null and whether we can tweak the message/score.

Hello @laurentsimon,
Sure

I have created a branch called testing
I made a change
I raised a PR and merged it with master

Pull request :

https://github.com/bhuvi11/ecom-service/pull/40

Branch successfully merged

Hello @laurentsimon,
Thanks a lot for the response.
What is that i need to do?

@azeemsgoogle recently updated this code with GraphQl. It may have fixed the problem. Can you run check if the changes have fixed the problem?

Hello @laurentsimon,
I just ran and got this as my result
{
"details":[
"Info: Gerrit code reviews found for 0 commits out of the last 30",
"Info: Prow code reviews found for 0 commits out of the last 5"
],
"score":10,
"reason":"GitHub code reviews found for 5 commits out of the last 5 -- score normalized to 10",
"name":"Code-Review"
}
I believe i got score 10 because code review were done for all the commits? So it is a good case right ?

I think that's incorrect, because you reviewed your own commits.  @azeemsgoogle is there a way to fix this with codeQL? (the value seems to be returned by the server https://github.com/ossf/scorecard/blob/main/clients/githubrepo/graphql.go#L151)

Hello @laurentsimon , So this issue is resolved?

I don't think so. @laurentsimon could you please look into this?
./scorecard --repo=bhuvi11/ecom-service --checks=Code-Review
Starting [Code-Review]
Finished [Code-Review]

RESULTS
-------
Aggregate score: 10.0 / 10

Check scores:
|---------|-------------|--------------------------------|------------------------------------------------------------------------------------------------------------|
|  SCORE  |    NAME     |             REASON             |                                         DOCUMENTATION/REMEDIATION                                          |
|---------|-------------|--------------------------------|------------------------------------------------------------------------------------------------------------|
| 10 / 10 | Code-Review | GitHub code reviews found for  | https://github.com/ossf/scorecard/blob/aa93ac232925102ff71023081932f8630778d2bf/docs/checks.md#code-review |
|         |             | 5 commits out of the last 5 -- |                                                                                |
|         |             | score normalized to 10         |                                                                                |
|---------|-------------|--------------------------------|------------------------------------------------------------------------------------------------------------|


text:
使用Release的srs-2.0-r2版本演示页面脚本错误

CentOS6.9，使用的srs-2.0-r2版本，按照wiki里说的运行demo后，出现了以下两个截图所示的问题。

chrome要先允许flash权限

我昨天也遇到了这个问题。。。
Chrome禁用了flash。

Fixed。

authors: XiaoWind canglongxiang ntnyq winlinvip

repo: ossrs/srs


text:
Change velocity timestamp format to u64

This PR remove the dependency on chrono just uses u64s to keep track of the velocity timestamps internally. You could still use chrono for this externally and pass the result of the timestamp_millis() function into the update function. Keep in mind that it has to be greater than 0 (after epoch) and hence an u64 instead of and i64.
I also fixed some things for which I got yelled at by clippy.

LGTM, haven't tested, please double check everything works. Thanks for the contribution 😉

There we go :)

@chmanie Also the example surrounding the Angular velocity stuff also needs a quick change, now that we are using a u8 instead of an enum

Oh sorry for not giving you a heads-up. I removed that commit again after our last discussion off-thread. Sensitivity is still an enum.

authors: chmanie ostenning

repo: ostenning/rotary-encoder-embedded


text:
Use diffids - fix pulling from containers-storage:

We fetch by blob right now, which doesn't work for containers-storage.
We need https://github.com/containers/skopeo/pull/1495 to fetch the config blob, then the pull code should use it.

Alternatively the proxy could expose LayerInfosForCopy, to be closer to what the c/image/copy code does and assumes.
(Admittedly LayerInfosForCopy is a wart that shouldn’t exist in the first place… between exposing that and hard-coding containers-storage: in clients, I find it hard to decide which one I dislike more :) )

Just noting that https://github.com/RishabhSaini is planning to look at this

I'd second the suggestion to expose and use LayerInfosForCopy(), and then add LayerInfos() to it as well.
A v2s1 image isn't going to have any DiffID values in the OCI-format config blob that is synthesized for it (observe: skopeo inspect --config docker://registry.k8s.io/pause:3.0), so reading the config and assuming that the DiffID values it contains can be used as suitable input values for GetBlob() is not always going to work.
LayerInfos() and LayerInfosForCopy() can supply the set of values that GetBlob() is prepared to be asked for.

Add a proxy API to serialize the result of LayerInfosForCopy (if returns nothing, call GetLayerInfos)
We can probably directly just call json.Marshal on this and have it work (but it'd be better to add json tags to the struct most likely)
We can call GetBlob on these digests, filtering out the blobs (compressed) that we already have.
We may need to store the uncompressed blob ID in the ostree commit that stores the blob to make this more efficient

authors: cgwalters mtrmac nalind

repo: ostreedev/ostree-rs-ext


text:
I'd like to contribute a PDF icon

I'd like to contribute an icon for PDF file types. I found the code where you're switching based on file extension, but I don't know how the icon(...) function converts that to an actual icon graphic. Is there a VSTS-provided library that implements that?
If you can point me in the right direction I'd be happy to submit a PR.
Thanks!

I was getting my icons from https://developer.microsoft.com/en-us/fabric#/styles/icons
Adding their pdf icon.

Thank you!!

authors: LarsKemmann ostreifel

repo: ostreifel/Attachments-Group


text:
Duplication de contenu : la catégorie n'est pas conservée

J'ai rencontré ce soucis sur Communication Publique. Certains articles font partie de la catégorie "Exclusivement en papier".
Quand je duplique un de ces articles, la catégorie n'est pas cochée sur le nouvel article.

Merci !

J'ai remarqué également que le ou les auteur(s) ne sont pas conservés nons plus lors de la duplication.
Autre chose, quand on dupliqué, le slug est repris avec -1 à la fin, c'est très bien. Mais urn fois qu'on a changé le titre de la publication, il faut taper le slug à la main pour le changer, avec toutes les erreurs que ça implique.
Serait il possible d'avoir un bouton de rafraîchissement du slug en fonction du titre actuel ? Juste à côté du champ slug ou dessous ?

Hello @OpusInternet ! Merci pour tes retours, je vais voir pour la manière de rafraîchir le champ du slug. Par contre, pour la partie auteurs, je pense qu'à la duplication, ils ne devraient pas être repris à l'identique, mais plutôt d'avoir en auteur la personne qui a dupliqué, qu'en penses-tu ?

Hello @OpusInternet ! Merci pour tes retours, je vais voir pour la manière de rafraîchir le champ du slug manuellement. Par contre, pour la partie auteurs, je pense qu'à la duplication, ils ne devraient pas être repris à l'identique, mais plutôt d'avoir en auteur la personne qui a dupliqué, qu'en penses-tu ?

Pour les auteurs, je ne pense pas que ça soit important de le reprendre de toutes façons. En ce moment je duplique des articles pour garder les éléments qui le composent mais je change l'auteur à chaque fois (mais ce n'est jamais moi)...

authors: OpusInternet SebouChu arnaudlevy

repo: osunyorg/admin


text:
Quay Image Registry: An error occurred loading TLS: No public key provided for HTTPS. Server falling back to HTTP.

When following the instructions from https://github.com/quay/quay/blob/master/docs/getting_started.md#build-the-quay-configuration-via-configtool i get this error
» podman run --rm -it --name quay_config -p 8443:8443 quay.io/projectquay/quay config secret

config-editor stdout | time="2021-07-09T19:11:54Z" level=warning msg="An error occurred loading TLS: No public key provided for HTTPS. Server falling back to HTTP."
config-editor stdout | time="2021-07-09T19:11:54Z" level=info msg="Running the configuration editor with HTTP on port 8080 with username quayconfig"

Not sure what causers that. netstat says that ports are free. Firewalld ports are not blocked. Network is reachable within container itself. Sample Nginx container runs just fine so it's most likely some outdated documentation of Quay or who knows what else.
Also not sure why they are using escalated privileges to run quay_config container.

I believe these instructions are taken from this video i just found https://youtu.be/DdSVgSopdJM

Found this docker-compose file which also includes Clair for image scanning https://github.com/quay/quay/commit/113ccebbbfea827e959630be312ef8347e7a7c48

Quay-registry container is in reboot loop

https://docs.projectquay.io/deploy_quay.html#_overview

I think there is an issue with play kube volume mounts.

At this point i have failing TLS. HAProxy is configured to handle TLS and i am pointing back-end to the http 9981 port.

Solution to TLS issue was a simple change in config PREFERRED_URL_SCHEME: https to http.

Also keep in mind that instead of using @qui-gon image tag i was using @latest tag. qui-gon is more than one year old image ATM.

Now instead of running this container separately i need to run it inside the pod.

repo: oswee/prime


text:
tag一覧ページの遷移でfirstPostのエラーにより遷移できず

唯一「easy-notion-blog_最新情報」というタグが10件以上あるので確認してみると、
ページへ移動するボタンの表示がされない状態でした。
開発画面上では問題ないです。
vercelでは怒られてしまいます....。
以下のようなエラーメッセージがタグ毎に表示される状態です。

もしかすると取り込み漏れもあるかもしれません。(改造してますし...)
何か手がかりがありましたら教えていただけるとありがたいです。(´ﾟдﾟ｀)

#79

ブランチ....
このmargeのコードです。
(この回答でよかったですか？？)

main ブランチで起きているということですね。承知しました。

リポジトリを見た感じ main でなくて master でしたね。

easy-notion-blog の不具合だったので https://github.com/otoyo/easy-notion-blog/pull/83 の差分を取り込んでみてください。

私のリポジトリのブランチのことでしたか....
勘違いしておりました(；・∀・)
無事Vercel通過しました！！！！

お手上げ状態だったので助かりました！！！
ありがとうございますm(_ )mm( )mm( _)m

解決して良かったです。

authors: herohoro otoyo

repo: otoyo/easy-notion-blog


text:
压力测试报错

STACK_TRACE=java.lang.ArrayIndexOutOfBoundsException: length=11; index=-1 	at android.util.SparseArray.keyAt(SparseArray.java:280) 	at com.oushangfeng.pinnedsectionitemdecoration.callback.OnItemTouchListener.shouldIntercept(OnItemTouchListener.java:144) 	at com.oushangfeng.pinnedsectionitemdecoration.callback.OnItemTouchListener.access$400(OnItemTouchListener.java:17) 	at com.oushangfeng.pinnedsectionitemdecoration.callback.OnItemTouchListener$GestureListener.onDoubleTap(OnItemTouchListener.java:225) 	at android.view.GestureDetector.onTouchEvent(GestureDetector.java:563) 	at com.oushangfeng.pinnedsectionitemdecoration.callback.OnItemTouchListener.onInterceptTouchEvent(OnItemTouchListener.java:84) 	at android.support.v7.widget.RecyclerView.dispatchOnItemTouchIntercept(RecyclerView.java:2572) 	at android.support.v7.widget.RecyclerView.onInterceptTouchEvent(RecyclerView.java:2618) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2212) 	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2669) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2301) 	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2669) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2301) 	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2669) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2301) 	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2669) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2301) 	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2669) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2301) 	at android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:2669) 	at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2301) 	at com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:411) 	at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1810) 	at android.app.Activity.dispatchTouchEvent(Activity.java:3061) 	at com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:373) 	at android.view.View.dispatchPointerEvent(View.java:10234) 	at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:4447) 	at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:4308) 	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:3855) 	at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:3908) 	at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:3874) 	at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:4001) 	at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:3882) 	at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:4058) 	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:3855) 	at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:3908) 	at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:3874) 	at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:3882) 	at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:3855) 	at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:6225) 	at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:6199) 	at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6160) 	at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:6328) 	at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:185) 	at android.os.MessageQueue.nativePollOnce(Native Method) 	at android.os.MessageQueue.next(MessageQueue.java:323) 	at android.os.Looper.loop(Looper.java:151) 	at android.app.ActivityThread.main(ActivityThread.java:6077) 	at java.lang.reflect.Method.invoke(Native Method) 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)

没设置头部view需要点击的id？？？

@oubowu 我不需要监听头部点击事件的,用的地方
mRv.addItemDecoration(new PinnedHeaderItemDecoration.Builder(R.integer.type_header).enableDivider(false).create());

authors: nicelyjust oubowu

repo: oubowu/PinnedSectionItemDecoration


text:
任务添加的节点数量有限制吗

任务添加的节点数量有限制吗，添加了7个节点，只运行前6个

节点数过多，数据表 ouqiang_task_log.hostname 内容超出
2020-08-13/21:56:17 [ERR] [[任务开始执行#写入任务日志失败- Error 1406: Data too long for column 'hostname' at row 1]]
2020-08-13/21:58:46 [ERR] [[任务开始执行#写入任务日志失败- Error 1406: Data too long for column 'hostname' at row 1]]
修改了该字段
ALTER TABLE ouqiang_task_log MODIFY  hostname text NOT NULL ;

repo: ouqiang/gocron

license: mit

license_source: bigquery


text:
Unknown proposal type error

https://sentry.io/organizations/oursky/issues/3561335216/?project=6602127&query=is%3Aunresolved

Note:

should be proposal 55 https://bigdipper.live/likecoin/proposals/55
proposals:/ibc.core.client.v1.ClientUpdateProposal
The original dao site don't support it either

authors: hochiw mitchellchou

repo: oursky/likedao


text:
build page of our world nomads website

[x] copy images and texts from ai file
[x] create your own branch development_name
[x] build homepage
[x] build location page
[x] build co-owns page
[x] hand in to ops to be build the website, ask kristof which domain he prefer / to buy

all pages built on https://nomads.ourworld.tf/

all pages are not complete yet @sasha-astiadi. I'm still gathering content for the co-own page.

authors: remrekoc sasha-astiadi


text:
Provide an example of "JSON mode"

Outlines can provide "JSON mode" using the JSON Lark grammar. We should add an example in the documentation (a cookbook) that demonstrates how to do it.

Hey, I'm really curious; how do you do this?

authors: remiconnesson rlouf

repo: outlines-dev/outlines


text:
Update sbt to 1.9.1

About this PR
📦 Updates org.scala-sbt:sbt from 1.6.2 to 1.9.1
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-sbt", artifactId = "sbt" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #103.

repo: outr/perfolation


text:
Git clone via HTTPS instead of SSH in readme

HTTPS is default method of cloning on GitHub as it works without having configured keys on the machine

Thanks

authors: PetrHeinz outsideris

repo: outsideris/slack-invite-automation


text:
微信支付存在问题

我用的环境
PHP 版本：7
overtrue/wechat 版本：~3.0 laravel
问题及现象
当我使用WeixinJSBridge，直接生成js配置的时候，前端调用支付，提示缺少timeStamp
检查源码发现
    public function configForJSSDKPayment($prepayId)
    {
        $config = $this->configForPayment($prepayId, false);

        $config['timestamp'] = $config['timeStamp'];
        unset($config['timeStamp']);

        return $config;
    }

中，对timestamp进行了转换？把转换去掉之后，可以正常调用组件，是否这里是否存在问题呢，还是我调用本身就有问题？

@JKair 请认真阅读文档：https://easywechat.org/zh-cn/docs/payment.html#生成支付-JS-配置

JSBridge 却用生成的 JSSDK 配置，不错才怪。

老眼昏花，哈哈哈，抱歉 @overtrue  @tianyong90

authors: JKair overtrue tianyong90

repo: overtrue/wechat


text:
Eve Online Provider

I pulled @mariozski's changes from #60 into this branch and corrected some formatting problems.
All seems well to me.

Authentication works well for the "Tranquility" server. I do not have access to the "Singularity" server but according to the documentation it should work fine.
The provider is all hooked up properly - you can hook into the provider to add claims and such.
I consulted the documentation and scopes are delimited properly, etc.

@jerriep, I know you are busy but I would really appreciate if you could use your experience to give this branch a quick once over in the browser before I merge into master.

Yeah, all looks good thanks

Thank you.

authors: ByteBlast jerriep

repo: owin-middleware/OwinOAuthProviders


text:
Previews via webDAV API tests fails on OCIS

Steps to reproduce

Create an user and upload an image
User downloads the preview of image file with width "32" and height "32"
e.g. curl http://172.17.0.1:9140/remote.php/dav/files/admin/testavatar.jpg\?x\=32\&y\=32\&forceIcon\=0\&preview\=1 -u admin:admin -v --output test.jpg

Expected

Preview of width "32" and height "32" should be downloaded

Actual

Preview of width and height same as the uploaded image is downloaded

While running the webDAV API test on OCIS it fails and gives output
width not as expected
Failed asserting that 1240 matches expected '32'.

"1240" is the width of the uploaded file

The previews currently only work if the requests go through the proxy (port 9200) or if the ocis-webdav service is called directly  (port 9115, but it only serves thumbnails for now the rest is still in ocis-reva)

is this because of authentication ?
so need to adjust the tests to use 9200, probably as part of https://github.com/owncloud/phoenix/issues/3601 @dpakach

No this is because currently the webdav code is seperated.
Most of it is in reva but the code related to thumbnails is in ocis-webdav.
The proxy is redirecting the requests to the correct services.

so what would be the next step to resolve this ?

Either this

so need to adjust the tests to use 9200, probably as part of owncloud/phoenix#3601

Or change the port of the preview tests to 9115.

blocked by https://github.com/owncloud/ocis-thumbnails/issues/39

@C0rby is this still the case? if not, feel free to close the issue.

@C0rby is this still the case? if not, feel free to close the issue.

Technically this should work now. I just don't know if we need to change some configuration or so.
Needs to be checked.

Technically this should work now. I just don't know if we need to change some configuration or so.
Needs to be checked.

Some context:
Requests authenticated with basic auth have to go through the oCIS proxy. There the proxy mints a JWT and puts it into the request context. This way the tests should be able to execute the tests using basic auth.

Some context:
Requests authenticated with basic auth have to go through the oCIS proxy. There the proxy mints a JWT and puts it into the request context. This way the tests should be able to execute the tests using basic auth.

It works now when oCIS is started with PROXY_ENABLE_BASIC_AUTH=true and the requests are done against the proxy

repo: owncloud/ocis


text:
Customize welcome bot

Closing Issue/Referencing Issue
issue reference (#59)
Changes Made In Pull Request

customized the welcome bot

Hey @brianabaker can you please add the upstream and take the updated version of this repo, then push to your forked branch.
Also can you please edit 'newPRWelcomeComment'? It is showing non Github-Markdown supported characters

Fixed newPRWelcomeComment and synced my repo with upstream.

Thanks a lot. It looks great now.

https://github.com/ows-ali/Hacktoberfest/pull/99
Good work :)

authors: brianabaker ows-ali

repo: ows-ali/Hacktoberfest


text:
API / Docs feedback

(as mentioned on discord) I've been working on migrating a project from some custom resolution logic to oxc-resolver. Here's some feedback about my experience so far:
path argument
There are no docs describing the public API of the crate - the page for the resolver just has a link to an example as the only documentation. The example includes a comment which says Path to directory, must be in absolute path.
The crate docs just say: Resolve specifier at an absolute path with no mention of the requirement that it be a folder.
I misread this in example and made the assumption that I was passing the "target" file path (the file that "owns" the dependencies) to the resolve function. This caused many resolutions to fail because the code assumes the path is a folder and does path.join(relative).
Suggestions:

Improve docs for the API
Add an error if the path passed to .resolve is a file instead of a folder

Alternately - take the .parent().unwrap() of a file automatically

extensions option
I had all my extensions configured without a leading .. This caused all my extensionless resolutions to fail because the code assumes the extension starts with a . and does concatenate(path, extension).
The docs allude to this expectation by showing the defaults as having a leading . but it does not state the requirement.
Suggestions:

Describe the assumptions in the docs
Add an error if any of the extensions passed to the config does not start with a .

Alternately - normalise the extensions to start with a .

Thank you for the feedback, there's too much assumed knowledge around these APIs. I'll fix these soon.

I'd like to add that the example shown in docs.rs isn't very beginner friendly.
It took me more than three reads to understand it, but it still confuses me when I read it after a while.
What I gathered is that the language used is very technical, and it uses terms without a glossary. A couple of things that we could improve:

a more beginner friendly introduction of the package and what it does
a small glossary that explains technical words and frames them in right context e.g. specifier, alias, etc.

authors: Boshen bradzacher ematipico

repo: oxc-project/oxc-resolver


text:
fix(ast, ast_codegen): visit decorators in Class before node events.

Closes #4142
I can split it into 2 PRs but it seems pointless. Let me know if you guys disagree with me.

#4147  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rzvxa and the rest of your teammates on  Graphite

Please see https://github.com/oxc-project/oxc/issues/4142#issuecomment-2219125356. I'm not clear why this change is required.

Please see #4142 (comment). I'm not clear why this change is required.

I just saw your comment, Even with that it is a good thing to have the visit(enter_before) marker just in case we need it in the future. I can just remove the marker from Class and merge the generator code.

@Dunqing do you know about the semantic details here?

@Dunqing do you know about the semantic details here?

https://github.com/oxc-project/oxc/issues/4142#issuecomment-2219677568

I just saw your comment, Even with that it is a good thing to have the visit(enter_before) marker just in case we need it in the future. I can just remove the marker from Class and merge the generator code.

Yes, I think we can keep the visit(enter_before) marker for now. It may be useful for reimplementing the adding scope and resolving references.

Personally, I don't think we should ever enter the node late. It is just confusing, and I can't see a use case.
If you want to avoid throwing away the generator code you already wrote, by all means merge it in, but would you consider "deactivating" visit(enter_before), so we don't start using it kind of by accident without discussing first?

I'll generate an error on encountering it for now.

authors: Boshen Dunqing overlookmotel rzvxa

repo: oxc-project/oxc


text:
Wrong path conversion in url() for imported files

In this filesystem situation:
project/
|- app/... php stuff ...
|- web/
|  |- css/
|  |- img/
|  |  |- bg.png
|  |- less/
|  |  |- main.less
|  |  |- _imported.less

This is main.less:
@import "_imported";

This is _imported.less:
h1 {
  background: url(../img/bg.png);
}

Calling lessc from outside the less directory works:
cd project/
lessc web/less/main.less >web/css/main.css

Results in:
h1 {
  background: url(../img/bg.png);
}

While calling it from the less directory changes the path:
cd project/web/less/
lessc main.less ../css/main.css

Results in:
h1 {
  background: url(img/bg.png);
}

This is a problem for some auto-compile scripts and IDE integration plugins, that often work inside the less directory (as the project structure could be much more complex).
I tried several combinations of -ru and -rp without success.
In general the path conversion should not depend on from where the compiler gets called.
I am using lessc 1.7.0.2.

I have the same problem... It works as expected in 1.6.3.1

Same problem here.
I defined images dir in my vars.less:

@layout_images_dir: "../bundles/app/images/";
@img_main_bg: @layout_images_dir + "bg.png";

vars.less is included in other less file, where I want to use the @img_main_bg variable as an url for the image like this:

background-image: url(@img_main_bg);

The result is:

background-image: url("");

(This worked well with leafo lessphp)
I tried this way too:

background-image: url('../bundles/app/images/bg.png');

The result is:

background-image: url('bundles/app/images/bg.png');

I can confirm the same happens when compiling with PHP.

Same thing here. Thanks @Teyras for the tip.

After some digging I found out that relativeUrls option became false by default in v1.7.0.6, was true before.

authors: Alex-PK Teyras bladi87 mnapoli outring


text:
建议增加自动发音功能

在划词以后，如果可以播放音频，就自动发音。

划词就跳出popup在不少场景下都有些恼人，因而这个插件添加了类似的功能来关闭popup的跳出。基于这点考虑，我觉得自动发音对不少人来说也是让人心烦的特性，暂时应该不会添加该功能。
如果其他人也有类似需求的话在重开这个issue吧。

可以做成一个选项来开关这个特性。

authors: FindHao oyyd

repo: oyyd/youdao-collins-chrome-extension


text:
GUI is not accessible if debug flag is set to true

In the main window of homebridge-config-ui-x I went to settings at the top right and set debug (it was  called something like that) as enabled under Advanced. Since then homebridge-config-ui-x is no longer accessible in the browser ("no connection possible"). When I use systemctl status homebridge, I see that the service is running:
user@server:~$ ● homebridge.service - Homebridge
   Active: active (running) since Sun 2020-01-12 16:12:32 CET; 11min ago
 Main PID: 11796 (homebridge)
    Tasks: 22 (limit: 4915)
   CGroup: /system.slice/homebridge.service
           ├─11796 homebridge
           └─11816 homebridge-config-ui-x

homebridge itself is still working in the background, but not homebridge-config-ui-x.
I changed the flag in my config respectively i deleted the line "debug": true. So homebridge-config-ui-x is now working, but where is the problem with debug true?
Running:
Node.js Version: v12.14.1
homebridge-config-ui-x: v4.7.0
Ubuntu: 18.04.3 LTS

Thanks @Staubgeborener,
I was able to replicate this. It will be fixed in the next release (currently in @test).

authors: Staubgeborener oznu

repo: oznu/homebridge-config-ui-x


text:
Feature: Disable fields caching by flag

insane-json by default caches Node fields if the number of fields in it exceeds 16 (default). We want to disable this behavior by a new flag.
See insaneJSON.UseMapThreshold and Dig func for more information

Why we need this:
(allocs profile)

Prometheus allocations fixed in #411.
This issue may fix .Dig allocations.


text:
NO-TICKET - Comment withdraw temporarily

Description of Work

QA can't test bottom sheets

why?

why?

it's already in the description, QA can't test other tasks because this request cannot be perfomed correclty atm


text:
autoChangeBannerAds() causes app crash when used offline

peace be upon you bro
autoChangeBannerAds(seconds) causes app crash when used offline!

Okay, I'll take a look at the problem today. Thanks for informing me

Okay, I'll take a look at the problem today. Thanks for informing me

Fixed the issue. Now try with this:
implementation 'com.github.p32929:HouseAds2:1.0.0.16'
Feel free to let me know if you see any more bugs.

Fixed the issue. Now try with this:
implementation 'com.github.p32929:HouseAds2:1.0.0.16'
Feel free to let me know if you see any more bugs.


text:
Crashes occurring on LG devices running Android 8 and 9

There is a crash that occurs when starting multiple Harmony preferences in LG devices, specifically in Android 8 and 9.
Caused by java.util.ConcurrentModificationException
       at java.util.ArrayList$Itr.next(ArrayList.java:860)
       at android.os.FileObserver.startWatching(FileObserver.java:196)
       at com.frybits.harmony.HarmonyImpl$isLoadedTask$1.call(HarmonyImpl.java:172)
       at com.frybits.harmony.HarmonyImpl$isLoadedTask$1.call(HarmonyImpl.java:72)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at android.os.Handler.handleCallback(Handler.java:790)
       at android.os.Handler.dispatchMessage(Handler.java:99)
       at android.os.Looper.loop(Looper.java:164)
       at android.os.HandlerThread.run(HandlerThread.java:65)

This issue is reproducible on an LG device. Will work on a fix.

Crash issue fixed in #39

repo: pablobaxter/Harmony


text:
stylize doesn't support windows

I suggest to use https://pypi.org/project/clang-format/ and https://pypi.org/project/black/ (or https://pypi.org/project/yapf/ if you prefer) for formatting directly. Both can be pip installed and don't require further apt or brew installs since clang-format offers wheels with the necessary binaries.

pre-commit supports formatting with clang-format and black https://github.com/pablocael/pynear/pull/36
makefile still uses stylize however

repo: pablocael/pynear


text:
Put the current profile to the Http.Context for template access

Since CDI it is not possible to access the userprofile in a template directly because you need stuff which is handled via injection.
I worte this annotation which puts if avaible the userprofile into the Http.Context so you can access it from a template.

I added a sample in play-java-demo see pull request: https://github.com/pac4j/play-pac4j-java-demo/pull/40

OK. I see your point and that's a good idea.
That said, starting to review your PR, I realized it should already work.
After a successful authentication, the map of profiles is saved as a request attributes (https://github.com/pac4j/pac4j/blob/master/pac4j-core/src/main/java/org/pac4j/core/profile/ProfileManager.java#L113) and thus in the context (https://github.com/pac4j/play-pac4j/blob/master/src/main/java/org/pac4j/play/PlayWebContext.java#L213).
Though, when going through the SecurityFilter, the profiles are serialized. Yes, I know, it's a bit hacky ;-)
So you should have the access to the profiles (in a serialized format or not) from the context.
Thus, with the ProfileHelper.flatIntoOneProfile method, you could certainly create a static Optional<CommonProfile> getProfile(ctx) method in the PlayWebContext. It's just an example, you can have a better proposal...

Ah  nice one okay than we dont need the duplicated code so i will try your approach.

Any update on this?

Hi @leleuj looked at it and do i understand this correctly that i need to configure the security filter for this ?

Yes, the user profile is populated via the SecurityFilter / Secure annotation/function.

Closing for now. Feel free to reopen with your proposal.

authors: leleuj tuxBurner


text:
Tests framework nose no longer maintained

The nose testing library used in ffq is no longer maintained and was last updated in 2015. It doesn't work with Python 3.10 with an issue that will not be fixed.
It looks like most people have switched to pytest, and there's even an automated tool to help the conversion: nose2pytest. Is this something that would be of interest?
Phil

Ah, looks like pytest even has support for running nose tests out of the box: https://docs.pytest.org/en/7.1.x/how-to/nose.html#noseintegration

We have migrated over to pytest with the help of @lauraluebbert. See https://github.com/pachterlab/ffq/pull/36/

authors: ewels sbooeshaghi

repo: pachterlab/ffq


text:
Add module to depmap database

Request type
New module
Request description
https://depmap.org/
Example command
No response
Example return value
No response

Cool! Looking forward to this. I would like to use it in https://github.com/GilbertLabUCSF/CanDI.

Note: Some DepMap data will be accesible through gget opentargets in gget version >= 0.29.0

authors: abearab lauraluebbert

repo: pachterlab/gget


text:
bad chunk after recovering from CrashLoopBackoff

I did a weird thing and got a weird result with beta3.  I am converting a workspace from beta2 to beta3 and there were some problems with my conversion -- I set WORKER_SIDECAR_IMAGE to worker instead of pachd.  This caused the pipeline to never start successfully (crashloopbackoff because k8s couldn't run /pachd).  I fixed the config, restarted, and deleted the underlying RCs.  The RCs scaled back up but failed due to Error.  This log line in storage seemed most relevant, but isn't the cause of the crash (the last log line was an error about not being able to start the s3 gateway, which sounds spurious to me).  I'm not actually sure what actually crashed, but I can pull logs from Stackdriver if this doesn't seem problematic but the behavior does.
2021-07-23T04:08:28Z ERROR pfs.API.GetFileTAR {"duration":0.026977937,"error":"bad chunk. HAVE: 30653537353163303236653534336232653861623265623036303939646161316431653564663437373738663737383766616162343563646631326665336138 WANT: 36376163353161663836383835616437343262636237336239
346363633963333533306433363165346465366631346536386433346139363766623166316338","request":{"file":{"commit":{"branch":{"repo":{"name":"edges","type":"spec"},"name":"master"},"id":"3f72a6752ea746b99f43ddf6ddfefcd6"},"path":"spec"}},"stack":["github.com/pachyderm/pachyderm/v2/src/in
ternal/storage/chunk.verifyData\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/chunk/transform.go:193","github.com/pachyderm/pachyderm/v2/src/internal/storage/chunk.Get.func1\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage
/chunk/transform.go:58","github.com/pachyderm/pachyderm/v2/src/internal/storage/kv.(*objectAdapter).Get.func1\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/kv/obj_adapter.go:42","github.com/pachyderm/pachyderm/v2/src/internal/storage/kv.(*objectAdapt
er).withBuffer\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/kv/obj_adapter.go:68","github.com/pachyderm/pachyderm/v2/src/internal/storage/kv.(*objectAdapter).Get\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/kv/obj_ada
pter.go:35","github.com/pachyderm/pachyderm/v2/src/internal/storage/chunk.(*trackedClient).Get\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/chunk/client.go:129","github.com/pachyderm/pachyderm/v2/src/internal/storage/chunk.Get\n\t/Users/avigil/Pachy
derm/Pachyderm_releases/pachyderm/src/internal/storage/chunk/transform.go:57","github.com/pachyderm/pachyderm/v2/src/internal/storage/chunk.(*DataReader).Get\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/chunk/reader.go:74","github.com/pachyderm/pach
yderm/v2/src/internal/storage/chunk.(*Reader).Get.func1\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/chunk/reader.go:46","github.com/pachyderm/pachyderm/v2/src/internal/storage/chunk.(*Reader).Iterate\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pa
chyderm/src/internal/storage/chunk/reader.go:33","github.com/pachyderm/pachyderm/v2/src/internal/storage/chunk.(*Reader).Get\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/chunk/reader.go:45","github.com/pachyderm/pachyderm/v2/src/internal/storage/fil
eset/index.(*levelReader).setup\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/fileset/index/reader.go:164","github.com/pachyderm/pachyderm/v2/src/internal/storage/fileset/index.(*levelReader).Read\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyde
rm/src/internal/storage/fileset/index/reader.go:143","io.ReadAtLeast\n\t/usr/local/go/src/io/io.go:328","io.ReadFull\n\t/usr/local/go/src/io/io.go:347","encoding/binary.Read\n\t/usr/local/go/src/encoding/binary/binary.go:166","github.com/pachyderm/pachyderm/v2/src/internal/pbutil.
(*readWriter).ReadBytes\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/pbutil/pbutil.go:39","github.com/pachyderm/pachyderm/v2/src/internal/pbutil.(*readWriter).Read\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/pbutil/pbutil.go:57","gi
thub.com/pachyderm/pachyderm/v2/src/internal/storage/fileset/index.(*Reader).Iterate\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/fileset/index/reader.go:51","github.com/pachyderm/pachyderm/v2/src/internal/storage/fileset.(*Reader).Iterate\n\t/Users
/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/fileset/reader.go:48","github.com/pachyderm/pachyderm/v2/src/internal/storage/fileset.(*Storage).Size\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/fileset/storage.go:273","github.co
m/pachyderm/pachyderm/v2/src/server/pfs/server.(*driver).commitSize\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/server/pfs/server/driver_file.go:517","github.com/pachyderm/pachyderm/v2/src/server/pfs/server.(*driver).inspectCommit\n\t/Users/avigil/Pachyderm/Pachyde
rm_releases/pachyderm/src/server/pfs/server/driver.go:980","github.com/pachyderm/pachyderm/v2/src/server/pfs/server.(*driver).openCommit\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/server/pfs/server/driver_file.go:128","github.com/pachyderm/pachyderm/v2/src/server/
pfs/server.(*driver).getFile\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/server/pfs/server/driver_file.go:176","github.com/pachyderm/pachyderm/v2/src/server/pfs/server.(*apiServer).GetFileTAR.func3\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/server/
pfs/server/api_server.go:514","github.com/pachyderm/pachyderm/v2/src/internal/storage/metrics.ReportRequestWithThroughput.func1\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/metrics/metrics.go:68","github.com/pachyderm/pachyderm/v2/src/internal/stora
ge/metrics.ReportRequest\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/internal/storage/metrics/metrics.go:54","github.com/pachyderm/pachyderm/v2/src/internal/storage/metrics.ReportRequestWithThroughput\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/inte
rnal/storage/metrics/metrics.go:67","github.com/pachyderm/pachyderm/v2/src/server/pfs/server.(*apiServer).GetFileTAR\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/server/pfs/server/api_server.go:512","github.com/pachyderm/pachyderm/v2/src/server/pfs/server.(*validate
dAPIServer).GetFileTAR\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/server/pfs/server/val_server.go:154","github.com/pachyderm/pachyderm/v2/src/pfs._API_GetFileTAR_Handler\n\t/Users/avigil/Pachyderm/Pachyderm_releases/pachyderm/src/pfs/pfs.pb.go:4951"]}

@brycemcanally would you mind taking a look at this? The things @jrockway did aren't likely to be done by a user but the fact that it could cause a bad chunk is a little concerning.

The bad chunk error is just a sanity check in the storage layer to ensure that data isn't changing underneath us. The 30653537353163303236653534336232653861623265623036303939646161316431653564663437373738663737383766616162343563646631326665336138 hash is for empty bytes, which likely means that object storage got out of sync with what we track in Postgres. I don't think we are propagating gets that fail due to non-existence correctly, which would explain why this is the error you see. I saw the same error when we weren't mounting in the correct volume for local deploys. @jrockway did you do anything that might have affected either the object storage client setup or object storage state?

I don't think I did anything that would affect the object storage setup.  The workspace did start out as a beta2 workspace, but no data was added while beta2 was running (but, schema migrations etc. happened on beta2).  Data was probably added while the worker image tag was wrong, though.
pachd could have died at an inopportune time.  Hopefully that can't result in missing data.
I wonder if we can make a more isolated test case for this -- set the worker images to something that will crash upon startup, add data, restart pachd with valid images, see if this bug comes back.

This should be addressed by: https://github.com/pachyderm/pachyderm/pull/6651. Feel free to reopen if it is not.

authors: brycemcanally jdoliner jrockway

repo: pachyderm/pachyderm


text:
am not able to get into your slack channel

Sorry you ran into that. Give me a few minutes and I'll fix that.

Should be working again. @mwaaas

thanks

authors: JoeyZwicker mwaaas


text:
Support jsonpath spec for ObjectTemplate sources

Support full jsonpath spec for ObjecTemplate sources, allowing ranges filters, map-key access and more:
https://kubernetes.io/docs/reference/kubectl/jsonpath/

/lgtm

/lgtm

/approve

authors: garrettthomaskth thetechnick

repo: package-operator/package-operator


text:
error trying to create server

using 0.6.0:
mbp ~ → machine -D  create -d packet --packet-api-key=apikey --packet-project-id=test packet
When trying to create a server I'm getting this error:
(packet) Provisioning Packet server...
Error creating machine: Error in driver during machine creation: POST https://api.packet.net/projects/test/devices: 404 Not found
open : no such file or directory
notifying bugsnag: [Error creating machine: Error in driver during machine creation: POST https://api.packet.net/projects/test/devices: 404 Not found]

HI @pandrew your --packet-project-id must be the ID of the project, not the name of the project. The ID can be pulled down from listing projects directly from the api using your api key, or you can get it from the url on the client portal. For example, while on the device listing page for a project, in the url:
https://app.packet.net/portal#/project/THIS_IS_WHERE_THE_PROJECT_ID_IS/servers
so, your command should look something like this:
machine -D create -d packet --packet-api-key=apikey --packet-project-id=ABABABABABA-CDCD-EFEF-1212-XXXXXXXXXXX
Let me know if that doesn't work!

I don't doubt it would work but it would be easier if the project id could contain the name of the project instead of finding the id by myself. I could not find any documentation on this either. Hopefully this is something that could be resolved in a later version. Thank you for explaining.

authors: crunchywelch pandrew

repo: packethost/docker-machine-driver-packet


text:
templates reworked, so one template can contain multiple yaml sections

partially implements #61
@all
if possible perform local test deployment
@csomh i had to comment out section  name: Create redis-commander secrets in deploy.yml, it was failing because of undefined variable

MSG:
'redis_commander_user' is undefined

will fix it with your help.
redis_commander fixed

Why was the ".j2" suffix removed from template files? I found it good to have it, b/c it was easier to tell which file is a template and which one a complete OpenShift resource definition. I also think using the ".j2" suffix is an Ansible best practice, but I might be wrong.

you are right will change it

playbooks/prepare-local.yml doesn't really has anything to do with reworking the other files.
Maybe it would be good to move it to a separate commit, and maybe even to open a separate PR for it, to have better visibility. The README should be also updated if we add this.

no it is working version of ansible script i am using to prepare env variables - will remove it from  PR

@sakalosj is this still WIP?

@sakalosj is this still WIP?

no, i thought i changed it

what's the status here?

is done but waiting for @csomh approval as he had most objections

just noticed that there is also comment from @jpopelka, will remove unnecessary comments

@csomh please check and if you will find anything will handle it in new pull request

authors: TomasTomecek csomh sakalosj

repo: packit-service/deployment


text:
improve typehint coverage in utils.py

Aims to remove any strict MyPy errors from the utils.py file, relating to ticket #251

/packit copr-build

recheck

Please, rebase so we can merge that.

/packit copr-build

authors: lachmanfrantisek svenharris

repo: packit-service/ogr


text:
accept a script to generate a spec file

We are working with the Fedora kernel team now and their source-git expectation is that the kernel source-git would contain a script to generate a spec file and patches and packit would just accept it. Obviously, it would not try to generate patches itself.
More detailed workflow TBD.

Fixed in 0.3.0

repo: packit-service/packit


text:
Hi ,How to open an access database file using MDW?

Hi ,How to open an access database file using MDW, is there an example?

You would need to install an ODBC driver for Access. If you are on windows maybe one is already installed. When you need a connection string referencing the driver you installed and the file you want to open. E.g.:
Driver={Microsoft Access Driver (*.mdb)};Dbq=C:\mydatabase.mdb;Uid=Admin;Pwd=;

Searching for ODBC and Access should yield you the relevant details.

Thanks, I'll try！

Any success?

Can not see any actionalbe step I could take here. Also have successfully opened access files using odbc-api in the past. So very sure this works.

Couple of points:

What does the error message say? Could you translate it to english?
The driver you show is a 32Bit driver, accessible for 32Bit programs. Did you make sure you used a 32Bit toolchain (like stable-i686-pc-windows-msvc)? Alternatively utilize a 64Bit access driver.
The way the driver is written in your screenshot, of the ODBC datasource administrator, and in your program is different. Driver do Microsofot Access (*.mdb) vs Microsoft Access Driver (*.mdb, *.accdb). I would expect them to match.

Best, Markus

Thany you !  32bit programs


text:
rfc: RFC process

This PR proposes a request for comment (RFC) process to propose and discuss changes to the Pact specification, ecosystem and community.
The PR can be read in the rfc/rfc-process branch

Thanks Josh, this feels like a great start!

Thanks @YOU54F! I've update the text based on your comments 👍

Thanks @YOU54F! I've update the text based on your comments 👍

danke muchly

I've also tagged several other maintainers for their visibility.

Firstly, I think this is a step in the right direction so thanks for that 👍 Whilst a lot of the development happens in the open, I feel like a lot of the decision making happens in private, so anything we can do to make that more public is a good move.
With that in mind, my first question is - will everyone be taking part in this RFC process? As in will Pact Foundation and SmartBesr employees also be making changes solely via this mechanism, or is this an avenue only for those external?
My second question surrounds the areas covered vs not. It makes total sense to me that the spec is covered by this process, but other parts are less clear. For example, why is the pact CLI covered by this but something like pact-jvm isn't? To an outsider, that's an unclear distinction.
Third point - what happens when an RFC is accepted? For example, a spec change RFC is accepted - is the spec now changed? Do we publish a new version bump? Or is this just accepting the idea of making that change at some future point?
Similar with the CLI and other elements mentioned in the text - if someone says "the CLI should start doing X" and that gets accepted, what then? Obviously someone needs to actually make a code change, and if nobody does then what does accepting the RFC actually mean?
In PactNet the RFC is like the initial design discussion, and is expected to be accompanied with a PR once the design has been agreed, and only then closed. So it's an atomic single ticket that results in a code change, whereas this didn't read like it was. This felt like it was accepting a plan to make a code change somewhere else later.

@adamrodger Thanks for your feedback and for recognising this as a step in the right direction 👍. We definitely want to avoid the appearance of decision-making happening in private, and we hope this RFC process will help with that.
To answer your first question: It is my hope that all significant changes go through the public RFC process, irrespective of who is suggesting the change. This includes contributions from open source contributors and SmartBear employees alike.
Regarding your second question: I agree that this distinction can be difficult to precisely define. The reason is that we want to acknowledge that Pact is an ecosystem with many moving parts, and it isn't reasonable or practical to consolidate all changes through a single RFC pipeline. For instance, you mentioned how Pact Net has its own RFC process; I believe changes solely contained within Pact Net should continue using its own process. Similarly, if someone suggests a breaking change to Pact Python that doesn't affect other implementations, this RFC process might not be the right forum for that discussion.
Conversely, a change to the FFI or the CLI could have much broader ramifications across the ecosystem thereby justifying the need for these changes to go through the RFC process. Though even there, only changes which have these broader ramifications would require this RFC process. A refactoring of logic internal to the FFI for example would not fall within the purview of this RFC process.
I'm open to hearing your thoughts on this or any suggestions you might have on making this distinction clearer.
As for your third point: The idea, which I thought I explained in the RFC process but may need further fleshing out, is:

If the RFC is accepted, the following steps will also be taken:

Assign an RFC number based on the PR number and update the filename and metadata.
Create a tracking issue in the Pact Foundation Roadmap repository for implementing the RFC. Where applicable, other issues may be created in other repositories.

Step (1) is purely administrative. Step (2) aims to track implementation. Given the breadth of possible changes, it's not feasible for one person to implement everything across different parts of the ecosystem. It is also possible for an RFC to come from an end-user of Pact who might have a valid suggestion, but not the technical experience to implement the change.
It's always a concern that an approved change remains in limbo; however, whether it stays as an open RFC or as a tracking issue doesn’t make much difference—except that a tracking issue formally recognises that an RFC has been approved.
Looking forward to hearing more of your thoughts!

On the topic of which components are included and which aren't:
I think your explanation above is a good one, like this process covers the common elements of the ecosystem (such as the Spec and FFI) and not the language-specific parts. That does put the CLI in a bit of an awkward inbetween though. That doesn't feel like it fits the definition of a common element that affects the entire ecosystem.
I think in reality the list of things covered in this process is actually "the things maintained by SmartBear people" vs. "the the things that aren't" generally speaking (I accept it's not that clearly separated, e.g. PactJS maintained by Matt). Where those language-specific libraries are maintained by SmartBear employees then they do tend to pop up in this repo, such as #95, which is PactJS-specific.
As a non-SmartBear member of Pact Foundation, my two concerns with that are:

Marking your own homework - There are enough 'core team' Pact Foundation members that it's very easy for one to raise an RFC and multiple others to comment/approve so that the entire process is followed, yet without involving anyone from outside of that group. For someone outside the group, that's not possible. To the community at large it's unclear who is paid to maintain Pact as their job and who is a volunteer, so it's not really possible to spot when this might happen.
Tail wagging the dog - There have been times where the reference implementation doesn't follow what the spec says, and then instead of changing the implementation the spec is updated to match what the implementation does (without any version bump or anything either). This effectively means that the spec can be de-facto updated by proxy. This is especially concerning for library maintainers because then users point to the spec and say you're not compliant, but once upon a time you were.

On the topic of what happens after an RFC is accepted:
I get the difficulty here. We want the RFC list to act as a decision log, and for that the designed process looks fine to me. However, accepting an RFC doesn't actually make that change happen, and it's unclear from reviewing the decision log which ones have and haven't been implemented. Perhaps some kind of extra tracking information needs to be added and maintained there? Like if we're going to raise tickets in other repos to actually implement a decision, the original 'umbrella' RFC should track its own progress against those tickets.
One problem with that approach is that you can get something partially implemented. For example, if we went back in time to before plugins existed then you'd expect that to have gone through an RFC process because it's a wide-reaching change. However, plugin support is still patchy across the ecosystem (generally it's implemented in the core team maintained libs, and not in the volunteer-maintained ones). So what does that mean for the RFC? Is it done? Partially done?
I think if I were an external user that went to the effort of raising an RFC and then it was accepted, that kinda feels like a promise being made to implement that change. If we get to a point where we have it partially implemented, or even not at all, then I don't think that user would engage with the RFC process again. It'd be quite a lot of effort to go through if it then ends up being accepted but not actually implemented.
Perhaps that implies some kind of "agreed in principle" type state of an RFC instead of just "draft" and "accepted"? As in we agree that the idea is a good one and we've ironed out any flaws, and now it moves to a stage where we actually need it implementing. Only after the implementation is the state something like "adopted".

Thanks for expanding on the feedback 👍
Regarding the distinction of what is and is not under the purview of this RFC process, I think we are in general agreement. The CLI is perhaps not the best example, though I did include it because the current (soon to be deprecated) implementation of Pact Python for example uses the CLI quite heavily under the hood[^1].
[^1]: The newer Pact Python V3 rewrite makes use of the FFI library, as having what effectively is a wrapper to a CLI is really not ideal.
I also hope that this RFC process forms a good foundation; however, I do not expect it to be immutable. If there is a common misunderstanding or failure of the process that becomes evident, an RFC to update the RFC process would be welcome.
On the topic of the implementation, my explanation of the process does mention in passing that a tracking issue is to be created in this repo, though I will admit that it may not be very clear. My plan to address this will be to:

Require that a link to the tracking issue be added to the metadata section of the approved RFC. It will be the responsibility of the person approving the PR to create the tracking issue and update the approved RFC document with the relevant link.

Add a GitHub issue template for the tracking issue. In contrast to the RFC process which details the 'what' and 'why' in detail, I would anticipate the tracking issue to focus more on the 'how'.
The issue's comments would be a good place for discussion about the implementation itself, in case there are any unforeseen difficulties or recommendations.
An example of a tracking issue that I am currently using is https://github.com/pact-foundation/pact-python/issues/396 which tracks Pact Python's progress to being fully backed by the FFI library. You can quite easily see the progress (as an "X out of Y tasks complete") in various places of GitHub interface.

I personally would avoid having an "agreed in principle" state for an RFC, as it is ambiguous to me (and may be even more ambiguous to non-native speakers of English). More specifically, I think that an "agreed in principle" does not really explain whether it is to be implemented now, later, or not at all. E.g., it could be agreed in principle, but some time in the future; or agreed in principle, but too difficult to implement; etc.  I think an RFC should have three distinct states:

draft (PR is open)
accepted (PR is merged)
rejected (PR is closed).

Once accepted, the implementation is recorded in the tracking issue I mention above.
Furthermore, if a RFC can only be "accepted" once it is fully implemented, how should we define "fully implemented"? If it requires changes in all Pact implementations across all languages; do we really want to wait until the lesser-known/lesser-used implementations also adopt it before it is marked as accepted? Or do we only care about the "main" implementations (and then the question is, which ones are they)?
I hope I have explained my reluctance to having any additional states to an RFC beyond what is strictly necessary; and I hope that the tracking issue provides an acceptable alternative which will fill the niche.
I will update the PR with my suggestions changes tomorrow morning (as it is late here in Melbourne), but do you think these would address your concerns?

@adamrodger I have updated the PR to address your concerns. I hope this helps address the concerns you raised, and if not, let me know.

I think your explanation above is a good one, like this process covers the common elements of the ecosystem (such as the Spec and FFI) and not the language-specific parts. That does put the CLI in a bit of an awkward inbetween though. That doesn't feel like it fits the definition of a common element that affects the entire ecosystem.

Yeah, I see this point. The CLI (like the Pact Broker) is something we recommend all users use, so in part, it feels like it should be here and any substantial change to it communicated and agreed upon. For example, if the author of the CLI decided to change the way arguments were handled (because Thor is a bit...strange) should that be raised here or not? I think so?
The additional of a new subcommand that fits with the existing model (e.g. to list the currently deployed applications for an environment)? Maybe.
The broker seems more important. For example, when the "pacts for verification" feature was created, there was a tracking issue created in the pact_broker repo - but raising it here would have made it more visible to maintainers. It's an important new concept introduced into the ecosystem, that will ripple into other languages and sits outside of the spec. It will eventually result in new FFI APIs etc.

I think in reality the list of things covered in this process is actually "the things maintained by SmartBear people" vs. "the the things that aren't" generally speaking (I accept it's not that clearly separated, e.g. PactJS maintained by Matt). Where those language-specific libraries are maintained by SmartBear employees then they do tend to pop up in this repo, such as https://github.com/pact-foundation/roadmap/issues/95, which is PactJS-specific.

That might be true, but only coincidentally so. If the rust core or the CLI were to have additional maintainers external to the SmartBear team I wouldn't expect the process to change. The aim is to have a place where core features that affect the whole ecosystem should be raised, and not for any language/repo/SDK-specific request.
That issue might be a red herring . All of the feature requests previously in Canny were moved here to move away from Canny and to something first-class in the ecosystem (i.e. GitHub). Pact JS-specific feature requests should go to https://github.com/pact-foundation/pact-js like any other feature request. That being said, that is an example of a feature request that may be raised as an RFC for support in other languages, as it is a feature in Pact JVM that a user would like to have supported in Pact JS (metadata support.

As a non-SmartBear member of Pact Foundation, my two concerns with that are:
Marking your own homework - There are enough 'core team' Pact Foundation members that it's very easy for one to raise an RFC and multiple others to comment/approve so that the entire process is followed, yet without involving anyone from outside of that group. For someone outside the group, that's not possible. To the community at large it's unclear who is paid to maintain Pact as their job and who is a volunteer, so it's not really possible to spot when this might happen.

I understand this point. I'm also concerned with the reverse problem. If we don't have clarity on the process to approve/reject an RFC, it might sit around for ages with no progress. For example, with the Plugins RFC we had basically zero contributions from the maintainer group at large. Back then, we didn't have a process like we are proposing now, but it was added to the V4 spec RFC where it was visible and maintainers did comment, it was made visible in our maintainers channel etc. For 6 months (maybe more) we had no feedback before it was started and then only after implementation did we get critical feedback (which was obviously too late).
Without re-litigating that history, we want to avoid an RFC sitting around that could be progressed but isn't because maintainer X or Y hasn't had time to get around to it.

Tail wagging the dog - There have been times where the reference implementation doesn't follow what the spec says, and then instead of changing the implementation the spec is updated to match what the implementation does (without any version bump or anything either). This effectively means that the spec can be de-facto updated by proxy. This is especially concerning for library maintainers because then users point to the spec and say you're not compliant, but once upon a time you were.

I would like to think this RFC process would start to address that kind of problem.

Final reminder that the deadline for any further comments is in 3 days!

authors: JP-Ellis YOU54F adamrodger mefellows

repo: pact-foundation/roadmap


text:
support to transfer direct objects

https://developer.mozilla.org/en-US/docs/Web/API/Transferable
Would be awesome!!!!!!
!!!

https://github.com/padolsey/operative/wiki/Transfers-API :)

authors: padolsey robertleeplummerjr

repo: padolsey/operative


text:
Feature request: attach closures to mocks for handling sideeffects

Hi, one thing I'd love to have is a way to simulate sideeffects:
Here's an example of how I'd like to mock Doctrines EntityManager
   $id = 0;
   $emMock = \Mockery::mock('\Doctrine\ORM\EntityManager',
            array(
                'getRepository' => $this->repository,
                'getClassMetadata' => (object)array('name' => 'aClass'),
                'persist' => function($obj) use ($id) { $obj->setId($id++); },
                'flush' => null,
            ));

Closing, been open for a long time without further interest.

authors: askundervisning davedevelopment

repo: padraic/mockery


text:
Deploy Project on Vercel with /docs/index.html as Main Page?

How can I deploy a project on Vercel such that the index.html file in the /docs directory serves as the main page of the site?
I see you provide instructions for Cloudflare and Github Pages.
I can't translate the instructions well, I am a bit new to this.
But I like golang usually on backend because its simple to use, never attempted to use it on front end only.

@jamiecropley thanks for posting this. I will work on this one soon and add a guide for Vercel.

@jamiecropley thanks for posting this. I will work on this one soon and add a guide for Vercel.

Keep this open as well, I will have a play around with it and update anything new I find here if it helps. My key concern with vercel, I have a paid plan budget $20 a month, I pay for this so I can build many sites for commercial use, but my main gripe is not always deploying in such a complex manner because that's how you end up with multiple charges, thus where it gets confusing for me more than anything.

That would be great, I gave it a brief try and did some progress with GitHub actions. Ended up here:
      # Push our generated site to vercel
      - name: Install Vercel CLI
        run: npm install --global vercel@latest
      - name: Copy output
        run: mkdir -p .vercel/output && cp -r public/* .vercel/output
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

However, it still complaining about some vercel configuration.

I know at the basic level I can build locally, then simply manually deploy to github which in turn auto deploys to vercel, thus it is only deploying the static HTML files then, but would ideally want something for docs where I don't have to keep running so many build commands etc... every time I update a markdown file.

It would be great to read any findings you encounter. I gave it a brief try and made some progress with GitHub actions. Ended up here:
      # Push our generated site to vercel
      - name: Install Vercel CLI
        run: npm install --global vercel@latest

        # Here I'm copying the Doco output as the CLI tool expects the output to live
        # on .vercel/output
      - name: Copy output
        run: mkdir -p .vercel/output && cp -r public/* .vercel/output
      - name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
      - name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

However, it still complaining about some vercel configuration.

I think this could be a good key to it https://vercel.com/docs/projects/project-configuration but I don't usually add these in most my sites added on there, it will generate them automatically.

So I had to make my own document generator in golang to understand more how vercel would achieve something like this. I don't think honestly vercel works straight forward like this with a focus more on node / next js kinda side of things rather than go long. Ideally the best way is to generate the docs to HTML first then deploy those static files once generated.

Yes. You can initialize your docs locally with doco init and then run doco build to generate the public folder; that public folder will have the resulting HTML. If you want to see the changes to your docs, you can run them locally with doco serve which rebuilds the documentation as you change the documents.

Yes. You can initialize your docs locally with doco init and then run doco build to generate the public folder; that public folder will have the resulting HTML. If you want to see the changes to your docs, you can run them locally with doco serve which rebuilds the documentation as you change the documents.

Yeah, so usually Vercel is very good at this if the main framework is javascript driven, despite my best efforts and tests it just won't pick up anything golang, you need to just build it locally then deploy the locally generated HTML files and such this way.

Cool. Let's review this later on. Thanks for bringing this up. I learned a bit about Vecel.

authors: jamiecropley paganotoni

repo: paganotoni/doco


text:
🛑 Pageon is down

In f6c7525, Pageon (https://www.pageon.be) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Pageon is back up in 57aac08.

repo: pageon/uptime


text:
🛑 Kind van God is down

In 68ff660, Kind van God (https://blog.kindvangod.be) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Kind van God is back up in dc40c1b.


text:
Set Column Header names

The functionality to set column header names and hide/show column headers separately
EG Time/Date.     Agency.    Alias.    Message.

I would like to work on this issue.

@ThomasLuu00 Thanks, Feel Free to submit a PR and reference this issue number

repo: pagermon/pagermon

license: Unlicense


text:
controller: don't fail tests when running in emacs

Apparently, when running in emacs and piped into another command, ps limits
it's output to COLUMNS making check_process_names fail.  Telling ps to use
wide, wide output with 'ww' fixes this.
Additionally, use check_from so that if this test does fail we can debug
it better, seeing what grep was looking at.

lgtm

authors: jeffkaufman jmarantz


text:
How to use BP_GO_WORK_USE

Summary
Companion docs PR for https://github.com/paketo-buildpacks/go-build/pull/537
Use Cases

Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[x] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[x] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

The only other thing the spell checker is worked up about is the word "workspaces" (not sure why) this can be fixed by adding it here https://github.com/paketo-buildpacks/paketo-website/blob/main/scripts/.util/spellcheck-dictionary.txt. If you would be willing to do that I would appreciate that!

The only other thing the spell checker is worked up about is the word "workspaces" (not sure why) this can be fixed by adding it here https://github.com/mamachanko/paketo-website/blob/topic/mamachanko/main/bp_go_work_use/scripts/.util/spellcheck-dictionary.txt. If you would be willing to do that I would appreciate that!

It's done!

authors: ForestEckhardt mamachanko

repo: paketo-buildpacks/paketo-website


text:
Proposal to publish multi-arch buildpacks

Readable
Checklist

[X] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

I haven't really been following the existing arm64 work in the cloud native buildpacks and paketo communities. One thing I am wondering about in the context of this RFC is what the longer-term picture is? Is this RFC a stepping stone towards pack build --multi-arch (or whatever the flag for this would be) producing multi architecture application images with Paketo buildpacks - I assume that's what we want in the end.

One thing I am wondering about in the context of this RFC is what the longer-term picture is? Is this RFC a stepping stone towards pack build --multi-arch (or whatever the flag for this would be) producing multi architecture application images with Paketo buildpacks - I assume that's what we want in the end.

@loewenstein the current work upstream is adding a lower level feature like Docker manifest so you can compose two images into an index.
Down the road that will be more automatic. The normal pack commands will be enhanced to support building multi arch images.
In the meantime Paketo will have to fill in the gaps in our pipelines. Maybe with some additional tooling too. That's what we're doing with the stack builds now, enhancing jam to publish a multi arch image for the stack.

@jpena-r7 Thanks so much for writing this up. Excellent to pull all of this information together and help get everyone focused on this topic.

@jpena-r7 FYI looks like you made changes under the @jericop account which hasn't signed a CLA. I'm not sure if you want to recreate them under your Rapid 7 account or sign the CLA on the other account.

@jpena-r7 FYI looks like you made changes under the @jericop account which hasn't signed a CLA. I'm not sure if you want to recreate them under your Rapid 7 account or sign the CLA on the other account.

I plan to start contributing from @jericop going forward so I signed the CLA. Sorry for the confusion.

With work being in progress already to fulfill this not yet accepted RFC... Should we make sure this actually get's merged as a basis of that ongoing work? WDYT @paketo-buildpacks/steering-committee?

I'm unsure of what we actually need to put into an RFC.
I could see us putting together an RFC that signals the intent to publish multi-arch images across Paketo. It would really just be a signal to users that we intend to do this across the whole project. IMO, it's probably better to just keep writing blog posts about our progress. Those are just as easy to site when folks ask questions about multi-arch support.
I don't think there's any technical coordination that needs to happen to publish multi-arch images though. Upstream has made tooling available to publish multi-arch images. We've done it for a number of buildpacks and it works fine. I don't see any reason why folks would not use that functionality in their implementations, but I suppose we could include that in an RFC.
Maybe there are some details with the stacks/builders that would be helpful to work out in an RFC. I would defer to that team though. From what I've observed, they're already working on it and I don't want to add a process if it's not needed. If everyone is in agreement on how we proceed, then we probably don't need an RFC and we just focus on the work.
That said, happy to help push an RFC forward if folks think it's helpful. Just let me know.

I'm unsure of what we actually need to put into an RFC.

Sure. All I am saying is that this is a draft PR for an RFC - so either we get it merged in one shape or another or we close it with a comment that it doesn't need an RFC.
Either way, I would suggest we at least create a tracking issue for all the work involved, similarly to the one I created for adopting Ubuntu Noble. That way we can ping all maintainers and track overall progress in a central place.

@loewenstein +1 to both those points. I'd prefer we close this RFC-draft. Then use the issue to track the works that's been done and what's still to be completed.

If anyone objects to closing this RFC-draft. Please let us know, or we'll close this in one week.

authors: dmikusa jericop jpena-r7 loewenstein loewenstein-sap robdimsdale

repo: paketo-buildpacks/rfcs


text:
Spread operator typescript 1.4.1

Versions

tslint: 2.1.1
typescript: 1.4.1

I'm using gulp-tslint which in turn uses tslint.
private func(arg1: (...any) => string): string {}
I have a function that uses the spread operator in the type definition, this is to allow me to call func with
public exampleOne(str: string): string or
public exampleTwo(str: string, radix: number): string as arg1
This gives me the error:
expected parameter: 'any' to have a typedef
Is there any other way of achieving this?

Update
private func(arg1: (any) => string): string {} and
private func(arg1: () => string): string {}
both pass the linting process but typescript fails to compile.

Solution
The following works as expected. I forgot to specify the argument name.
private func(arg1: (...args: any[]) => string): string {}

repo: palantir/tslint


text:
Data to play with for OTU descriptions & synonyms

To help us play with merged descriptions and synonyms, I entered some real Bighorn Basin data that is a fun story. We initially had two morphotypes, "JAY" and "Arial", which were in part different morphotypes because we had different features preserved at different sites. As we added sites and specimens, we could see more features and similarities between the two. So, we lumped them into the "JAY Arial" type.
I have entered a selection of specimens belonging to JAY and to Arial, and done a description for each of the original morphotypes based on a composite of specimens. I have also created an OTU that includes all the specimens and thus both descriptions. No holotype chosen.
This dataset will be in both stage/prod and dev. In dev, I will also create both the JAY and the Arial OTU so that we would be ready to try out the synonym function. I'm keeping the data private because it is real and unpublished, but everyone on the PBot core team is a member of the group (as is Scott Wing).

Curious to hear more about this at the next meeting.

A fix for synonym and comment was deployed on dev as part of #295. Please check if it works with your examples as expected.

I am closing this just to merge with #295 for cleanliness...

authors: aazaff ecurrano

repo: paleobot/pbot-dev