v3.x.x | No documents exist.  Unable to continue dependency-check analysis.

dependencyCheckAnalyze gradle task fails with the error below consistently.
I have linked two gist links below showing the complete stacktrace and info logs of my gradle run.
This issue was observed on dependency-check gradle plugin versions 3.0.0 through 3.1.2
Erorr
Checking for updates and analyzing vulnerabilities for dependencies
No documents exist

Unable to continue dependency-check analysis.
:dependencyCheckAnalyze FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':dependencyCheckAnalyze'.
> Analysis failed.

Logs

depedencyCheckAnalyze-stacktrace-log

depedencyCheckAnalyze-info-log

I initially suspected that I may be experiencing connectivity issues when trying to download CVE data from NVD database. However, that was not the case. I could see in the info log that the plugin completed the processing of all downloaded CVE data. To make it easier to read, I sorted the relevant section of the depedencyCheckAnalyze-info-log and pasted below.
NVD CVE requires several updates; this could take a couple of minutes.

Download Started for NVD CVE - 2002
Download Started for NVD CVE - 2003
Download Started for NVD CVE - 2004
Download Started for NVD CVE - 2005
Download Started for NVD CVE - 2006
Download Started for NVD CVE - 2007
Download Started for NVD CVE - 2008
Download Started for NVD CVE - 2009
Download Started for NVD CVE - 2010
Download Started for NVD CVE - 2011
Download Started for NVD CVE - 2012
Download Started for NVD CVE - 2013
Download Started for NVD CVE - 2014
Download Started for NVD CVE - 2015
Download Started for NVD CVE - 2016
Download Started for NVD CVE - 2017
Download Started for NVD CVE - 2018
Download Started for NVD CVE - Modified

Download Complete for NVD CVE - 2002  (8896 ms)
Download Complete for NVD CVE - 2003  (7359 ms)
Download Complete for NVD CVE - 2004  (6134 ms)
Download Complete for NVD CVE - 2005  (12440 ms)
Download Complete for NVD CVE - 2006  (10567 ms)
Download Complete for NVD CVE - 2007  (19191 ms)
Download Complete for NVD CVE - 2008  (10262 ms)
Download Complete for NVD CVE - 2009  (13361 ms)
Download Complete for NVD CVE - 2010  (15220 ms)
Download Complete for NVD CVE - 2011  (25540 ms)
Download Complete for NVD CVE - 2012  (14330 ms)
Download Complete for NVD CVE - 2013  (18895 ms)
Download Complete for NVD CVE - 2014  (9892 ms)
Download Complete for NVD CVE - 2015  (9709 ms)
Download Complete for NVD CVE - 2016  (12277 ms)
Download Complete for NVD CVE - 2017  (12746 ms)
Download Complete for NVD CVE - 2018  (4857 ms)
Download Complete for NVD CVE - Modified  (3773 ms)

Processing Started for NVD CVE - 2002
Processing Started for NVD CVE - 2003
Processing Started for NVD CVE - 2004
Processing Started for NVD CVE - 2005
Processing Started for NVD CVE - 2006
Processing Started for NVD CVE - 2007
Processing Started for NVD CVE - 2008
Processing Started for NVD CVE - 2009
Processing Started for NVD CVE - 2010
Processing Started for NVD CVE - 2011
Processing Started for NVD CVE - 2012
Processing Started for NVD CVE - 2013
Processing Started for NVD CVE - 2014
Processing Started for NVD CVE - 2015
Processing Started for NVD CVE - 2016
Processing Started for NVD CVE - 2017
Processing Started for NVD CVE - 2018
Processing Started for NVD CVE - Modified

Processing Complete for NVD CVE - 2002  (899 ms)
Processing Complete for NVD CVE - 2003  (269 ms)
Processing Complete for NVD CVE - 2004  (642 ms)
Processing Complete for NVD CVE - 2005  (14916 ms)
Processing Complete for NVD CVE - 2006  (12961 ms)
Processing Complete for NVD CVE - 2007  (52887 ms)
Processing Complete for NVD CVE - 2008  (8254 ms)
Processing Complete for NVD CVE - 2009  (20590 ms)
Processing Complete for NVD CVE - 2010  (25303 ms)
Processing Complete for NVD CVE - 2011  (36655 ms)
Processing Complete for NVD CVE - 2012  (27525 ms)
Processing Complete for NVD CVE - 2013  (29202 ms)
Processing Complete for NVD CVE - 2014  (59512 ms)
Processing Complete for NVD CVE - 2015  (48373 ms)
Processing Complete for NVD CVE - 2016  (50058 ms)
Processing Complete for NVD CVE - 2017  (58776 ms)
Processing Complete for NVD CVE - 2018  (6970 ms)
Processing Complete for NVD CVE - Modified  (1052 ms)

Begin database maintenance.
End database maintenance.
Check for updates complete (97660 ms)
No documents exist

Other notes:

I should add that it didn't matter where I ran the dependencyCheckAnalyze gradle task on (my laptop, jenkins, ubuntu, Mac, CentOs etc), it failed with exactly the same issue consistently.
Also I'm not behind any proxy

Workaround
I managed to find a good working version of the plugin (i.e. one without the issue described above). It is version 2.1.1.
So if you are not precious about being on the latest and greatest version, you could give v2.1.1 a try.

@jeremylong
Sorry for the delay in getting the debug log across to you. Here it is
depedencyCheckAnalyze-debug-log

Unfortunately - the log provided is truncated. Any chance you could repost the complete log or zip it and email it to me (jeremy.long at owasp.org)


Is there a schedule to develop a version can use for system with ARM architecture?

As the explanation in Supported platforms chapter:The driver is developed and tested for x86 architecture. Use for system with ARM architecture (e.g. Raspberry platform) is not officially supported.
Is there a schedule to develop a version can use for system with ARM architecture?
Thanks

In principle, you can already compile and use the driver for ARM platforms now. We only reserve the right not to provide direct support in case of problems.

@Jonny0816 A release with ARM support is planned end of the first quarter in 2023.


Train, test , demo codes

Hi,
Are you planning to complete the project for training, test and demo, etc for professional use? Or you stopped working on this project?  I have tried to run the demo using given weights and cfg with (https://github.com/ultralytics/yolov3) but it does not work.

Also wait for the train code.


Build of Phoenix 0.13.1 application fails with no guidance as to why

Everything compiles fine and then all of a sudden, exrm reports a failure with no details, thus I do not know how to begin tracking the issue down.
==> Building release with MIX_ENV=prod.
==> Generating relx configuration...
==> Generating sys.config...
==> Generating boot script...
==> Performing protocol consolidation...
==> Conform: Loading schema...
==> Conform: No schema found, conform will not be packaged in this release!
==> Generating release...
==> Failed to build release. Please fix any errors and try again.

Following are the contents of my apps mix.exs file.
 ...

    def project do
      [app: :some_app,
       version: "0.1.0",
       elixir: "~> 1.0",
       elixirc_paths: elixirc_paths(Mix.env),
       compilers: [:phoenix] ++ Mix.compilers,
       build_embedded: Mix.env == :prod,
       start_permanent: Mix.env == :prod,
       preferred_cli_env: [espec: :test],
       deps: deps]
    end

    # Configuration for the OTP application
    #
    # Type `mix help compile.app` for more information
    def application do
      [
        mod: {SomeApp, []},
        applications: [
          :phoenix,
          :phoenix_html,
          :cowboy,
          :logger,
          :phoenix_ecto,
          :postgrex,
          :erlzmq,
          :dotenv
        ]
      ]
    end

    # Specifies which paths to compile per environment
    defp elixirc_paths(:test), do: ["lib", "web", "test/support"]
    defp elixirc_paths(_),     do: ["lib", "web"]

    # Specifies your project dependencies
    #
    # Type `mix help deps` for examples and options
    defp deps do
      [{:phoenix, "~> 0.13"},
       {:phoenix_ecto, "~> 0.4"},
       {:postgrex, ">= 0.0.0"},
       {:phoenix_html, "~> 1.0"},
       {:phoenix_live_reload, "~> 0.4", only: :dev},
       {:cowboy, "~> 1.0"},
       {:erlzmq, github: "zeromq/erlzmq2"},
       {:uuid, "~> 1.0"},
       {:good_times, "~> 1.0.0"},
       {:espec_phoenix, "~> 0.1", only: :test, app: false},
       {:apex, "~>0.3.2", only: :dev},
       {:dotenv, "~> 1.0"},
       {:logger_file_backend, github: "onkel-dirtus/logger_file_backend"},
       {:exrm, "~> 0.18"},
       {:rebar3_hex, "~> 0.8"},
       {:timex, "~> 0.13"}]
    end

  ...

Could you post the output of running mix release --verbosity=verbose? This outputs the debug log and can help us track down the issue.
I think I'm going to update the error handling to suggest this on failure, I put documentation in the task docs for mix release, but I don't think that's very helpful currently.

No need to post, your hint gave me what I needed to fix this myself.
I apologize, but I am fairly new to Erlang/Elixir and I do not have a great understanding of the toolset, etc yet.  I am sure you will have more and more newbies rolling though due to Elixir's lower barrier of entry, so putting that message into the error would probably save you lots of interruptions, like me :).
Anyways, thanks for your quick response and thanks for all of the hard work you have done on this project!  Take care.

@midas No worries, I'm glad you were able to get it sorted :). These questions are definitely not an interruption so don't worry about that, it helps guide me towards ways to make the tooling better!


Support juju proxy settings

Issue
I'm fixing the following issue: https://github.com/canonical/loki-k8s-operator/issues/326
Solution
I declared a ProxyHandler for the urllib request that is made to download the promtail binary.
Testing Instructions
I used the discourse-k8s charm to test the change.

Add the cilium addon to microk8s
Deploy squid on microk8s like proposed here
Create a model
apply a network-policy to that model only allowing local networking (like this)
Apply the correct juju-http{s,}-proxy settings to the model
relate all the charms to discourse-k8s, it should be operational in the end.

Release Notes
Add support for JUJU_CHARM_{HTTP,HTTPS}_PROXY variables in the loki_push_api lib.

This PR needs to bump the LIBPATCH for both libraries :)

I see that the integration tests are failing but I can't see anything related to my change in the logs. Can you help me on that ?

What's the status on this one @dstathis ?


Fix 4.4

BASH_Source并不是一个bash的环境变量, 应该是BASH_SOURCE
$ cat test.sh
echo "\$0: $0"
echo "\$BASH_Source: $BASH_Source"
echo "\$BASH_SOURCE: $BASH_SOURCE"

$ bash test.sh
$0: test.sh
$BASH_Source:
$BASH_SOURCE: test.sh

Thanks for contribution!


PowerToys Run Web Search

Description of the new feature / enhancement
If a result is not found for the given text, pass it to the search field of the default web browser.
Scenario when this would be used?
As a one-step method of making a web search.
Supporting information
The current behavior of the URI Handler is to open the current browser then allow you to make your search, or to take your query and add "https://" to the beginning.  This could instead be a single step using the text that is input directly in the launcher.
Examples:

The Windows 10 Start Menu does this, but requires use of Bing.
Sesame Shortcuts (Android) has a home screen launcher that does this (along with allowing you to select which app to send the text to for results).

Tracked via #3245


transition to open-source

Let's discuss what parts to simplify (if any) before making this repo public.
Some issues to address:

The README contains a lot of balena-related info, perhaps less focus on that
Some of the compose files contain balena-specific flags and variables and need to contain specific paths when built on non-balena operating systems
See if some parts of the code need improvement in terms of naming, refactoring, and comments
Decide if the code should be split into smaller modules
What parts to test and how to test them, e.g. flashing the firmware and onboarding the egw using the configurator(?)
Decide open-source license

I guess most of this stuff has been taken care of or already decided. closing...


Hardware Encoding/Decoding

V4L2 supports hardware encoding and decoding via it's Memory to Memory (M2M) mode. Would it be possible to add support for hardware encoding to libv4l-rs?
This tutorial ( https://lalitm.com/hw-encoding-raspi/ ) seems to lay out how to do it for people how are fluent in C (ie. not myself, not without staring at it for a long time :sweat_smile:).
Would this fit within the way things are setup in this library? Would it make more sense to try to build HW encode/decode separately on top of something like nix?
Also I'm not sure but this seems related to #15.

Doesn't this crate already support all the necessary IOCTLs and memory mapping?


Update Readme [WIP]

Also update code comments and restore unintended review removals

/gcbrun

/gcbrun

/gcbrun


Training result on s3dis dataset is low

Hi !Thanks for your great work!
I follow your experiment setting on your paper, 8 A100, batchsize=32. But the result on s3dis are as follows, which are far from the results provided in your paper. Do you have any suggestions with training?
s3dis B8/N4

Could you please verify that the caption loss is non-zero during training? I suspect that the caption loss is not being utilized.

According to the training log, its true that the caption loss is not being utilized. Then how could it be solved?
2023-09-20 17:04:00,748   INFO  Epoch [5/32][100/127] LR: 0.004, ETA: 3:20:13, Data: 0.34 (0.42), Iter: 3.54 (3.48), Accuracy: 0.92, loss_seg=0.13, binary_loss=0.28, caption_view=0.00, caption_entity=0.00, loss=0.41, n_captions=0.0(0.0)
2023-09-20 17:05:06,016   INFO  Epoch [5/32][120/127] LR: 0.004, ETA: 3:17:02, Data: 0.36 (0.41), Iter: 3.11 (3.44), Accuracy: 0.93, loss_seg=0.22, binary_loss=0.23, caption_view=0.00, caption_entity=0.00, loss=0.45, n_captions=0.0(0.0)
2023-09-20 17:05:27,248   INFO  Epoch [5/32][127/127] LR: 0.004, ETA: 3:15:20, Data: 0.39 (0.41), Iter: 2.93 (3.42), Accuracy: 0.93, loss_seg=0.23, binary_loss=0.22, caption_view=0.00, caption_entity=0.00, loss=0.45, n_captions=0.0(0.0)

BTW, it also different with the result without caption in the paper.

I found the reason, the caption was not loaded successfully. Thank you.

Yes. The mIoU for the base category is quite low.  Could you provide the log file for us to investigate the underlying issue?

Hi, please get the log from here. https://github.com/JaneDoc/tmp
pla_baseline_s3dis.log without caption  and the result is 14.2/44.3/8.5 , yours 13.0 / 58.0 / 7.4.
pla_baseline_s3dis_wcaption.log with caption and the result is 33.7/58.6/23.6, yours 35.6 / 58.3 / 25.6.

We report the performance of the last epoch instead of cherry-picking the best-performing epoch. The baseline result of the last epoch is 0.0941 / 0.5936 / 0.0511 for loss, which is within the expected range. The performance gap observed is attributed to the inherent instability of the S3DIS dataset, as it contains a relatively small number of scenes.

I see. Thank you for your reply.


Making a selection should be passive

Simply making a selection should not modify the canvas; it should be a passive operation.
Only when you move or resize it (or otherwise operate on it) should it cut the selection from the canvas.
You can see that this is how it works in mspaint by creating a selection, then changing the secondary color, then dragging the selection, and the background color it leaves behind will be the new secondary color you selected.
In jspaint currently it leaves behind the original background color.
The way it works now causes or compounds problems, and makes the code more complicated (like, right now canceling the selection uses undo; stuff like that?).
I'll need to make sure operations like invert still work (on selections), and undo/redo and canceling

Note: I've done some work on this on a branch.
I've also identified a bunch of things I want to test. This feature touches a lot of areas. A lot of places destroy selections, either melding them into the canvas, or deleting/erasing them, and care has to be given to undo history for each case.

You should be able to make a selection, then change the secondary color, then drag the selection cutting it out with the color you selected
If you create a selection and there are several redos it pops up the dialog and it should... [maybe i should just implement nonlinear history instead of trying to figure out what weird UI might exist here]
Clicking and not dragging (much? is there a margin of error?) should not create a selection.
zooming while selection present
copy pasting
deleting
cropping
inverting
smearing (shift)
cloning (ctrl)
resizing
quick undo
normal undo
switching tools
textbox
all the tools
multitools
multi-user mode


[Search] Conditionally pull catalog entities from local catalog if configured

Hey, I just made a Pull Request!
Aims to provide a reasonable interim solution to #5207 until there's consensus on #5210...
Not sure of what, if any, implications there are of building a completely separate instance of the catalog (but with identical configs).
:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

Not sure about this construction of the catalog builder. Would it make more sense to use the catalog-client?

Since the plugin-to-plugin communications so far has only happened via their service interfaces, not via code sharing or direct injection

Hmm...  Just looked at the Catalog client and I see it's just making HTTP calls under the hood.  The problem we're trying to work around is when folks have auth enabled for backend APIs.  Was hoping there'd be a reasonable in-process way to interact with the catalog if it happened to be deployed together with the search backend.  Any other ideas @freben?


PhpdocScalarFixer - fix property annotation too

Ref #1295

This is kind of more of a feature than a bug fix I think @keradus. Wondering if maybe 1.10 is a better target?

Also, we were looking for a place for me to update my email address across the code base, could I do that here @keradus?

I agree it may be treaten like enhance or bugfix.
But it was intended to fix long form to short form of types in phpdocs, we just missed that one annotation. Personally it's a bugfix to me.

Personally it's a bugfix to me.

Sure. That's what I first thought too when I selected the 1.9 branch. :)

:+1:

:+1:

Thank you @GrahamCampbell.


Queries are not selectable

The popup that contained the different queries doesn't contain any items. Therefore it's impossible to query the database.

It also doesn't work if you open the query interface. I had to remove the (manually) added views. IMO we should think of a better solution. The old implementation was a quick&dirty solution for a meeting. What do you think @eScienceCenter/spacialists ?

The reason is that some views got lost in the database (e.g. the "german_attributes" view and others). This seems related to #44, should be part of migrations

The views we had were very specific. Not every project needs a german_attributes view. Thus I'm not sure if/how this should be a part of the migrations. But if we need just something that works (for now), I could re-add the view in pgAdmin and later discuss a better solution.

yes please re-add the view(s) for now. we can discuss alternatives later on

I re-added the views, but since our db layout has changed, we have to adjust the views as well. Hence we should definitely find a better solution.

Views work like a charm

🎱


Add Clojure notebook viewer

Cool! Thanks!

Wow, that trick with GET request parameter is great, I was using anchors for that but this is much cleaner.
Thank you.


NBT player abillity stats Reset after respawning.

I changed the movement speed of the player using the new built in NBTeditor. This works, untill the player dies. Then it gets reset to its original state (1.00).

Sorry, we have nothing to do about it
That's just how Minecraft works

Oh, okay.


Fix inferring algorithm, make sure to choose the lowest common denominator

Fixes #210 .
The infer algorithm has a problem - for each sample value in each column, it tries to find the most specific type it can cast it to. Then it counts which type has the most occurrences.
As can be seen in the attached bug, this method is not correct.
The PR changes the algorithm so it does not find just one type per value, but all applicable types.
Then the selected type is the one with most occurrences (and amongst those - the most specific type).

@akariv
Thanks.
Regarding the changes - I think we touch here the same thing we discussed with @Stephen-Gates and others on tableschema-js.
For example if we have a column like:
1
2
3
4
5
typo
7
8
9
I guess the updated algorithm will say it's a string but tableschema-js will say that it's an integer because it uses a probabilistic algorithm including the confidence concept (like chardet) based on the idea that infer is just a first iteration on a schema creation (requiring manual tweaks later).
Not sure it's implemented already or not for tableschema-js but we were also looking for an option to get the lowest common denominator. List this:
schema = infer(data, confidence=1)  # should return `string` for our example

https://github.com/frictionlessdata/tableschema-js/blob/master/src/config.js#L5
So I'm kinda confused what we better to do with tableschema-py for now. Because these changes are switching the lib from one mode to another mode. And I can't say that any of this behavior is incorrect.
Maybe we try to start with confidence flag here? For example:
schema = infer(data) # work as before this PR
schema = infer(data, confidence=1) # switching to behaviour proposed in this PR

And later we just update the whole algo based on the tableschema.js lib (which is a way faster - https://github.com/frictionlessdata/tableschema-js/blob/master/src/schema.js#L179) preserving proposed behavior for the client.
WDYT?

I think that infer schema should always return a schema that works with the data.
Anything else feels like a bug to me.
Allowing lower levels of confidence sounds like a great feature, but only as an addition over the basic functionality.
By the way, the current algorithm will return integer for the following list of values too:
1,
1.2,
2,
2.3,
3,
3.4,
4

btw, implementing a 'confidence' parameter is super simple - just modify the sorting phase here:
https://github.com/frictionlessdata/tableschema-py/pull/211/files#diff-e7ea47bed4b0f96022a8553c5c1572ecR318
So that it takes all results with count >= max(counts)*confidence and picks the one with the highest priority.

@akariv
I would probably agree I think on the idea that 100% compliant way should be default but historically the default way is the best guess (and in Python it doesn't work very well - not sure about JS for edge cases like above).
So I think we would better don't change the current default behavior to do not break the dependent software (esp. goodtables.io) and existent workflows (e.g. with CLI).

See my latest commit @roll - it now introduces a new confidence parameter, which defaults at 0.75 (which is inline with the current behaviour) but can also be set to 1.0 to make it strict.

@akariv
Cool. I think now it's just great


Close dropdowns when they scroll out of view

From https://github.com/sindresorhus/refined-github/pull/735#issuecomment-340138827
Can use IntersectionObserver.

Specifically, because of my workflow when reviewing (described here: https://github.com/sindresorhus/refined-github/pull/735#issuecomment-339183475) I'd prefer not to do that.
Even though it sounds nice, clicking somewhere to close is easy and I want to keep it explicit for the review dropdown. If you this could be done for other dropdowns, but not for the review dropdown, I'm fine with it.

I agree it would be annoying for the review dropdown, but for the other ones, I think it's ok.


Prevent failure when "prefix" is empty string.

 Issue by voxik
Monday Mar 11, 2013 at 16:33 GMT
Originally opened as https://github.com/rmagick/rmagick/pull/71

In case that "prefix" is empty string, the config_string returns false. Default to empty string for that case.

voxik included the following code: https://github.com/rmagick/rmagick/pull/71/commits

@voxik I pushed your change to master. Further contributions will also be welcome.


Regression in v0.13.2

Steps to Reproduce
git clone https://github.com/styfle/og-image
cd og-image
ncc build src/card.ts

Error
ERROR in ./node_modules/chrome-aws-lambda/source/index.js 167:6-67
Module not found: Error: Can't resolve '/Users/styfle/Code/zeit/og-image/node_modules/chrome-aws-lambda/source/source/puppeteer/lib' in '/Users/styfle/Code/zeit/og-image/node_modules/chrome-aws-lambda/source'

Click for full output

ncc: Using<EMAIL_ADDRESS>(local user-provided)
ncc: Module directory "/Users/styfle/Code/zeit/og-image/node_modules/debug/src" attempted to require "supports-color" but could not be resolved, assuming external.
ncc: Module directory "/Users/styfle/Code/zeit/og-image/node_modules/ws/lib" attempted to require "bufferutil" but could not be resolved, assuming external.
ncc: Module directory "/Users/styfle/Code/zeit/og-image/node_modules/ws/lib" attempted to require "utf-8-validate" but could not be resolved, assuming external.
ncc: Module directory "/Users/styfle/Code/zeit/og-image/node_modules/https-proxy-agent/node_modules/debug/src" attempted to require "supports-color" but could not be resolved, assuming external.
ncc: Module directory "/Users/styfle/Code/zeit/og-image/node_modules/chrome-aws-lambda/source" attempted to require "puppeteer" but could not be resolved, assuming external.
Error: Hash: b222450dedeb92a8e6c4
Version: webpack 5.0.0-alpha.9
Time: 4534ms
Built at: 02/13/2019 9:39:28 AM
                                   Asset       Size  Chunks  Chunk Names
                        Inter-Bold.woff2   93.7 KiB
                     Inter-Regular.woff2   87.1 KiB
             bin/chromium-72.0.3617.0.br   34.2 MiB
                          iltorb/LICENSE   1.13 KiB
       iltorb/build/bindings/iltorb.node    782 KiB
                                index.js   1.12 MiB   {404}  main
          puppeteer-core/CONTRIBUTING.md   8.15 KiB
                  puppeteer-core/LICENSE   11.1 KiB
                puppeteer-core/README.md     18 KiB
             puppeteer-core/package.json   3.28 KiB
                   source/iltorb/LICENSE   1.13 KiB
source/iltorb/build/bindings/iltorb.node    782 KiB
                       source/index.d.ts  399 bytes
Entrypoint main = index.js
 [66] external "fs" 42 bytes {404} [built]
 [77] external "url" 42 bytes {404} [built]
[127] ./src/parser.ts 1.61 KiB {404} [not cacheable] [built]
[298] external "crypto" 42 bytes {404} [built]
[421] external "http" 42 bytes {404} [built]
[426] ./src/file.ts 819 bytes {404} [not cacheable] [built]
[431] external "os" 42 bytes {404} [built]
[444] ./node_modules/puppeteer-core/index.js 1.15 KiB {404} [built]
[589] external "path" 42 bytes {404} [built]
[607] ./src/card.ts 1.3 KiB {404} [not cacheable] [built]
[721] ./src/options.ts 857 bytes {404} [not cacheable] [built]
[898] ./src/chromium.ts 710 bytes {404} [not cacheable] [built]
[940] ./src/template.ts 3.44 KiB {404} [not cacheable] [built]
[963] ./node_modules/marked/lib/marked.js 40.2 KiB {404} [built]
[967] external "util" 42 bytes {404} [built]
    + 145 hidden modules
ERROR in ./node_modules/chrome-aws-lambda/source/index.js 167:6-67
Module not found: Error: Can't resolve '/Users/styfle/Code/zeit/og-image/node_modules/chrome-aws-lambda/source/source/puppeteer/lib' in '/Users/styfle/Code/zeit/og-image/node_modules/chrome-aws-lambda/source'
@ ./src/options.ts 6:44-72
@ ./src/chromium.ts 4:18-38
@ ./src/card.ts 5:19-40
at compiler.close.n (evalmachine.<anonymous>:1:41090)
at _promise0.then._result0 (eval at create (evalmachine.<anonymous>:1:813514), <anonymous>:13:1)
at process._tickCallback (internal/process/next_tick.js:68:7)

Comments
I'm not sure why this error just started occurring in the @now/node builder because<EMAIL_ADDRESS>works and<EMAIL_ADDRESS>works, but the bug occurs in<EMAIL_ADDRESS>and newer.
Here's the build logs for today https://zeit.co/deployments/og-image-1vj25qvla.now.sh/logs

Can you try with the 0.15.0 latest here?

The error log I posted is with v0.15.0 (click for full output above)
I just went back to see when the bug was introduced.

Fixed in https://github.com/zeit/webpack-asset-relocator-loader/commit/6122f38cf76d7aafa71d8a221e199ba2881838ee. Will post a loader release shortly with the upgrade.

@guybedford Any update on this one?
This is blocking deployments of puppeteer which is something that was being advertised the last 2 weeks.
It's confusing for users 😐
https://github.com/styfle/og-image/issues/56

@styfle this should be fixed on master.

@guybedford Was this fixed in #282?
I didn't realize devDependencies would change the behavior of ncc at runtime.

Yes, we moved the bulk of the analysis logic out into the the separate loader there.

Can you publish a new version of ncc with the fix? 😃

I don't have the publish permissions, but I believe you do :)

Fixed in<EMAIL_ADDRESS>


Add tests to CSVOption functions

Codecov Report

Merging #6 (e734410) into master (78fa35c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #6   +/-   ##
=======================================
  Coverage   88.88%   88.88%
=======================================
  Files           2        2
  Lines          36       36
=======================================
  Hits           32       32
  Misses          2        2
  Partials        2        2

Continue to review full report at Codecov.

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


Android Kotlin: 10.05 Explain Bitmap using Canvas.

Description :scroll:

Give a step-by-step tutorial of bitmap using Canvas (Kotlin).
Required Documentation or Video or Audio.

Domain of Contribution :bar_chart:

[x] Android Dev (Kotlin)

References :

https://camposha.info/android-examples/android-bitmap/

https://twiserandom.com/android/graphics/what-is-a-bitmap-in-android/index.html

Please Read it Carefully Before Contributing

Changes should be made in Android_Development_With_Kotlin/ directory under Android_Development_With_Kotlin branch.
Inside Android_Development_With_Kotlin/ directory creates a directory and names it according to the topic ( for this issue 10. Custom Views)
Inside 10. Custom Views/ directory add your task with subtopic number and name and make changes accordingly.
You have to push your PR to the Android_Development_With_Kotlin branch only.
You can take help to the references but don't simply try to copy it. Just explain in your own word.
This issue is for GWOC'21 contributors only.
You need to push in a single commit. If there exists more than one commit then you need to squash your commits into one commit.
Will assign you on a first come first serve basis.
Please try to complete your assigned task within 7 days. If you need some more time then, please inform mentors and supervisors.
If you have two previously assigned issues on Android-Kotlin pending then please first complete them.

Supervisor @rahulsain

Happy Contributing. Best of Luck.:sparkling_heart:

/assign

Hey @sitamadex11 I have created the PR if there are no issues please merge it.

Okk
On Sat, 16 Oct 2021, 8:09 pm Eshan Gupta, @.***> wrote:

Hey @sitamadex11 https://github.com/sitamadex11 I have created the PR
if there are no issues please merge it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/girlscript/winter-of-contributing/issues/5873#issuecomment-944925094,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASIF5UAPG6GNRUISWJVCGLLUHGFCLANCNFSM5GACAGWQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

may you please tag us on your pr?


Add paths parameter to the API

Resolves #3

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

Project coverage is 100.00%. Comparing base (b64e2bc) to head (9932f22).

Additional details and impacted files
@@            Coverage Diff            @@
##            master        #4   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            7         7
  Lines          127       146   +19
  Branches        24        28    +4
=========================================
+ Hits           127       146   +19

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


Docker Issues

Sorry if this is the wrong place, asking here is a last resort after reading through previous issues and docker documentation for hours.
Very new to Linux and Docker, used this script on Windows for a while and loved it, recently switched to Linux and wanted to use it here too, but can't figure out what I'm doing.
I think I've got it running? It's connected to my Plex server and the logs show it's getting the right information, but I cannot figure out how to get Discord to see this, or how to configure this at all from here. I've tried to follow the readme but as I said, I'm very new to all of this so it doesn't make much sense to me. Any help would be appreciated.

Since you've got it running already, I assume you managed to figure out Docker Compose and are running it through that. Let me know if this is not the case.
Copying the compose file contents from the example in the README should work in most cases. The 3 lines that might require changing are:

DRPP_UID: 1000 - Replace 1000 with your UID (user ID), which you can find by running the id command in your terminal.
DRPP_GID: 1000 - Replace 1000 with your GID (group ID), which you can find by running the id command in your terminal.
- /run/user/1000:/run/app - Replace /run/user/1000 with the path to your runtime directory, which you can find by running echo $XDG_RUNTIME_DIR in your terminal.

Yes, I've got it running through Compose, and all those settings from the example in the readme are correct for my system.
I get a "Discord IPC pipe not found" error, which I'm guessing is the issue, and I don't get any [WRITE] or [READ} messages.
[18-11-2024 04:13:45 PM] [ERROR] Discord IPC pipe not found (attempted pipes: /run/app/discord-ipc-0, /run/app/app/com.discordapp.Discord/discord-ipc-0, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-0, /run/app/discord-ipc-1, /run/app/app/com.discordapp.Discord/discord-ipc-1, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-1, /run/app/discord-ipc-2, /run/app/app/com.discordapp.Discord/discord-ipc-2, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-2, /run/app/discord-ipc-3, /run/app/app/com.discordapp.Discord/discord-ipc-3, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-3, /run/app/discord-ipc-4, /run/app/app/com.discordapp.Discord/discord-ipc-4, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-4, /run/app/discord-ipc-5, /run/app/app/com.discordapp.Discord/discord-ipc-5, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-5, /run/app/discord-ipc-6, /run/app/app/com.discordapp.Discord/discord-ipc-6, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-6, /run/app/discord-ipc-7, /run/app/app/com.discordapp.Discord/discord-ipc-7, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-7, /run/app/discord-ipc-8, /run/app/app/com.discordapp.Discord/discord-ipc-8, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-8, /run/app/discord-ipc-9, /run/app/app/com.discordapp.Discord/discord-ipc-9, /run/app/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-9)

Post the contents of your compose file here. I'll take a look at it just in case you missed something.

Which Linux distro are you using?

Are you using the official Discord client? If so, where did you acquire/install it from?

1:
services:
  drpp:
    container_name: drpp
    image: ghcr.io/phin05/discord-rich-presence-plex:latest
    restart: unless-stopped
    environment:
      DRPP_UID: 1000
      DRPP_GID: 1000
    volumes:
      - ./data:/app/data
      - /run/user/1000:/run/app

Fedora KDE 41

Yes, from Flathub

Run this command while Discord is running: find /run -name discord-ipc-*
Any results?

find: ‘/run/user/1000/doc’: Permission denied
/run/user/1000/.flatpak/com.discordapp.Discord/xdg-run/discord-ipc-0
/run/user/1000/app/com.discordapp.Discord/discord-ipc-0
find: ‘/run/user/1000/2cc871a7_87a8_48f6_b7b3_3ebb7842ecf0’: Permission denied
/run/user/1000/discord-ipc-0

I'm guessing it's a flatpak permissions issue then?

The permission issues there are unrelated.
It's strange that the discord-ipc-0 file exists in 3 places. The /run/user/1000/discord-ipc-0 one should exist if you were using the regular version of Discord instead of the Flatpak version, and with the Flatpak version, only one of the other two should exist.
Regardless of that, the script wasn't able to see any of them at all as per the error in the container logs. Did you add/modify/fix the /run/user/1000:/run/app part of the compose file under volumes after the creation of the container? If so, did you re-create the container after that by running docker compose up -d again?

I think something had gotten messed up with my discord install at some point, I've cleaned it up now and gotten a fresh install from flathub, but script still can't see it.
I didn't modify the compose file at all from the version in the readme.

Hmm, I'm not sure what's going on. Try re-creating the container anyways by running docker compose down and then docker compose up -d. If it's still not working, run docker exec drpp find /run -name discord-ipc-* and let me know the output, to check if the Discord IPC Unix socket file is visible inside the container.

Recreating it didn't fix it, and there's no output from running the second command.

What's the output of docker inspect drpp --format '{{json .Mounts}}'?

[{"Type":"bind","Source":"/host_mnt/home/argorath/Desktop/drpp/data","Destination":"/app/data","Mode":"rw","RW":true,"Propagation":"rprivate"},{"Type":"bind","Source":"/run/user/1000","Destination":"/run/app","Mode":"rw","RW":true,"Propagation":"rprivate"}]

The error from the logs you sent above (https://github.com/phin05/discord-rich-presence-plex/issues/109#issuecomment-2483504441), that's the only error you're seeing, right? Or are there any other errors?

Yes, that's the only error.

Everything looks right to me so I'm not sure what's happening. The runtime directory is mounted into the container according to the output of the inspect command but somehow the discord-ipc-0 file which is in that directory is not showing up inside the container.
If you want, you can add me on Discord (username: phin05) and we can try to debug it a bit more with maybe screenshots or screen sharing or some more back-and-forth command running.

The issue was caused due to the usage of Docker Desktop, which runs containers inside a virtual machine, isolated from DIscord which runs on the host machine. Using normal Docker resolved the issue.


[Improvement]: Show commit message in webhook deployments

Description
The commit message only appears in manual deployments. Deploy messages received via webbook are not appearing in the list.

Minimal Reproduction (if possible, example repository)
Open deployments tab on any service.
Exception or Error
No response
Version
v4.0.0-beta.294

Ah, nice catch. It was just not visible in the UI. In the next version it will be.


CI: bump build and test timeouts to 60 minutes

Motivation
We've started running the CI workflow on #main post-merge again. Several job steps are running into timeouts on #main. We're also fiddling with the cargo env vars to avoid running out of space on the GitHub runners.
Solution
To give some margins to trying all these tweaks, this change bumps the timeouts on the build and test jobs/steps to one hour.
Review
Anyone can review, but @oxarbitrage @teor2345 . Medium urgent as we have timeouts on CI runs on #main.
Related Issues
#1756
Follow Up Work

Hmm, i think the test builds will almost always need more time as they build everything and later run the tests. I will say 60 minutes there is fine. In the build only job we can go with 50 minutes and in the without features 45 mins ?
We can increase this values if needed but some difference between the timeouts could help us spot certain rare problems.

Hmm, i think the test builds will almost always need more time as they build everything and later run the tests. I will say 60 minutes there is fine. In the build only job we can go with 50 minutes and in the without features 45 mins ?
We can increase this values if needed but some difference between the timeouts could help us spot certain rare problems.

Since we're experimenting with flags, and to have some more consistent expectations of how long jobs take, I rounded up to 60mins for now, but am amenable to changing them again later. I would rather the top margin be large with room to experiment rather than too low. The GitHub job max is like 6 hours or something.

Ok, fair, approving.


[WIP, DO NOT MERGE] Add basic integration test

This adds an integration test using Jest, which uses Selenium to start up Firefox and install a test extension. It also turns on extra logging in Firefox so we can see messages from the extension's background script from Selenium.
However I think it needs a few changes before we land it:

[ ] create an extension at runtime instead of having the test/build dir
[ ] make the test extension actually do something useful that can only be tested from integration vs. unit tests (maybe inject a content script as a first test?)

@hamilton I think this isn't quite ready to land, but I'm pretty new to Jest and could use your opinion on this :)


Add Prefix to Metric Name

The documents recommend adding a prefix to your metric name.
https://prometheus.io/docs/practices/naming/
This update adds the hubitat_ prefix

Great catch, thanks for this!


[GOBBLIN-2128] Fix bugs in setpermission step where it does not properly add records…

… with equal file depths
Dear Gobblin maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[ ] My PR addresses the following Gobblin JIRA issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"

https://issues.apache.org/jira/browse/GOBBLIN-2128

Description

[ ] Here are some details about my PR, including screenshots (if applicable):
SetPermissionCommitStep has a bug where it does not handle paths with the same file depth appropriately.
If directories of the same nested path have different permissions, they can lead to unknown behavior as the key equality is incorrect here and doesn't maintain both separate paths/permissions.

The key comparator:
Long.compare(o1.chars().filter(ch -> ch == '/').count(), o2.chars().filter(ch -> ch == '/').count())

should be replaced with:
Comparator.comparingInt((String o) -> o.split("/").length).thenComparing(o -> o)

Additionally, build the paths and permissions from the existing map instead of re-reading from FS to reduce FS calls and ensure consistency.
Add a setting to disable this permission step with the configuration
gobblin.copy.manifestBased.enableSetPermissionPostPublish

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Unit tests.
Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

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

Project coverage is 41.11%. Comparing base (e501b62) to head (e4be396).
Report is 3 commits behind head on master.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #4020      +/-   ##
============================================
- Coverage     45.86%   41.11%   -4.75%
+ Complexity     3257     2204    -1053
============================================
  Files           707      480     -227
  Lines         27865    20365    -7500
  Branches       2796     2355     -441
============================================
- Hits          12779     8374    -4405
+ Misses        14008    11099    -2909
+ Partials       1078      892     -186

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


Update to new react-native-gesture-handler API?

Hi,
What an awesome component you've built!
I've noticed that the old API of react-native-gesture-handler is still being used.
Do you plan on updating to v2?
Thanks!

I can't dismiss the photo screen.
This is my setup:
"react-native-gesture-handler": "^2.3.2",
"react-native-reanimated": "^2.4.1",
"@react-navigation/native": "^6.0.8",
"@react-navigation/stack": "^6.1.1",
"react-native-screens": "^3.13.1",

Do you think it's related?

https://user-images.githubusercontent.com/1864359/159129944-36640920-71d2-437e-93a9-ea0ac06cc220.mov

@MadeinFrance Yes, it's related

RNGH v2 is now used in v0.3.0


[WIP] Fix online check if using proxy

What's this PR do?
This PR tries to mitigate (re)connection issues experienced by users behind a proxy as raised in #591 and discussed here.
If is-online returns true, we're online
If is-online returns false, no proxy enabled, we're offline
If is-online returns false and we use a proxy, we:

get the list of domains
prepare a properly setup request with ca and proxy options for each domain to fetch the favicon.ico
run a Promise.race() against all the requests, ending whenever one domain's favicon has been reached (means we're kinda online regarding our Zulip instances)

Any background context you want to provide?
The package used to check every 1.5s if we're online/offline, is-online, relies on the got package which is not compatible with proxies.
Given that got is not compatible with proxy connections, and that there's so many ways a test could work in a given setup and not on another, the best way seems to test for Zulip instances as this is the most relevant.
Screenshots?

Behavior with online/offline/online : https://d.pr/i/6I7nCb
Behavior with offline/online : https://d.pr/i/NVWVSG

You have tested this PR on:
macOS Mojave 10.14.1
Important notes:
I've deliberately commented some code to help test this implementation without a proxy and reach the favicon test code. Would be really amazing if someone could try it with a proxy!
This is very far from being either a perfect solution but, for me, it's much more valuable being able to reach a Zulip domain than Google or OpenDNS, as what we want to give the user is an insight about whether he can use a Zulip domain and nothing else.
Maybe cleaner solutions exist that would work in proxy setups, but when even reaching Google or OpenDNS fails in some very specific setups, and if you can't reach anything else than your Zulip domains, you should still be able to use Zulip.
Feel free to share your thoughts :)

I feel the addition of requestOptions in request-util.js would make our code very clean and easier to write. I think it deserves a separate PR with all places of request changed to requestOptions. @superbiche Would you interested in doing that? Then you can this rebase this PR above that commit (once merged).

Yes I’ll start with doing that.
[image: Logo]
Michel Tomas / Freelance Web Developer
<EMAIL_ADDRESS><EMAIL_ADDRESS>/ +33 6 08 05 94 27
[image: Skype] skype:webiche?add [image: Twitter]
https://twitter.com/superbiche [image: LinkedIn]
https://www.linkedin.com/in/micheltomas [image: Github]
https://github.com/superbiche
On 1 December 2018 at 14:13:53, Abhigyan Khaund<EMAIL_ADDRESS>wrote:
I feel the addition of requestOptions in request-util.js would make our
code very clean and easier to write. I think it deserves a separate PR with
all places of request changed to requestOptions. @superbiche
https://github.com/superbiche Would you interested in doing that? Then
you can this rebase this PR above that commit (once merged).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zulip/zulip-electron/pull/598#issuecomment-443425383,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACXQQmRSroQaHZ9dNXpNCnu4R8njEvFsks5u0oCRgaJpZM4Yp9WN
.

@superbiche let me know if you need any help in this.

Some part of this PR has been merged in #643.


[httpservice] upgrade to jakarta namespace

Pax web has a widely used extension to Httpservice and even though HttpService is not considered "modern" anymore keeping it at the old javax.* namespace makes it effectivly unusable now that most containers move to the jakarat namespace.
I therefore like to propose to release one more version of the HttpService specification that simply moves javax.* --> jakarta.* namespace.

Speaking from Pax Web perspective, I think it's good idea to keep org.osgi.service.http as kind of ancient legacy - just updated to jakarta.servlet packages with big, red not saying that Whiteboard approach is better now (even if the whiteboard extender pattern has some issues itself).
ops4j/org.ops4j.pax.web#1802 is work in progress, but the most important part of it is that org.osgi.service.http.HttpService interface is simply copied into Pax Web API bundle. Having it coming from the osgi CMPN API would make things simple.
There are at least two places where the ancient API is used:

Jolokia: https://github.com/rhuss/jolokia/blob/v1.7.2/agent/osgi/src/main/java/org/jolokia/osgi/JolokiaActivator.java#L322-L325
CXF: https://github.com/apache/cxf/blob/cxf-3.5.5/rt/transports/http/src/main/java/org/apache/cxf/transport/http/osgi/ServletExporter.java#L126

When working on ops4j/org.ops4j.pax.web#1802 (and ops4j/org.ops4j.pax.web#1803) I'll be adding feedback here.

in previous discussions we decided not to do this and to let the Http Service disappear.
This update would be a huge amount of work as it would involve adding support (and tests) for all the features between the ancient Servlet version used by the Http Service and the latest version. Furthermore, the design of the Http Service follows an anti-pattern which we do not wish to promote.
Anyone writing a new application should not use the Http Service, and anyone updating an existing application should move to the Servlet Whiteboard.

If that's the final decision, I'd like to know if it's possible for Pax Web 10 (targetting jakarta.servlet) to use old org.osgi.service.http package (and its HttpService and HttpContext interfaces) - I'd like to keep them as base interface of org.ops4j.pax.web.service.WebContainer extension interface (with 46 (!) additional methods for filters, listeners, jsps, session, cookies, SCIs, ...)?

It’s fine for people to implement and use the old interface, but it won’t be updated to use the new Jakarta API. In this case I would be adding the methods you want to the PAX interface and severing the link to the old specification.
Note that all references and links to the Http Service have been removed from the Servlet whiteboard, including specified behaviour about service ids.

This update would be a huge amount of work as it would involve adding support (and tests) for all the features between the ancient Servlet version used by the Http Service and the latest version.

I must confess I'm not really understand this  part... what new features? the only change should be the HttpService interface accepting a jakarta.Servlet instead of javax.Servlet ...

I'm stil preparing to run TCK tests on Pax Web related to "Web Applications Specification" (chapter 128) after migration to jakarta.servlet, so adding HttpService is not a big deal...

If you need to support the HttpService with jakarta namespace, you will need a new package to hold this API. OSGi would not make an org.osgi.service.http version=2.0 package anyway. As you see in the RESTful services and servlet specs, we used a new package name. Since any users of a jarkarta-fied HttpService would need to use a new package name anyway, PAX can simply copy the org.osgi.service.http package contents into a PAX namespace package and modify the javax references to jakarta. Users can then migrate to the PAX namespace package for Jakarta use. (But PAX should not release packages in the osgi namespace.)
I don't support OSGi resurrecting HttpService and jakarta-fying it.

If you need to support the HttpService with jakarta namespace, you will need a new package to hold this API. OSGi would not make an org.osgi.service.http version=2.0 package anyway.

Why not? Isn't that why packages are versioned? What is the purpose in always ever having only a v1.x version?

I don't support OSGi resurrecting HttpService and jakarta-fying it.

I must confess I'm confused. When discussion about the removal of WAB it was argued that any removed spec can easily be "revived" if there is any interest, now this process is asked for it is rejected ...

Isn't that why packages are versioned? What is the purpose in always ever having only a v1.x version?

See https://github.com/osgi/bugzilla-archive/issues/2958 for some of the past discussion. But the OSGi experts some time ago reached general consensus that when a major version change happens that new package names should also be used. This allow those that are interested to import both old and new packages. This choice allows Felix Http to support both old Http Whiteboard and new Servlet whiteboard from a single implementation.

When discussion about the removal of WAB it was argued that any removed spec can easily be "revived" if there is any interest, now this process is asked for it is rejected ...

You are not asking to revive it unchanged. You are asking for 2 things: revive it and then make a major change to it. I object to the latter and there is no point in reviving it unchanged.

See https://github.com/osgi/bugzilla-archive/issues/2958 and https://github.com/osgi/bugzilla-archive/issues/2949#issuecomment-622169502 for some of the past discussion. But the OSGi experts some time ago reached general consensus that when a major version change happens that new package names should also be used.

That seems really odd and actually resort to the "old" way of having version numbers in package names for evolution of an API, I must confess I always have though of actually making such practice unnecessary. There are many "major" breaking changes that might not affect the "whole universe" and inventing new package names seems not very helpful, strange enough the javax. > jakarta is exactly that kind of stuff that puts a lot of effort on libraries and I can't find many people that found this a great choice :-\

This choice allows Felix Http to support both old Http Whiteboard and new Servlet whiteboard from a single implementation.

Seems a very rare case where this is useful and seems to introduce a lot of maintenance efforts to support different (incompatible) versions in one release. But if it would be just a matter of rename the package I think that could be done here as well e.g. org.osgi.service.http.jakarta ...

You are not asking to revive it unchanged. You are asking for 2 things: revive it and then make a major change to it. I object to the latter and there is no point in reviving it unchanged.

Isn't this effectively "once removed never revived" ...?

This choice allows Felix Http to support both old Http Whiteboard and new Servlet whiteboard from a single implementation.

That's true and convenient from the provider perspective. From the consumer perspective check this scenario - CXF 4 is based (as provider) on jakarta.servlet API and CXF 3 is for javax.servlet. It (CXF 4 doesn't support OSGi now, but may do it at some point in the future if there's a demand) uses org.osgi.service.http.HttpService to register a CXF servlet and now it'd need to pass an instance of javax.servlet.Servlet or jakarta.servlet.Servlet.
Adding to this another difference - like orgi.osgi.service.http in CXF 3 and e.g., org.osgi.service.newhttp in CXF 4 would be extra and unnecessary change.
So I agree with @laeubi here - javax.servlet to jakarta.servlet between version 4 and 5 is both major version and package name change, however it was only major version change with 2→3 and 3→4 case. So I'd treat javax.servlet → jakarta.servlet rather a (politically motivated) exception than a rule.
On the other hand:

But the OSGi experts some time ago reached general consensus that when a major version change happens that new package names should also be used.

I can't argue with such decision even if it's quite weird...

Back to the subject - whether to keep HttpService (in any package) or not.
I think chapter 102 (HttpService) is quite similar to chapter 128 (WebApplication) with one significant difference - it provides an API tied to javax.servlet.
If you want to keep chapter 128 (and I'm much much more certain that it's important), why not keep the HttpService? It is badly designed, it covers very little of the available web elements, it doesn't cover contexts at all (only /), but it's quite simple, straightforward and used in legacy code.
Also take this into account - OSGi CMPN 8.1, in the scope related to javax → jakarta migration doesn't add any value - it's just an effort forced by external, political decision which prevented to keep javax namespace.
Also mind that I'm maintaining Pax Web and only learning bnd, so I can try TCKs with Pax Web... I (and Pax Web) lags behind the TCKs, but it'll not remove HttpService support (as it's fundamentally built around them - even when implementing the Whiteboard spec).

#นายณัชพล วงษ์เปลี่ยนผัน
NATCHAPHON WONGPLIANPHAN#

I must confess I'm not really understand this part... what new features? the only change should be the HttpService interface accepting a jakarta.Servlet instead of javax.Servlet ...

Given that the Http Service predates (and still does not support) Servlet Filters, there are quite a lot of new features that would need to be supported in a move to Jakarta.

I'd like to suggest two paths:
support chapter 102 (HttpService) with jakarta.servlet namespace, but only for current scope (registration of servlets and resources.
get rid of chapter 102 entirely
Second option is obvious, but I see good reasons for option 1:

if you want more (servlets, filters, listeners, prepprocessors, error pages), choose Whiteboard spec (chapter 140)
if you want everything (the above + JSPs, SCIs, WebSockets, Welcome Files), choose Web Applications spec (chapter 128)
if you want, well, only servlets, but you want to be on Jetty 10 / Tomcat 11 / Undertow 2.3 / Servlet API 5+, HttpService specification still plays its role. If CXF (4) considers bringing back OSGi support, it's easier to simply register one servlet than do it with Whiteboard. Of course it shouldn't be a problem for CXF to use Whiteboard, but imagine other projects/libraries - HttpService is quite straightforward.

Given that the Http Service predates (and still does not support) Servlet Filters, there are quite a lot of new features that would need to be supported in a move to Jakarta.

Why must they be supported? I really don't get this. as @grgrzybek  mentioned there are alternatives, for advanced use cases, but the bare minimum that is working for many use-cases is just a plain servlet and may libs offer such thing that can be integrated easily with HttpService ... with just a few lines of code I added JAX-RS support to my Application, and have in the past used this to integrate with Wicket, Vaadin, CXF ... so even though its not the most glorious service it serves its purpose.

Why must they be supported?

The don't have to be, but you then have some explaining to do in the spec. The old spec supports Servlet 2.1 which does not have such things and so the old spec does not even have to mention them. All features of Servlet 2.1 are supported. But to update the spec to Servlet 5.0 (which is the first servlet spec based upon jakarta namespace), the updated spec will need to explain why many features in Servlet 5.0 are not supported. This is a bad look for a new specification.

I am unclear on how simply registering a servlet as a service (whiteboard) is not easier than using a service tracker to get the HttpService service and then call that service to register your servlet.

You don't need a service tracker, DS is perfectly suitable for this, also Blueprint, also CDI.... With whiteboard you simply has no control over when the servlet is registered, it might get register immediately, some time later, or probably never, so there are always different use-cases.

With whiteboard you simply has no control over when the servlet is registered

Of course you have control. You can always decide when to register and unregister the servlet service.

With whiteboard you simply has no control over when the servlet is registered

Of course you have control. You can always decide when to register and unregister the servlet service.

Yes I can register it, but there is no guarantee it will actually be registered at the web-container (if ever), if there are many ones I can't easily decide to use one over the other ...

I don't understand this statement.

What part exactly? The first part was because of @bjhargrave statement that one need to use servicetracker (what is just one way), the second was not specifically directed to Equinox or its implementation details.
In general Whiteboard is a great way to decouple things (especially listener), what is great for a listener (it is only used if there is a service collecting it and I don't need to know about it), is bad for other purpose, e.g. I want to publish my web-page (or give the user a log message: WARNING no HttpService found, Website will NOT be available)) or I want to choose to which service of multiple available ones I want to register it (e.g. only to the one that serves the web console but not the the one that serves my web-frontend) .... this is nothing specific to HttpService but more generally if Whiteboard is the right approach for a service model or not.

e.g. I want to publish my web-page (or give the user a log message: WARNING no HttpService found, Website will NOT be available))

If you need this knowledge couldn’t you track the runtime service for the whiteboard? Its presence tells you the whiteboard is up (same as http service). If you need more detail the runtime dtos exist.

What part exactly?

All of it.
org.osgi.service.http.whiteboard.HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET can be used to target specific whiteboard implementations if there are multiple.

What part exactly?

All of it.
org.osgi.service.http.whiteboard.HttpWhiteboardConstants.HTTP_WHITEBOARD_TARGET can be used to target specific whiteboard implementations if there are multiple.

I use this feature a lot.

As said, this was just a general statement that whiteboard is not good per-se (even though I often use that pattern) nor explicit usage of service, simple as that.

I won't be defending HttpService. In practice there are no big differences between:

Whiteboard: register a javax|jakarta.servlet.Servlet service and don't be sure when it'll be able to start responding to requests, and
HttpService: register a tracker for org.osgi.service.http.HttpService and don't be sure when you'll be notified about it to be able to call registerServlet() with an instance

Speaking from CXF (if it wants to get back to OSGi) and Jolokia (https://github.com/rhuss/jolokia/pull/484#issuecomment-1375132916 - I'll be preparing PR for Jolokia soonish) I see two big benefits switching from HttpService to Whiteboard:

switch from dependency on osgi.cmpn (or org.osgi.service.http) to plain osgi.core (BundleContext.registerService())
be able to configure target context (path) to register the servlet too. While Pax Web has lots of improvements related to cooperation of HttpService/Whiteboard/WAB web elements within single context (path), it's usually safer to have dedicated target (Jetty/Tomcat/Undertow specific) context for different applications. Remember - Pax Web doesn't use single "dispatcher servlet" but instead leverages actual Jetty/Tomcat/Undertow ServletContext implementations.

I won't be dying to spare HttpService specification ;)

As said, this was just a general statement that whiteboard is not good per-se (even though I often use that pattern) nor explicit usage of service, simple as that.

I don't agree with that. We permanently register/unregister Servlets as services programatically or via DS (e.g. Jersey, Vaadin, RAP, Jolokia, Swagger). The same applies for filters (Pac4J (OAuth), Logging Filter). It does not matter if the instances are DS components or just ordinary service registration with some service properties. I can introspect everything using the RuntimeService.
What else do you need? I don't see a thing that is possible with HttpService and not possible with the Servlet Whiteboard. Vice verse it look different.
I really understand that there are implementations, that still use the HttpService. As you argue, the user will lose trust in OSGi, when we deprecate specifications. The same applies to the fact, when we half-hearted provide a specifiaction, that is not compliant to the corresponding Servlet Specification. in addition to that the Servlet Whiteboard can be seen as successor of the HttpService. From this point of view I think HttpServie should be deprecated somewhen. That we've choosen this time based on the fact, that we have to switch to the jakarta namesspace somewhen.


Improve documentation on Docker specific setup

Extend the documentation by adding steps for setting up the remote_path and local_path variables.
Move the Linux-specific instructions below the more general instructions.

Thank you!

Thank you!


Deprecate unwrapped and implement unwrap and unwrapping

This is the second PR of my GSoC :sun_with_face: project

Some fixes to the pack traversal API
It replaces the internal implementation of the unwrapped internals to use the pack_traversal API.
The functional unwrap is now called unwrapping, the new immediate unwrap: unwrap. The API provides two alternatives for both functions:  unwrap_n, unwrap_all, unwrapping_n, unwrapping_all which unwrap until a particular level of futures or all futures which are found recursively inside the arguments.

Tuples which are passed as only argument to unwrap aren't unwrapped anymore. We could provide an explode or spread function for this behaviour.

For now all internal stuff of HPX is using a proxy function unwrapped which calls the new API unwrap.

Probably there are some remaing build failures and inconsisties which need to be fixed, however I want to receive feedback early.
For now:
:heavy_check_mark: hpx base library builds
:heavy_check_mark: unwrapped_test builds (using the unit tests of the old implementation for the new one)
:heavy_check_mark: unwrap_test builds
:heavy_check_mark: examples build
:heavy_check_mark: tests build
Outstanding points (need to be fixed before merging):

[x] More unit tests for unwrap and unwrapping
[x] Fix the remaining inconsistencies between the old implementation and the new one.
[x] Replace using namespace
[x] Add constexpr and noexcept
[x] Replace unwrapped by unwrap and unwrapping
[x] Add deprecation notice

@hkaiser did you take a look on this already?
It would be great if you could give me feedback whether I'm going into the right direction here.

@Naios This is impressive work! The only thing I'd ask is for you to use meaningful commit messages. Otherwise it will be impossible to reconstruct the changes you applied, if necessary. You might even want to go back and to merge commits or to rewrite some of the history on this branch to make things more transparent.

@hkaiser Yes, I'll rebase the commits back into the 7 first commits, so everything looks like atomic changes, as soon as I'll have a proper state.
Just wanted to keep the history as long as possible so I have a chance for reverts and also that you can take a look at my current progress.

@hkaiser For me it seems like the functional part of this PR is done now, since all the unit tests pass with the new unwrap implementation and the changes I applied recently.
I'll work on the few outstanding ToDo items now, in order to get the PR ready for merge in the next 2 days.
Additionally, I have one outstanding question regarding the originally planned compatibility layer between unwrap and unwrapped.
Since the 1:n mapping improvements, the original unwrapped and the new unwrap unwrap implementation just distingiush theirself in one point: unwrapped did unwrap the first occurring tuple regardless the callable was called with more than one argument or not. Thus tuples which were passed to unwrapped were unpacked by default as shown in the following unit test:
int add(int c1, int c2)
{
    return c1 + c2;
}

// ...

hpx::util::tuple<future<int>, future<int> > tuple =
                hpx::util::forward_as_tuple(
                    hpx::make_ready_future(42), hpx::make_ready_future(42));

HPX_TEST_EQ(unwrapped(&add)(tuple), 42 + 42);

Because uwrapped will be deprecated anyway, I would like to drop this behaviour immediatly (and delete the unit test above), so we don't need to add an additional compatibility layer (and duplicate the implementation headers). Since this particular functionality of unwrapped isn't documented nor used in the overall framework, I think we can apply this change without risking to break the API.

That is fine. We need to add a note about the breaking change in the docs, though (here).
Also, we may be able not to rename the existing unwrapped, or do should we do that in any case?

@Naios: could you please also clarify what relation this PR has to #1404, #1400, and #1126?

Internally I'll rename the function calls to unwrap or unwrapping accordingly so I can flag unwrapped with HPX_DEPRECATED.
Because HPX itself and all the unit tests and examples build with the new behaviour, there is nothing against the rename in my opinion.
Because of the issues: #1404 and #1400 will be resolved, #1126 is only solved half because when_all and dataflow are still missing the changes (which require the async traversal API).
I'll add closing comments to the last commit in this PR so those get resolved accordingly through merging.

@hkaiser From my side this PR is finished and ready for merging :tada:

@Naios: the only real question I have is whether we should retain the old name (at least for the functional part of unwrapped).

@hkaiser My personal opinion on this is to also take a new name for the functional part since the overall capability of the function was changed and thus library users should be forced to review this change.
But if it's decided to keep the old name for the functional implementation, I could change it back easily.
However, this would prevent users from using the current deprecated unwrapped function which stays functionable until removal (in this case we would remove the old unwrapped completely without deprecating it officially).

@Naios, Congratulations on your first pull request! After this is merged we can coordinate to get you an HPX T-shirt ;)

@Naios: well, we have to think about code out there using unwrapped today. We have two possible ways forward:

either we leave the name unwrapped (instead of unwrapping), or
deprecate unwrapped the usual way (in three stages, as described earlier)

I personally think we should deprecate today's unwrapped as a simple renaming doesn't cover all possible use cases.
For this reason, may I ask you to add a preprocessor constant (for instance HPX_WITH_UNWRAPPED_COMPATIBILITY/HPX_HAVE_UNWRAPPED_COMPATIBILITY) which wraps the old code (no need to try to 'emulate' the old behavior in the new code) and to mark the definition of the old unwrapped using HPX_DEPRECATED`. Also, please add a sentence or two to the docs describing the necessary changes to existing code, including the name of the configuration constant you used.

@hkaiser I applied the requested changes as discussed.

@Naios What compilers this PR was tested with?
In Visual Studio 2015, I found compile error messages related to this PR.
c:\users\xornr\onedrive\documents\github\hpx\hpx\util\detail\unwrap_impl.hpp(176): error C2297: '&&': 오른쪽 피연산자 형식으로 'Unique-Type-value'을(를) 사용할 수 없습니다.

There is the error message above. (Sorry to korean error message. Maybe you need to translate the message to english.)

@taeguk I'm sorry because it seems the PR was only tested with with Visual Studio 2017.
I blindly trusted the AppVeyor CI which uses Visual Studio 2017 too.
What you could try is to do is to patch your locale Visual Studio version to Visual Studio 2015 Update 3, which eventually could fix your issue.
Beside of this I'll take a look on this.
@hkaiser Is the current minimum compiler version for HPX still Visual Studio 2015 as described in the docs or could it be raised to Visual Studio 2017?
It would be great if the documentation could also state the patch version of Visual Studio, which preferably should be Visual Studio Update 3, since the previous updates were not stable.
Also maybe we could  aligned the Appveyor Visual Studio version with the minimum required version to avoid such issues in the future.

Is the current minimum compiler version for HPX still Visual Studio 2015 as described in the docs or could it be raised to Visual Studio 2017?

So far we've had the policy to support the latest two versions of Visual Studio. We just dropped support for VS 2013 the other day,

It would be great if the documentation could also state the patch version of Visual Studio, which preferably should be Visual Studio Update 3, since the previous updates were not stable.

Ok, patches welcome. Anybody?

Also maybe we could align the Appveyor Visual Studio version with the minimum required version to avoid such issues in the future.

That should be doable as well.

@Naios: another option would be to leave the old unwrapped code in place when compiling with VS2015. I don't particularly care about this version as VS2017 is ABI compatible and everybody can simply download the newer one. This however would require some discussion, I'd like to hear the opinion of others.

@hkaiser @taeguk I provided the fixes for both known issues of this PR in #2787

@Naios I found that issue with Visual Studio 2015 Enterprise Update 3.
Now, is my issue fixed??

@taeguk I'm really sorry for the inconveniences.
The build fix for MSVC 2015 is provided in #2787.
As temporary workaround you may cherry-pick the fix locally:
git remote add msvcfix https://github.com/Naios/hpx.git
git fetch msvcfix
git cherry-pick 320f515335b43f0342

Or as alternative you could explude this PR from your locale history through interactive rebasing git rebase -i HEAD~30.

@Naios Thanks for your fast fix!
Don't worry for me. I'm already doing my works in the point which this PR is not applied.


Unexpected bahaviour touch sensor on ESP32-S3 measurement time (IDFGH-7499)

Environment

Development Kit: ESP32-S3-DevKitC-1
IDF version v4.4.1
Build System: CMake
Compiler version (run xtensa-esp32-elf-gcc --version to find it): 8.4.0
Operating System:     Windows
Using an IDE: VSCode
Power Supply: USB

Problem Description
On the dev-board the example code touch_sensor_v2 produces unexpected behavior. I tried 2 different boards and different pins.
Expected Behavior
According to the documentation, the measurement time is set with touch_pad_set_meas_time(). The sensor value is supposed to be the count of charge and discharge cycles within the fixed measurement period. My ESP32-Module behaves exactly as described in the documentation.
Actual Behavior
The ESP32-S3 however extends the measurement time when a sensor is being touched. The raw value increases value returned by touch_pad_read_raw_data() while being touched rather than decreasing. The measurement time is being increased with an increase of the measured capacity.
Measurement without touch (raw value ~68.000)

Measurement with touch (raw value ~270.000)

Steps to reproduce

Compile and flash example touch_sensor_v2
Connect Oscilloscope and touch pad to any touch-pin.

Yes, the touch sensor on ESP32 and ESP32-S3 are different. Actually, the touch sensor on ESP32-S2 and ESP32-S3 adopt an opposite way to  measure the capacity, they will fixed  the count of charge and discharge cycles and then record the count of the clock cycles during the sensing period.
That is to say, the result of these two version are also opposite, on ESP32, the capacity will get bigger with finger put on the touch pad, then the touch sensor will count less charge and discharge cycles in a fixed period, however, on ESP32-S2 and ESP32-S3, it will count more clock cycles with the fixed charge and discharge cycles.

Thanks for the clarification regarding the measurement principle. I am referring to the programming guide for ESP32-S3. From what you describe, it needs to be updated.
What is also very misleading is the function touch_pad_set_meas_time() used to specify a fixed measurement time, which it is obviously not longer doing. What is it doing instead? With the procedure you describe, I would have expected an API that lets me specify the number of charge and discharge cycle within one measurement cycle. Is such a function implemented?
Can you anticipate, when the documentation will be updated?

I agree, the API name touch_pad_set_meas_time are same on both two versions is quite misleading, but this API can still specify the number of charge and discharge cycle in one measurement cycle, the second parameter meas_times is exactly the charge and discharge times, and an appropriate value recommended to to keep the measurement time about 1 ms.
Since the API has public, its name can't be updated easily, we'll add detailed description for this API as soon as possible

OK, thank you!

We will keep this issue open and close it once documentation is updated.


wrong label getting added on taskrun created referencing a clustertask

Expected Behavior
When we create a taskrun from the clustertask the label should be tekton.dev/clustertask
Actual Behavior
When we create a taskrun from the clustertask the label is tekton.dev/task
Steps to Reproduce the Problem

Create a cluster task
Create a taskrun referencing clustertask
check the metadata.labels

Note: When we have a task and a clustertask with same name, if we create taskruns for them, it is difficult to differentiate the taskruns of the task and clustertask
Additional Info
Pipeline Version: 0.11.1
/cc @vdemeester @piyush-garg

/assign

/kind bug


ModuleNotFoundError: No module named 'infer.modules'

Does anyone know how to fix this?
I just installed with all of the pretrained models so I'm not sure what's happening.

If anyone could help please tell me

I'm not sure why the dependencies with repo just hate to load. Like, the pathing is correct and _____?
Anyway.
Opening up infer-web.py and slapping something like:
sys.path.insert(2, '................/RVC-nvidia/assets/weights')
sys.path.insert(3, '............/RVC-nvidia/configs')
sys.path.insert(1, /.........../RVC-nvidia/venv/lib/python3.10/site-packages')
sys.path.insert(4, '/............../RVC-nvidia//tools/infer/lib/infer_pack/modules')
sys.path.append('/............./RVC-nvidia/tools/infer/lib/infer_pack/modules')
into it for whatever won't load may fix it. sys.path.append() will likely work but if it doesn't then you can' slap the path.insert on there to make sure it loads whatever problematic little fucker isn't loading first.
so in your case try adding: sys.path.append("D:\Restrieval-based-Voice-Conversion-WebUI-main\Retrieval-based-Voice-Conversion-WebUI-main") to the top of your infer-web.py file  near where all the import statements are.

I'm not sure if me adding that caused the error to change or if it was something else I did but i've started getting this error instead.

Hopefully its easier to fix


Add support to configure server port number

Problem
Currently the server port number is statically set to 7546 even though an env variable exists to modify it.
The variable is currently only used in test cases and as such operator of the relay are forced to use this value
Solution
Update server package logic to pick up the custom port number if set. If not set default to 7546
Alternatives
No response

@Nana-EC This was addressed here.


Create camel-spi component

@gautric I'm in the process of reading air sensor data (see #302 ) to do this in the first step I need to use ADC like MCP3008 [1]. To be able to do this I have created pi4j-spi component (it works basically the same way as pi4j-i2c component just implementing different interface) and driver for MCP3008. And this is enought to handle my use case but if I would like to add this to master I need to add implementation to SpiProducer and SpiConsumer as they do nothing right now.
First question can we continue the work under this thread or should I create new issue dedicated to pi4j-spi component?
Second question, do you have any suggestions on how to implement producer and consumer?
[1] https://www.adafruit.com/products/856

Greg, any thoughts on this?

@hekonsek we gonna implements  spi component on pi4j component
pi4j-spi

we can close this thread

@ajurasz Are you OK with closing the thread, Arek?


develop basic ingest script from CSV files

depends on #32

@wilbertom (until I can assign you the ticket)

Go for it, I'll handle this issue.

Nice, assigned. I'll try and get that manifest/index of available CSVs done today or tomorrow.
For now, you can hardcode; the CSV files should be public.
The pattern is: https://s3.amazonaws.com/cookcountyjail.il.propublica.org/dev/daily/2016-07-24.csv
It runs from 2014-06-05 to 2016-07-24 and 2017-06-19 to 2017-06-23 -- I broke something and didn't realize!


fix: basic id validation

Please ensure your pull request adheres to the following guidelines:

[ ] make sure to link the related issues in this description
[ ] when merging / squashing, make sure the fixed issue references are visible in the commits, for easy compilation of release notes

Related Issues
Thanks for contributing!

:tada: This PR is included in version 2.25.7 :tada:
The release is available on:

v2.25.7
v2.25.7
GitHub release

Your semantic-release bot :package::rocket:


can't pass table name from variable without {}

Environment

Operating System: Darwin
Node Version:     v20.10.0
Nuxt Version:     3.11.1
CLI Version:      3.11.1
Nitro Version:    2.9.5
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      css, devtools, modules, fonts, shadcn, eslint, experimental, nitro
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
I will add one here soon.
Describe the bug
// DOESNT WORK
// routes/tables/[name].get.ts
export default defineEventHandler(async (event) => {
  try {
    const db = useDatabase()
    const name = getRouterParam(event, 'name')
    const query = getQuery(event)
    const limit = (query?.limit ?? 10) as number

    const table = await db.sql`SELECT * FROM ${name} LIMIT ${limit}`

    return table.rows ?? []
  }
  catch (error) {
    createError({
      status: 500,
      name: 'ServerError',
      cause: 'Internal Server Error',
    })
  }
})

// DOES WORK
// routes/tables/[name].get.ts
export default defineEventHandler(async (event) => {
  try {
    const db = useDatabase()
    const name = getRouterParam(event, 'name')
    const query = getQuery(event)
    const limit = (query?.limit ?? 10) as number

    const table = await db.sql`SELECT * FROM {${name}} LIMIT {${limit}}`

    return table.rows ?? []
  }
  catch (error) {
    createError({
      status: 500,
      name: 'ServerError',
      cause: 'Internal Server Error',
    })
  }
})

Additional context
It seems to work fine if I add the {} around the variable but maybe that was intended and isn't documented.
Logs
near "?": syntax error

  at Database.prepare (node_modules/better-sqlite3/lib/methods/wrappers.js:5:21)
  at Object.prepare (node_modules/db0/connectors/better-sqlite3.mjs:24:29)
  at Object.sql (node_modules/db0/dist/index.mjs:34:38)
  at Object.handler (server/api/tables/[name].get.ts:9:1)
  at node_modules/h3/dist/index.mjs:1890:43
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
  at async node_modules/h3/dist/index.mjs:1962:19
  at async Object.callAsync (node_modules/unctx/dist/index.mjs:72:16)
  at async Server.toNodeHandle (node_modules/h3/dist/index.mjs:2249:7)

May I know what is the use-case for this? Because prepared statements are not supported for table names.
Now describing what happened in your case:

Case 1 which doesn't work:
DB0 thought that the name is meant to be used as prepared statement and following query was generated:
SELECT * FROM ? LIMIT ?. DB connector rejected that since table name is expected there.

Case 2 which does work (wrapped by braces):
DB0 has took it as a static parameter (parameter which need not be passed as prepared statement). This is to allow developer to use string literals without them being passed on as connection parameters. Yes this should be documented, I will raise the PR.

Important Note:
If this was for demonstration, it's okay. But never send static parameters from an untrusted source such as request. STATIC PARAMETERS ARE NOT SANITISED.

@amandesai01 I was creating a endpoint to dynamically fetch the table name e.g. GET /tables/users then would return this to the frontend to render the table. Maybe there is a better way to go about it, but I don't want to create multiple endpoints to fetch all the tables 😅

You must use some enums / strict validation. You may create a set of valid values and make sure value exists in set before sending it to query or whatever.

I run into this today. Thanks for the {} solution.


Broken link in "A Tool Developer's Guide..." for graph_metrics.py

Here is the link for graph_metrics.py in this tutorial but it's broken:
https://github.com/tensorflow/tensorflow/blob/master/tensorfl
ow/python/tools/graph_metrics.py
Update:
Just found other links to the files, such as freeze_graph() and tensorflow/core/framework/tensor.proto also not working.

Thanks for the report! I'd accidentally added new-lines to some URLs when I was formatting the markdown to an 80-column width, but I've just pushed a fix internally. This bug should be updated automatically once the change goes in, and then the website should get a push soon after that.

Actually I rolled back my internal change since it looks like #1174 / #1175 fix this and we don't want merging conflicts. Closing this bug.


Add automatic segmentation

based on VAD
probably simplest to have an own module

currently based on the silero software.


Cannot install python-olm on Windows via pip (Py38 amd64)

C:\>pip install python-olm
Collecting python-olm
  Using cached https://files.pythonhosted.org/packages/d4/a4/1face47e65118d7c52726dfa305410a96bc4a0c6f3f99c90bc7104aebf21/python-olm-3.1.3.tar.gz
Requirement already satisfied: cffi>=1.0.0 in c:\users\me\appdata\local\programs\python\python38\lib\site-packages (from python-olm) (1.13.2)
Requirement already satisfied: future in c:\users\me\appdata\local\programs\python\python38\lib\site-packages (from python-olm) (0.18.2)
Requirement already satisfied: pycparser in c:\users\me\appdata\local\programs\python\python38\lib\site-packages (from cffi>=1.0.0->python-olm) (2.19)
Building wheels for collected packages: python-olm
  Building wheel for python-olm (setup.py) ... error
  ERROR: Command errored out with exit status 1:
   command: 'c:\users\me\appdata\local\programs\python\python38\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\me\\AppData\\Local\\Temp\\pip-install-1myzii8l\\python-olm\\setup.py'"'"'; __file__='"'"'C:\\Users\\me\\AppData\\Local\\Temp\\pip-install-1myzii8l\\python-olm\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d 'C:\Users\me\AppData\Local\Temp\pip-wheel-vv1l60m8' --python-tag cp38
       cwd: C:\Users\me\AppData\Local\Temp\pip-install-1myzii8l\python-olm\
  Complete output (30 lines):
  'make' is not recognized as an internal or external command,
  operable program or batch file.
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build\lib.win-amd64-3.8
  creating build\lib.win-amd64-3.8\olm
  copying olm\account.py -> build\lib.win-amd64-3.8\olm
  copying olm\group_session.py -> build\lib.win-amd64-3.8\olm
  copying olm\pk.py -> build\lib.win-amd64-3.8\olm
  copying olm\sas.py -> build\lib.win-amd64-3.8\olm
  copying olm\session.py -> build\lib.win-amd64-3.8\olm
  copying olm\utility.py -> build\lib.win-amd64-3.8\olm
  copying olm\_compat.py -> build\lib.win-amd64-3.8\olm
  copying olm\_finalize.py -> build\lib.win-amd64-3.8\olm
  copying olm\__init__.py -> build\lib.win-amd64-3.8\olm
  copying olm\__version__.py -> build\lib.win-amd64-3.8\olm
  running build_ext
  generating cffi module 'build\\temp.win-amd64-3.8\\Release\\_libolm.c'
  creating build\temp.win-amd64-3.8
  creating build\temp.win-amd64-3.8\Release
  building '_libolm' extension
  creating build\temp.win-amd64-3.8\Release\build
  creating build\temp.win-amd64-3.8\Release\build\temp.win-amd64-3.8
  creating build\temp.win-amd64-3.8\Release\build\temp.win-amd64-3.8\Release
  C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -Ic:\users\me\appdata\local\programs\python\python38\include -Ic:\users\me\appdata\local\programs\python\python38\include "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt" /Tcbuild\temp.win-amd64-3.8\Release\_libolm.c /Fobuild\temp.win-amd64-3.8\Release\build\temp.win-amd64-3.8\Release\_libolm.obj -I../include
  _libolm.c
  build\temp.win-amd64-3.8\Release\_libolm.c(493): fatal error C1083: Cannot open include file: 'olm/olm.h': No such file or directory
  error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.24.28314\\bin\\HostX86\\x64\\cl.exe' failed with exit status 2
  ----------------------------------------
  ERROR: Failed building wheel for python-olm
  Running setup.py clean for python-olm
Failed to build python-olm
Installing collected packages: python-olm
    Running setup.py install for python-olm ... error
    ERROR: Command errored out with exit status 1:
     command: 'c:\users\me\appdata\local\programs\python\python38\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\me\\AppData\\Local\\Temp\\pip-install-1myzii8l\\python-olm\\setup.py'"'"'; __file__='"'"'C:\\Users\\me\\AppData\\Local\\Temp\\pip-install-1myzii8l\\python-olm\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\me\AppData\Local\Temp\pip-record-kcobwouw\install-record.txt' --single-version-externally-managed --compile
         cwd: C:\Users\me\AppData\Local\Temp\pip-install-1myzii8l\python-olm\
    Complete output (30 lines):
    'make' is not recognized as an internal or external command,
    operable program or batch file.
    running install
    running build
    running build_py
    creating build
    creating build\lib.win-amd64-3.8
    creating build\lib.win-amd64-3.8\olm
    copying olm\account.py -> build\lib.win-amd64-3.8\olm
    copying olm\group_session.py -> build\lib.win-amd64-3.8\olm
    copying olm\pk.py -> build\lib.win-amd64-3.8\olm
    copying olm\sas.py -> build\lib.win-amd64-3.8\olm
    copying olm\session.py -> build\lib.win-amd64-3.8\olm
    copying olm\utility.py -> build\lib.win-amd64-3.8\olm
    copying olm\_compat.py -> build\lib.win-amd64-3.8\olm
    copying olm\_finalize.py -> build\lib.win-amd64-3.8\olm
    copying olm\__init__.py -> build\lib.win-amd64-3.8\olm
    copying olm\__version__.py -> build\lib.win-amd64-3.8\olm
    running build_ext
    generating cffi module 'build\\temp.win-amd64-3.8\\Release\\_libolm.c'
    creating build\temp.win-amd64-3.8
    creating build\temp.win-amd64-3.8\Release
    building '_libolm' extension
    creating build\temp.win-amd64-3.8\Release\build
    creating build\temp.win-amd64-3.8\Release\build\temp.win-amd64-3.8
    creating build\temp.win-amd64-3.8\Release\build\temp.win-amd64-3.8\Release
    C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -Ic:\users\me\appdata\local\programs\python\python38\include -Ic:\users\me\appdata\local\programs\python\python38\include "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt" /Tcbuild\temp.win-amd64-3.8\Release\_libolm.c /Fobuild\temp.win-amd64-3.8\Release\build\temp.win-amd64-3.8\Release\_libolm.obj -I../include
    _libolm.c
    build\temp.win-amd64-3.8\Release\_libolm.c(493): fatal error C1083: Cannot open include file: 'olm/olm.h': No such file or directory
    error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.24.28314\\bin\\HostX86\\x64\\cl.exe' failed with exit status 2
    ----------------------------------------
ERROR: Command errored out with exit status 1: 'c:\users\me\appdata\local\programs\python\python38\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\\Users\\me\\AppData\\Local\\Temp\\pip-install-1myzii8l\\python-olm\\setup.py'"'"'; __file__='"'"'C:\\Users\\me\\AppData\\Local\\Temp\\pip-install-1myzii8l\\python-olm\\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record 'C:\Users\me\AppData\Local\Temp\pip-record-kcobwouw\install-record.txt' --single-version-externally-managed --compile Check the logs for full command output.

The Python bindings require the C lib and C headers to be installed beforehand. @turt2live could you lend a hand in Windows land?
I believe the error about the make file is safely ignored even though it shouldn't be there, this should be fixed by next release.
Thanks for the report.

The Python bindings require the C lib and C headers to be installed beforehand

Compiling on Windows is a terrible user experience for people who develope in Python and have no experience with C/C++. The knowledge isn't there, the build tools aren't there, and where are we supposed to get C libs/headers or place them? For example, I had to install the VS C++ build tools, which already required me to install a 4 GB package of Visual Studio on my computer only to compile a small module (which then still didn't work).
The best way for any Windows user is to have a compiled binary wheel uploaded to Pypi.
Would be great if that could happen when you release the next version.

Compiling on Windows is a terrible user experience for people who develope in Python ...

yes it is, particularly when you don't have a windows machine to build on... which is a big reason we don't ship windows binaries.

We might want to let CI build statically linked wheels using something like cibuildwheel.
CI would in this case push releases to PyPi as well, but that requires CI to be set up and I forgot what our stance on the legal side of things is with regards to this.

Anybody got it compiled?

@dirkbike Would it be possible to upload the wheel for cp38 and win64? This issue still seems to be unsolved.

This issue is still not resolved. Apart from the method @dirkbike mentioned, is there an easier way to install python-olm on windows?
It would be great if we'd get the .whl file.

Why not use wsl2? It works fine for me.


Migrate CI to GitHub Actions

Introduces a continuous_integration workflow to build and publish all Docker image variants to Quay.io. Replaces Travis CI configuration.
Resolves #11

Testing

Verify that CI workflow passed for all variants
Verify that this CI workflow run that was configured to run cipublish successfully published images to Quay
Verify that Travis checks did not run for latest commit

I'll be disabling the Travis project once this is merged.

Final build was cancelled because there isn't much sense burning two hours of build time on a markdown change.


Add Konstellation native token.

Can you also add .png image, Thanks !

Going to merge this as is.  Can you add the .png in a new PR?


dragonflybsd further utmpx db fn

r? @Amanieu
(rust-highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit da6078725cad7c43b565802fad186e370756b579 has been approved by Amanieu

:hourglass: Testing commit da6078725cad7c43b565802fad186e370756b579 with merge 2b9253a5c599b9c4b4eac10a19e9a980ff0d2d28...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing 2b9253a5c599b9c4b4eac10a19e9a980ff0d2d28 to master...


2nd cut of fossils data import

[ ] Handle institution ID (reference number at storage location)

Using updated spreadsheet provided by Elisabeth.
Process involves importing the spreadsheet to Postgres, creating normalized tables w/ UUIDs and then importing to Arches.
Currently finding an issue with importing relationships that needs to be resolved.

Successfully executed full data import into dev. Will continue work on this in next sprint.