Update modsecurity.conf-recommended

Add application/json as default to SecResponseBodyMimeType config for enabling JSON response parsing as default.

Thanks for the reply, I understand your point. A note in the reference manual about this would be useful.

Hi @1Jesper1,
The note has been added to the reference manual. Your contribution has been referenced on the revision history here: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)/_history
Thanks!


feat: add nextls

Hi!
First time making one of these. Please let me know of any adjustments needed. I have not been able to test it yet since I am not sure how. Will be working through that while this PR is open.

Hi!
NextLS author here.
I completely agree with what you've said here, and have tried to explain that mason is not as useful here, but...
eventually (in the coming months maybe) I hope to distribute NextLS as a compiler binary, rather than a bootstrapping script.
So, Mason would be useful then, and I think the mason registry here wouldn't need to change.
I plan on still having my plugins (neovim, vscode, etc) downloading it for you, but some people prefer mason.
I hope that helps in your calculus on whether to include NextLS in the registry.

@mhanberg Cool I had some issues with the Burrito wrapper on Ubuntu 20.04, it pulled binaries linked to glibc 2.34 (quite recent release) so I couldn't execute it. Not sure if it's a Burrito issue or nextls issue though.

That's a burrito thing.
I'm not sure if there is a way to lower it but I'll talk to the burrito author.
He was working on embedding musl statically instead of dynamic linking so that might make it easier to support older operating systems.

@williamboman is that a blocker? Just for clarity, if I need to get it to work on older operating systems.

Hey sorry I got distracted while reviewing this, forgot about this.
My final thought was about the name, I'm leaning towards nextls (or next_ls or next-ls), wdyt? It might cause people to think it's related to Next.js but I think the description and language mapping makes up for that. Also, what is the canonical binary name, nextls or next_ls?

@williamboman no worries at all.
let's go with nextls for name and binary

Thanks!
@jared-mackey  let me know if you get a moment to try this out


These are not the samples!

Apparently it is the microprofile-conference where the samples actually are. Can we delete this repo please. Super confusing.

They actually serve two different purposes.
This repo is about application samples that can be run on any of the implementations.
The microprofile-conference repo shows each service being run with a different implementation and them working together to be used in a UI


Update cloudwatch, dynamodb, kinesis, s3, sns, ... to 2.18.38

Updates

software.amazon.awssdk:cloudwatch
software.amazon.awssdk:dynamodb
software.amazon.awssdk:kinesis
software.amazon.awssdk:s3
software.amazon.awssdk:sns
software.amazon.awssdk:sqs

from 2.18.7 to 2.18.38.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #962.


fix: optimizeDeps.include missing in known imports fallback

Description
While debugging the issue fixed in https://github.com/vitejs/vite/pull/7214, I found that the same error can be reproduced in the current Marko test suite against vite 2.8.x (or any prev version) if you comment the dev step and we only test the build step.
If you don't run vite dev, the pre-bundling step isn't run, so the _metadata.json with the known imports isn't available and the build process then runs a fresh scan phase. For some reason, this scan phase seems to be given a different set of deps because I ended up with the same error then we are seeing in vite-ecosystem-ci. We need to investigate that afterward.
The issue was that optimizeDeps.include was being ignored in the build known imports fallback. Tested this PR against the marko CI removing the dev step and it is working correctly.

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

@DylanPiercey this PR doesn't fix marko when running a fresh SSR build in a project where there was never a dev run (so the cache dir with pre-bundling metadata is not present) because in the marko vite plugin you are only populating optimizeDeps.include for dev in the config. I think you should change it to always have optimizeDeps.include, even for build, something that may better prepare marko if Vite starts to use prebundle deps during build/ssr. See here:
https://github.com/marko-js/vite/blob/b0f2975bf5f6e6eb57c406a3405cd6a1b00dccf6/src/index.ts#L190
@bluwy I marked as ready for review, I think we should merge this one as explained in my previous comment.


Optional might need a .Value property

Casting is not the best way to access a value. Having .Value might be ok, if it is documented that it throws exception if does not have a value. ValueOrDefault makes sense, but not after a HasValue check.

ValueOrPanic?


Wrapper overall improvement with support for generation, langdetection and tokens endpoints, unit and integration tests, custom status code errors...

This PR is :fire:NOT BACKWARD COMPATIBLE:fire:. Please make sure you create a new major version (tag) when merging it.
What does this PR contains ?

:screwdriver: a fix for nlpcloud.Question.Answer invalid json tag value (string instead of answer)
:screwdriver: a fix for nlpcloud.LibVersions data structure
:screwdriver: a fix for optional parameters using pointers (optional means it can be not specified in a request, which means something different than being the default value of the underlying type. This is cleanly made possible using a pointer)
:superhero_man: an improvement of the nlpcloud.Client methods by using the same underlying function which follows the API specification
:superhero_man: an improvement of the nlpcloud.Client for interoperability, by giving it a sub-HTTP client to use for requests
:superhero_man: an improvement of the parameters given for each endpoint (except LibVersions which does not take some) using a data structure. This makes the API more cohesive and avoid having functions with a lot of parameters (this avoids shadowing the API)
:confetti_ball: the support of nlpcloud.Client.Generation, nlpcloud.Client.LangDetection and nlpcloud.Client.Tokens for their respective endpoints
:confetti_ball: the support for documented errors
:microscope: unit tests for the whole module with a code coverage of 100%
:microscope: integration tests for the whole module
:checkered_flag: an update to Go 1.17
:checkered_flag: an update of the README.md to make it cleaner (not documenting each nlpcloud.Client endpoint while the website does it already, and the wrapper does it a second time to make sure it's properly understood). Add badges to prettify the doc.

Discussions on the client interoperability
This PR claims to improve client interoperability by adding a parameter (the first) in the nlpcloud.NewClient function, which makes it not backward compatible. This one must be a valid nlpcloud.HTTPClient, which means it has to implement Do(*http.Request) (*http.Response, error).
The code makes sure it works with a *http.Client while it will most often get used to achieve this task.
Nevertheless, specifying the underlying HTTP client to use enables the developer (the one who uses the wrapper) implementing strategies on the Do method, as a proxy, a status checker, a circuit breaker... as a middleware.
This directly enables integration tests which proves its use case is legitimate.
Number of unit tests and integration tests
Looking at the unit and integration tests, you may think there are a lot of them for not so much. Indeed, there is a lot of duplications (e.g. to test custom status code errors).
Those duplications cannot be cleanly refactored in this state of Go while it would need generics for this. If you are trying to refactor this, you'll have to make an anonymous type to pass functions, making a wrapper for each one, passing the method as an argument with the parameters and expected results... which will make the tests a spaghetti code.
I do think it's better to get some duplications in tests than having an unreadable code.
Additional comments

this PR needs you to create a GitHub secret for the CODECOV_TOKEN used by the CI (see https://app.codecov.io/gh/nlpcloud/nlpcloud-go using the repo owner account), and to set an API_TOKEN that is able to perform integration tests on the NLP Cloud API. Notice for this last that you'll need to make sure than the contribution guidelines follows a fork-PR strategy to avoid leaking it, and double-check when someone modify the .github/workflows/ci.yaml file.
the header Content-type: application/json is not checked by the server, as it should be according to the documentation of custom error 422 | Unprocessable Entity
there is a typo in custom error 413 | Request Entity Too Large: "it too large" should be "is too large"

It looks like an impressive work @pandatix!
Let us review this ASAP!
Thanks a lot.

Thanks again @pandatix, I just merged your PR!
Once again, it's an amazing client you built here, congrats. It's well documented, tested, perfectly follows the Go style, and seamlessly integrates all the subtleties of the NLP Cloud API 💪🏻
It seems that integration tests break the Github CI because they require a valid API token. Maybe I should remove them from the Github workflows, what do you think?

Hello, I'm glad that you liked my work and pleased to read that it perfectly fits into NLP Cloud API !
For the API token issue, you have two choices:

Remove the integration tests but you won't be able to detect breaking changes that are not supported by the wrapper
Create an API token in your server (maybe a service account used for CI) that is able to perform integration tests. In this last case make sure you double check future changes to the .github.com/workflows/ci.yml while someone could try to leak it (basically it's not supposed to change while this workflow already well covers the module)

Thanks @pandatix !
I disabled the integration tests and I'll take some time to think about a good strategy. As this token will leak, we might want to enforce additional protection mechanism in order to avoid issues on the API side.
Thanks again!


Featured Articles Section

Add a Featured Articles section on the Dataguide for most recent articles.

Hi @imchairmanm Is this still relevant? If not, could you close this issue?
If yes, add me as assignee :)

@nikolasburk


Multi controller fix ludo

This adds modification for embedded_s.launch file and mult_embedded.launch files to allow for controlling 3 cameras. It would require to add another camera to multi_embedded.launch, but I'll wait until the wiring for the arm is done.
This PR is paired with the other PR with the same name in the repository Markhor.

Pas mal straight forward, je me demandes juste pourquoi on turn off le rgb processing sur multi embeded et on le turn on sur embeded_s

@benmalenfant that's a good question. Truthfully, I'm not sure what those options do. At first, I disable everything to avoid having issue with the camera, since they took as much time to set up as the fix for the controllers.
I'll look into it and try to test what does options do and if they are worthwhile to enable.
Also, I'm fairly certain that if we set up an arg tag in a parent launch file, it will be use inside the child launch file. So setting to disable in multi_embedded.launch and calling embedded_s.launch will keep the option disable inside embedded_s.launch.


Add feature to select 1/3/auto phases to be used in ECO+ mode

Describe the solution you'd like
The latest zappi app has support to set the number of phases to be used in ECO+ mode (see https://myenergi.info/app-update-3-3-1-t12674.html#p122029)., can be 1, 3, or auto
Additional context
See https://github.com/CJNE/pymyenergi/issues/28 for the pymyenergi related issue

Would be a great feature, because the integrated solution of Zappi, when setting is "auto", is sometimes not a good choice. In my case and at partly clouded weather, the Zappi is spending more time waiting to change from one to three phase and back, than it would charge constantly at one phase. Especially, when other consumers switch on and off.
Greetings, Heiko

I have asked myenergi on the API, no feedback yet

That’s because you can’t switch phases.

This can’t be achieved in a Zappi or any other EVSE, don’t should be closed

The myenergi app does provide the ability to select 1/3/auto phase charging in ECO+ mode, a recent addition of the app.

Yes, but titles need to be clear and now it has been changed!

I will implement this asap

not sure if it helps. I monitored the requests and found out the command for phase switching.
I mentioned it in the other GitHub project describing the API:
https://github.com/twonk/MyEnergi-App-Api/issues/25

Dear all,
just want to ask about the progress of this?
Background is, that the automatic switching by Zappi does not work very well (sometimes the system is taking more time switching than loading :-).
Therefore, my plan is do something more clever with automations from Homeassistant. For example much longer retention time of phase before switching from 1 to 3-phase loading.
Anyway, this requires the possibility to switch in HA.
Does anybody observe the same problem with Zappi's automatic switching?
Any advice, if setting in Zappi can be adjusted?
Best regards,
Heiko

The code necessary is ready for review on my PR.

The code necessary is ready for review on my PR.

For some reason, one of the automatic checks is failing (pre-commit). I am not sufficiently experienced with Github to figure out which file(s), and what's the reason it fails. Perhaps have a look at that, because it seems that once this check is OK, the PR could be pushed through.

I think two linters are making opposite changes, also happens in the scheduled action, so not related to my PR

I think two linters are making opposite changes, also happens in the scheduled action, so not related to my PR

Since I don't even know what a 'linter' is, I can't help with that. Is there someone else who could look into this and figure out what's causing the check(s) to fail? Perhaps the person who created the scheduled actions.


Update Chart.js support

HTMLUnit currently includes support for Chart.js version 2.9.4 (https://github.com/HtmlUnit/htmlunit/tree/master/src/test/resources/libraries/chartjs/2.9.4) but the latest version is currently 4.4.3 (https://www.chartjs.org/docs/latest/api/).
Using the latest version of Chart.js should be possible, but fails with a JavaScript error ("redeclaration of const..."), that seems to be related to a rhino bug (https://github.com/mozilla/rhino/issues/326).

I saw a commit  related to the mentioned "redeclaration of const..." in the latest 4.3.0 release and gave it another try.
Unfortunately it is still failing. This time it seems to be related to using default parameters ("missing ) after formal parameters")...

@blasss Yes i know (i also did a quick test) but there is hope for this problem also; see https://github.com/mozilla/rhino/pull/1481


Broken link - bounces

Expected content
Base link goes to an error 404 page
"You can also retrieve and edit your list of bounces through our Web API"
Actual content
https://github.com/sendgrid/docs/blob/develop/content/docs/glossary/bounces.md

Hi. It's working fine. Please check the following link.
https://sendgrid.com/docs/glossary/bounces/
When you click on "You can also 'retrieve and edit your list of bounces' through our Web API.",
you will be directed to
https://sendgrid.com/docs/API_Reference/Web_API/bounces.html


Foundry v9.255 compatability

Hello!
I'm not sure if this module is still being updated, but I wanted to report that as of v9.255 the controller box seems to have some issues with the Retro UI - the side bar of the PokeDex which contains the interior of each controller section doesn't appear, it simply widens the main PokeDex icon.

Any thoughts on how whether/how this could be addressed?
Thanks!

Tried looking at the code but I can't make heads or tails of it unfortunately.

I know styling rules have changed in a few areas, the main buttons being one of them. I haven't been updating this theme, but the fact that anyone is using it is enough reason to fix it.

At the moment I was able to make it work with a hack job just removing the pokedex image from the tools section, still have minor graphical glitches but usable.


Update seq.unfold['state,'t]-function-[fsharp].md

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

File
Status
Preview URL
Details

docs/conceptual/seq.unfold['state,'t]-function-[fsharp].md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Remote SFO IdP metadata and AuthnConextClassRefs must be configurable

This issue is imported from pivotal - Originaly created at Jun 14, 2019 by Thijs Kinkhorst
To make SFO calls, engine needs the config of the SFO IdP Entity and the SFO AuthnConextClassRefs to use. Because these differ from the AuthnConextClassRefs that engine must communicate to SPs, a "translation table" is needed.
** SAML Metadata **
In order to be able to call the remote OpenConext-Stepup SFO endpoint, EB needs to know its metadata (I.e. the metadata of the SAML IdP Entity published at https:///second-factor-only/metadata):
Needed information is:

EntityID
SSO location
SAML Signing Certificate

These can be global configuration file parameters. We do not want to dynamically import/configure these from the metadata published by the Stepup-Gateway. These parameters must not be mandatory for regular EB operation (since an install may not also have a OpenConext-Stepup setup).
** AuthnConextClassRefs **
The AuthnConextClassRef values are specific to an OpenConext-Stepup installation. Moreover the values used by the "standard" authentication endpoint of the Stepup-Gateway (which engine will emulate) differ from those used by the SFO endpoint. This means that a translation table is required to be able to convert between two.
Additionally engine needs to be able to express to the SP that, if allowed by the configuration, a user did not have an (active) token that allowed authentication at the requested level  (see: Scenario 3 in https://www.pivotaltracker.com/story/show/166729297). This corresponds to the LoA 1 authentication policy of the Stepup-Gateway.
So the needed information is:

The AuthnConextClassRef to use for LoA 1  (i.e. the value of gateway_loa_loa1 in https://github.com/OpenConext/Stepup-Gateway/blob/develop/app/config/parameters.yml.dist#L121)
A two-way mapping from "AuthnConextClassRef configured in manage and used in the assertion to the SP" to "AuthnConextClassRef to use with she SFO endpoint of the Stepup-Gateway". For the Current Stepup-Gateway this table will have two entries (but I suggest not limiting the number of entries in this table):

gateway_loa_loa2 <-> second_factor_only_loa_loa2 (I.e. https://github.com/OpenConext/Stepup-Gateway/blob/develop/app/config/parameters.yml.dist#L122 to https://github.com/OpenConext/Stepup-Gateway/blob/develop/app/config/parameters.yml.dist#L126)
gateway_loa_loa3 <-> second_factor_only_loa_loa3 (i.e. https://github.com/OpenConext/Stepup-Gateway/blob/develop/app/config/parameters.yml.dist#L123 to https://github.com/OpenConext/Stepup-Gateway/blob/develop/app/config/parameters.yml.dist#L127)

These can be global configuration file parameters. These parameters must not be mandatory for regular EB operation (since an install may not also have a OpenConext-Stepup setup).
Estimation: 6 - 8h

Both the SFO endpoint data and the lookup table can be neatly expressed in an SFO entity/value objects (Michiel Kodde - Jul 9, 2019)


Added support for Select field type.

I'm working on a couple of plugins, and they will require a new type of field in the UI : Select (same as text-align, but configurable from the plugin).
Thanks.

Corresponding PR for the API : https://github.com/unix-streamdeck/api/pull/7

There you go, updated go.mod to point to API 1.0.1

you'll need to run a go mod tidy first to update the go.sum file, so references get updated, otherwise it could cause errors on go install

Oh sorry! I'm a go beginner, I just started last weekend, specifically to work on some plugins for this project.

yeah no problem, all of this is my first go project too :laughing:


Expanded children

It was working before, I will try and restart my emulator and see if that solves the issue

@ryle3
can you provide your flutter doctor -v, your flutter run -v and a minimal reproducible code sample

@ryle3
Please elaborate on your issue and provide above requested details if issue persists.

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


add some debug logging to help diagnose token expiration/refresh issues for PGP

description of the issue:
"tokens expire after a few hours (days?), the oauth refresh doesn’t appear to work"

Set OAUTH2_DEBUG to true in production, hoping that can capture the refresh issue.


commando's

I did enter the lines you mentiond in the text into the config Yaml file, but what are the commands?
How can I put a light on or off?
Its nt total clear for me how to do this.

As of now they don't show up automatically, you have to find them in the entity list and/or your automation


Device Request - [Immax NEO Smart soil moisture and temperature sensor] - [_TZE200_2se8efxh] / [TS0601]

Device Information

Device Name: Immax NEO Smart soil moisture and temperature sensor
Device Model: _TZE200_2se8efxh / TS0601
Device Description: Measure soil temperature and humidity
Link to device image: https://www.immax.eu/immax-neo-smart-soil-moisture-and-temperature-sensor-zigbee-p18721/

Device Interview
{

  "ids": {
    "modelId": "TS0601",
    "manufacturerName": "_TZE200_2se8efxh"
  },
  "endpoints": {
    "ieeeAddress": "a4:c1:38:80:07:09:24:14",
    "networkAddress": 12052,
    "modelId": "TS0601",
    "manufacturerName": "_TZE200_2se8efxh",
    "endpointDescriptors": [
      {
        "status": "SUCCESS",
        "nwkAddrOfInterest": 12052,
        "_reserved": 20,
        "endpointId": 1,
        "applicationProfileId": 260,
        "applicationDeviceId": 81,
        "applicationDeviceVersion": 0,
        "_reserved1": 1,
        "inputClusters": [
          4,
          5,
          61184,
          0
        ],
        "outputClusters": [
          25,
          10
        ]
      }
    ],
    "deviceType": "enddevice",
    "receiveWhenIdle": false,
    "capabilities": {
      "alternatePANCoordinator": false,
      "deviceType": false,
      "powerSourceMains": false,
      "receiveWhenIdle": false,
      "security": false,
      "allocateAddress": true
    },
    "extendedEndpointDescriptors": {
      "1": {
        "clusters": {
          "groups": {
            "attributes": [
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 0,
                "name": "nameSupport",
                "value": {
                  "type": "Buffer",
                  "data": [
                    0
                  ]
                },
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 65533,
                "name": "clusterRevision",
                "value": 2,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              }
            ]
          },
          "scenes": {
            "attributes": [
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 0,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 1,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 2,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 3,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 4,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 65533,
                "name": "clusterRevision",
                "value": 2,
                "reportingConfiguration": {
                  "status": "NOT_FOUND",
                  "direction": "reported"
                }
              }
            ]
          },
          "basic": {
            "attributes": [
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 0,
                "name": "zclVersion",
                "value": 3
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 1,
                "name": "appVersion",
                "value": 72
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 2,
                "name": "stackVersion",
                "value": 0
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 3,
                "name": "hwVersion",
                "value": 1
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 4,
                "name": "manufacturerName",
                "value": "_TZE200_2se8efxh"
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 5,
                "name": "modelId",
                "value": "TS0601"
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 6,
                "name": "dateCode",
                "value": ""
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 7,
                "name": "powerSource",
                "value": "battery"
              },
              {
                "acl": [
                  "readable",
                  "writable",
                  "reportable"
                ],
                "id": 65502
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 65533,
                "name": "clusterRevision",
                "value": 2
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 65534,
                "name": "attributeReportingStatus",
                "value": "PENDING"
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 65506
              },
              {
                "acl": [
                  "readable",
                  "reportable"
                ],
                "id": 65507
              }
            ]
          }
        },
        "bindings": {
          "ota": {},
          "time": {
            "attributes": [
              {
                "acl": [
                  "readable"
                ],
                "id": 65533,
                "name": "clusterRevision",
                "value": 1
              }
            ]
          }
        }
      }
    }
  }
}

Additional Comments:

Note:
Store link - https://www.alza.cz/immax-neo-smart-cidlo-pudni-vlhkosti-a-teploty-zigbee-d7862464.htm?o=5

How to interview a device

Add the device as a generic Zigbee device in Homey
Navigate to https://developer.athom.com/tools/zigbee.
Interview the device, the button for this is to the right of the device in the list of Zigbee units.
Click the copy button/icon to capture the device information.
Paste the copied information above.

Note: To be able to add more devices to the Tuya Zigbee app, we rely on community members like you to provide interviews of the devices you want to be added. Thank you for your contribution!

Added to existing Soil Sensor driver. Get back to me if anything does not work.


Fix server error when a user doesn't input an argument into /plytransfer

from commit:
target:getChar() assumes target exists, return earlier if it doesn't. get rid of duplicate string notification.
Secondly I want to make it known the reason I named this branch "temp-fix" is because I have a strong want to add to the inbuilt argument system an automatic argument type checking/handling and possibly even deprecating the usage of things like ".findPlayer()" in commands by automatically running something like that when a player is wanted. Still figuring out the details as we'll want to make sure we retain backwards compatibility with the argument system used right now.

While this does fix the error, this also removes the notification that no player/char was found. I'd rather have it, that way the player running the command gets informed why the command failed

While this does fix the error, this also removes the notification that no player/char was found. I'd rather have it, that way the player running the command gets informed why the command failed

nut.command.findPlayer already gives a notification if it doesn't find a player


Upgrade image's packages

Image scan detected vulnerabilities in the image, hence added upgrade command to Dockerfile

The base container image is :latest so on a rebuild it should pick up the ubi 9.5 image. That should have most of the updates and then the microdnf will sweep in any recent patches.
FROM registry.access.redhat.com/ubi9-minimal:latest


Options: add JSON config

refs https://github.com/prettier/prettier-chrome-extension/issues/68
Here's an initial implementation of the JSON configuration option. It doesn't have any styles, but all the functionality should be there! Will try to follow up with styles for all the Options next. I think once we complete the styles we'll be ready for v1 - I don't have any other outstanding issues.

Will try to follow up with styles for all the Options next.

I'd like to help out with this, but I wanted to finish the tests first, which could take a while.

I think once we complete the styles we'll be ready for v1 - I don't have any other outstanding issues.

Would you mind checking my 1.0 milestone (which is ordered from high to low priority)? I'd like to know if you think any of these things should wait for a future release like 1.1 or 2.0.

Separating components into separate files is a great idea, but I prefer to avoid components directories, as it's more useful to organize files by domain/usage than type.

Do you have an alternative for how you think it should be organized right now? Or are you thinking of keeping a flat directory structure in src/options/ right now? In a project this small, I don't think there is much to gain or lose by moving files around, so I don't think it's worth bikeshedding too much on it. If you have another way you think works better, happy to move things around.

Separating components into separate files is a great idea, but I prefer to avoid components directories, as it's more useful to organize files by domain/usage than type.

Do you have an alternative for how you think it should be organized right now? Or are you thinking of keeping a flat directory structure in src/options/ right now? In a project this small, I don't think there is much to gain or lose by moving files around, so I don't think it's worth bikeshedding too much on it. If you have another way you think works better, happy to move things around.

I was thinking of a flat directory structure to keep things simple for now, like what we have in src/content.

I explained more about my original UI idea in https://github.com/prettier/prettier-chrome-extension/issues/68#issuecomment-549489261, though we don't have to follow it if you don't want to.

I was thinking of a flat directory structure to keep things simple for now, like what we have in src/content.

Sounds fine to me.

I explained more about my original UI idea in #68 (comment), though we don't have to follow it if you don't want to.

Thanks for explaining that. I'm definitely not opposed to doing it that way, and here are some thoughts/discussion points around it:

If we do it this way we can get rid of storing the JSON string at all, and go back to having one options (prettierOptions?) key, and just derive the text box value by running JSON.stringify() on the options in storage.
My biggest question is around validation/supported options. I guess we could keep a whitelist of supported options in the version of Prettier we're running (I don't think there's a programmatic API to get this information, but I don't think these change very often so it's probably not a big deal), and display an error message if there are properties in the config that aren't supported. I want to avoid a situation where we're storing arbitrary data in Chrome storage.

If we do it this way we can get rid of storing the JSON string at all, and go back to having one options (prettierOptions?) key, and just derive the text box value by running JSON.stringify() on the options in storage.

Exactly. We could even run Prettier when loading the settings so the formatting is consistent regardless of how it was created.

My biggest question is around validation/supported options. I guess we could keep a whitelist of supported options in the version of Prettier we're running (I don't think there's a programmatic API to get this information, but I don't think these change very often so it's probably not a big deal), and display an error message if there are properties in the config that aren't supported. I want to avoid a situation where we're storing arbitrary data in Chrome storage.

Adding validation is a good idea, but figuring out edge cases of how to run it could be tricky. What if a user pastes in an invalid config and then switches to the form (which can't be displayed properly)? When do we validate and how?
I can't seem to find an API for the config options either. Could we use the keys of defaultOptions instead? Those are the only options supported by the form UI anyway, so we wouldn't have to worry about removing any to make them compatible. We could also add

Adding validation is a good idea, but figuring out edge cases of how to run it could be tricky. What if a user pastes in an invalid config and then switches to the form (which can't be displayed properly)? When do we validate and how?

Right - this is my biggest concern and why I went with what seemed like the simpler approach of giving control to the user (if it's invalid, it's on the user to make it valid). That being said, I think there's an easy fix. Currently, there's a "Save" button that we can utilize for validation (it currently validates whether it's valid JSON or not, but we include checking the keys for valid whitelisted properties as well). If it's not valid, it shows an error and doesn't update the configuration. We should also be able to add some nice error messaging (doubleQuote is not a valid Prettier configuration option, or singleQuote must be a boolean). I'll work on implementing this.

Thanks. I don't mean to make this too complex. Free to split up PRs if it's useful and let me know if you need help.

Sorry for the delay - finally was able to get back to this. I regenerated the lockfile because I ended up having merge conflicts and was worried about editing it manually 😬
Please let me know what you think! The validation is strict, but I think it has to be so that we don't allow users to save arbitrary data in Chrome Storage.

@nickmccurdy Friendly ping - does the changes ease your concerns?

This is ready for re-review. Would love to land this!

Thanks! We can talk about this separately, but how would you foresee autosave working without constantly showing “malformed JSON” errors?

Good question, we'd probably have to display errors when invalid and only update the saved config when valid

I initially actually did implement it that and thought the UX was frustrating. If we can come up with a way to do that that doesn’t have guaranteed errors in your face as you type, I’m definitely down for exploring that!


if sofa feed is used and contains no supported devices, unsupported ui is shown

https://github.com/macadmins/sofa/commits/main/cache/gdmf_cached.json
the cached json does not have data for say 14.3, so you get the unsupported UI.

Will err on the side of caution moving forward until I better understand the sofa issue and gdmf behavior
https://github.com/macadmins/nudge/commit/a478a17c3d1677f17ab1a20387c7e8055b847a08

Kyle Erickson
to help resolve the issue where the SOFA feed doesn't have the list of supported devices, it looks like you might be able to use the models aspect instead. E.g. if model is Mac15,13, you can check the supported macOS releases for that model (e.g. Sonoma 14), and use that to determine supported? Might be some added logic, not sure but throwing it out there as an idea.
erik
SOFA team is discussing now what we can do to fix this, even though this is technically Apple's fault for removing them from gdmf
Kyle Erickson
That's fair. It was mostly the thought that if the latest version of macOS is 14, you only need to match the major version to determine if it's supported or not, and those keys are already present in the feed for each model.
erik
oh hm!
erik
that's actually a really good point
erik
it's literally the same thing I'm telling the sofa team to do right now, but at the feed level
Kyle Erickson
Yeah. In the off chance Apple splits an update again you'd still need to use softwareUpdateID to determine if the update was applicable to a given system though. Although if behind the scenes the SOFA team is mapping softwareUpdateID to the hardwareModel it might be fine to swap out on the feed itself. I'll leave it to you and the team and we'll go from there.

https://github.com/macadmins/sofa/pull/104 was merged and now addresses the overall issue here. This should now work as I originally intended.


download fail

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

pls fix it

No information provided or steps to replicate - Closing


Vector XYZ data source does not show in Inspect view

Maputnik version: 2.0.0
Browser: Firefox 126.0
OS: Windows
When importing a vector XYZ data source with a .pbf link, the features are not shown in inspect view. The data only becomes visible on map view in case a style is imported or style layers are defined (which is hard without the inspect view):
Steps to reproduce the behavior:

For the Austrian cadastre tileset, open https://maplibre.org/maputnik/?style=https://kataster.bev.gv.at/styles/kataster/style_vermv.json to import style and data
Features can be seen on map view but not on inspect view, unless a layer is selected, then this layer is visible in inspect view
Start again with empty style and add vector XYZ source: https://kataster.bev.gv.at/tiles/kataster/{z}/{x}/{y}.pbf
Nothing is visible on map or inspect view, unless a layer is defined (e.g. line layer, source layer 'pg')
kataster-at-test-style.json

Another example:
Another example is the Austrian basemap.at when added as a vector XYZ https://mapsneu.wien.gv.at/basemapv/bmapv/3857/tile/{z}/{y}/{x}.pbf. A layer only becomes visible in inspect view when defined and selected (e.g. line layer BEV_BEZIRK_L_BEZIRKSGRENZE on zoom and location #8.14/48.222/16.361 )
basemap-at-test-style.json
Both tilesets don't have a proper TileJSON according to TileJSON specs. I'm wondering if this is a prerequisite for a proper use of vector tiles in Maputnik.

I see, thank you for your quick reply.


ci(pr-title): use a new shared action

Switch from jef/conventional-commits-pr-action to bonitasoft/actions. It provides better defaults and more features. Also run the workflow on pull_request_target to ensure that PR created from fork repositories.

ℹ The workflow will run once this PR is merged. For pull_request_target event, the workflow definition is taken from the default branch. Currently, it doesn't exist, so the workflow doesn't run.


$ionicView.loaded inside ionicModal

Does ion-modal-view have a method to listen like ion-view's $ionicView.loaded?
Do we have to use modal.shown instead?
Thanks.

Greetings @alvaromb!
We are now requiring all issues to be submitted through our custom issue form so that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
This issue will be closed if not resubmitted through the form. Please fill out the rest of the form so that we may assist you.
Thank you for allowing me to assist you.

Greetings @alvaromb!
My sensors indicate that you have created an issue on our tracker requesting usage help, rather than an actual error with Ionic framework.
This GitHub issue tracker is used to track framework features, problems, and development.
If you wish to get help using the framework itself, the recommended place is the forum. There are many humans there who would be happy to offer sage advice.
Thank you for allowing me to assist you.


This package should allow specifying the Validator binary path

what happens now
The js-validator package CI tests cannot use this package to determine if a given PR is going to work.
what I would like
This package should be able to be used by the js-validator package to run smoke-screen tests.
additional context
I'd like to be able to pass in a specific path to the validator binary.  So that PRs in the js-validator package can be tested via CI using smoke-screen tests.

fixed by #423


Create new task for pushing Docker images from Service Fabric applications

New capabilities are being added to the Visual Studio tools for Service Fabric that allow a Service Fabric Application project to reference Service projects that represent Docker containers.  The MSBuild packaging logic of the Service Fabric Application project will build Docker images for those projects.  But those images need to be pushed to a Docker registry and the service manifest files of those service projects need to be dynamically updated to reflect the new name of the pushed image.  To do this, we're defining a new VSTS task that provides this functionality.
The task's implementation is based on the already existing Docker task, referencing some of the shared modules that the Docker task uses.  So it has very similar settings as the Docker task to provide consistency.  The difference is that this task requires the ability to push multiple images that are only known at build time.  For this reason, the task accepts a file path to a text file that defines the names of the images to be pushed rather than a string property for a single image name as the Docker task does.
After the task has pushed the images to the selected registry, it gathers the hash value of those associated images and computes the new image name using that value.  It then updates the associated service manifest so that the manifest now uses the new image name.  This allows Service Fabric to reference the image properly in the registry that now stores the image.
Also, the task follows the same functionality as the Docker task in regards to including additional custom tags and tags associated with SCC in the images that are pushed.

Seeing as many of these files are common to this task, the docker task and the docker-compose task. Would it be possible to move them to a Commmon\Docker folder to enable easier servicing and prevent drift? See the task AzureResourceGroupDeployment and the common folder azure-arm-rest for an example of how this could work

@NCarlsonMSFT, @bishal-pdMSFT: I've refactored things to no longer need a new task.  The work is now split across three tasks: Docker, ServiceFabricUpdateAppVersions (renamed to ServiceFabricUpdateManifests), and ServiceFabricDeploy.

Adding @jikuma to review docker task changes

@jikuma: Can I get a review from you please?


Link points to archived GitHub repo

The doc page "Build a single page web application using OAuth and ADAL.JS with AD FS 2016 or later" points to sample GitHub repo Azure-Samples/active-directory-angularjs-singlepageapp which has been archived. The link (and likely the docs) should be revamped to point to a current repo.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 564391c0-ad11-762f-41c9-cc898c7b3a46
Version Independent ID: 04020c6c-d236-3dcb-5be2-f444d05d214e
Content: Build a single page web application using OAuth and ADAL.JS with AD FS 2016 or later
Content Source: WindowsServerDocs/identity/ad-fs/development/Single-Page-Application-with-AD-FS.md
Product: windows-server
Technology: ad-fs
GitHub Login: @billmath
Microsoft Alias: billmath

#assign:IngridAtMicrosoft

#label: "doc-bug"

Referenced Windows Server page no longer exists. Keeping open as the Azure page is already assigned to content developer.

Thank you for submitting this issue.  Unfortunately, due to high volumes I was unable to respond to this in a timely manner.  At this point, I am going to close this due to it's age and the possibility that it may have been addressed.  If this is still a problem, please consider submitting a new issue.  Thank you.
#please-close


IE script errors

There is an IE related issue that is being exposed in downstream libraries originally reported here: https://github.com/FormidableLabs/victory/issues/1595

see https://github.com/d3/d3-array/releases/tag/v2.0.0


disable MoveOnly and MoveOnlyClasses feature flags

We don't want production compilers having
these features enabled when they are not
able to handle future swiftinterface files
that have these types in them.
part of rdar://106262652

@swift-ci please smoke test

@swift-ci smoke test macos platform


config-linux: describe more about rootfs mount propagation (cont'd)

I offered to rebase #975 by @dongsupark, which had grown conflicts with master and wasn't getting much attention anymore, so here it is.
Fixes #973
Closes #975
Edit: following review, does not include the portion about shared+slave from #975.

LGTM
Thanks! (I think we should discuss shared+slave separately :+1:)

LGTM


configpath and feature flags do not filter

Hello,
I was trying to score an sbom using a modified features.yaml file. However, none of the categories or criteria would be ignored when I set enabled to false.
Also, when I try to run the -f or --filter command with a feature string, nothing happens and it defaults to the default output with all features.
I downloaded sbomqs using Go Install with v0.0.13 on a Windows/amd64 platform.
Currently, I have tried these two flags with the sample files provided with the tool.

@mattymo30 thanks for informing me, I am working on a fix for this issue, should be in the v0.0.14. May i ask what is your usecase.

@riteshnoronha Hello,
I have been testing with the samples files the tools provides in the samples folder.
In the features.yaml file, I have made several criteria and categories set to false for enabled. It was more to understand how the flags work and how to customize the scoring through the file.
This is similar to my usage of the -f flag, I was learning how to use this tool with the several sample files provided.
Both just default to the default output for scoring, even when I enter a valid configpath or feature.

@mattymo30 yes this feature broke when i made somechanges in v0.0.10. I will be fixing this for v0.0.14. Will msg you when it starts working. Let me know if this is blocking any work for u, i can expedite the fix.

@riteshnoronha No rush! Thank you!

@mattymo30 v0.0.14 has been released, it should work now. Let me know if you find any more issues.

@riteshnoronha Thank you!


How to set post_login_redirect_uri based on original url

I have following entries in my staticwebapp.config
   "routes": [
      {
        "route": "/docs*",
        "allowedRoles": [ "authenticated" ]
      },
      {
        "route": "/login",
        "redirect": "/.auth/login/aad?post_login_redirect_uri=https://mydomain.com/docs/home"
      },
      {
        "route": "/logout",
        "redirect": "/.auth/logout"
      }
    ],
    "responseOverrides": {
      "401": {
        "statusCode": 302,
        "redirect": "/login"
      }
    },

All this works, but there is one issue. Let's say I give someone a direct link to a page like
https://mydomain.com/docs/tech/staticwebapps
and let's say the user is not logged in. This based on responseOverrides takes to the user to /login & on login takes him to   https://mydomain.com/docs/home because it is hardcoded above
While you want the user to be taken to https://mydomain.com/docs/tech/staticwebapps ( the original url he clicked )
Is there a way to fix this just using the config where the post login url is dynamic based on the original url ? Or this needs to be done in the page in code only ?

Found the answer in another old issue https://github.com/Azure/static-web-apps/issues/502


[RHCLOUD-26967] Enhance Search Results: RHEL Inventory Systems

@rsun19 can you resolve the conflicts?

done


Report: indicate which run/whatever a report is referring to somehow

commit number perhaps
filename? Maybe that's just one report
[See #469 for how to make a link to an action in the action itself, though that's complicated and may make life more complicated for the developer. See the discussion in that issue.]

I think GitHub has taken care of this by letting you look back at different test runs. We ourselves have given a timestamp to the test so each run does have a uniquely named artifact.


Move to setup-dotnet v3

Will be rolled out as part of https://github.com/pulumi/ci-mgmt/pull/669

@danielrbradley - doing it here first serves as a canary to see if the behavior is as expected. It turned out we did catch a missing update on pulumi-package-publisher when we merged to default, so while this is slow and manual, it saved us from trouble this time around.


thanks nigga

cool project. double thanks for not using javascript.
I've got the n-word pass

Thanks..?


grammar edits to datadog helm docs!

Is this a new chart
No.

NOTE: We're experiencing a high volume of PRs to this repo and reviews will be delayed. Please host your own chart repository and submit your repository to the Helm Hub instead of this repo to make them discoverable to the community. Here is how to submit new chart repositories to the Helm Hub.

What this PR does / why we need it:
Grammar edits to the Datadog Helm chart docs.
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md
[ ] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @vboulineau

@cswatt LGTM. But you'll need to sign DCO and bump chart version.

/ok-to-test


Add seconds() method to Timestamp

Just a little thing I found useful when working on contracts.
For user-provided times, we usually would prefer second values, this allows us to more easily compare env.block.time with a seconds-based timeout.
Does this need/deserve a CHANGELOG entry?

Makes sense to me in general. However, if we go that route I would like to implement the whole story. There are two ways to use such a timestamp:

Use the nanoseconds since epoch directly
Destruct into seconds since epoch plus nanoseconds since this second

The second one is documented in the 0.14 MIGRATING entry:
let seconds = env.block.time.nanos() / 1_000_000_000;
let nsecs = env.block.time.nanos() % 1_000_000_000;

Those components are named the fgollowing way in other libraries:

Go Time: func (Time) Unix and func (Time) Nanosecond
Rust chrono: timestamp and timestamp_subsec_nanos

I think we can drop the terms "timestamp" and "unix" as this is already encoded in the Timestamp type. But otherwise follow the  chrono pattern and have:

Timestamp::nanos Returns the number of nanoseconds since the midnight on January 1, 1970, UTC. This is a UNIX timestamp with no leap seconds.
Timestamp::seconds Returns the number of seconds since the midnight on January 1, 1970, UTC. This is a UNIX timestamp with no leap seconds.
Timestamp::subsec_nanos Returns the number of nanoseconds since the last whole second. The return value ranges from 0 to 999,999,999.

The above code would then become:
let seconds = env.block.time.seconds();
let nsecs = env.block.time.subsec_nanos();

That sounds good.
The only addition to the PR would be adding

Timestamp::subsec_nanos Returns the number of nanoseconds since the last whole second. The return value ranges from 0 to 999,999,999.

Correct?

(And updating associated docs and usage) Correct?

Yes. Especially docs deserve some love as the number of method increase.

Hijacking this and finishing up!

Looks good. Just the CHANGELOG entry

One day I'll learn.

Rebased to resolve conflicts.

Looks good. Could you update this example as well? https://github.com/CosmWasm/cosmwasm/blob/main/packages/std/src/types.rs#L39-L41 It will become much nicer with this change.

One day I'll learn.

One day we have a bot that reminds everyone


Refactored state access level by renaming state field to restriction.

Please change client view and then test.

Please test again, there was a migration conflict.


[Silabs] Drop BLE connection on endpoint close

Problem
When a BLE endpoint is closed on the peripheral side, the associated connection is not automatically closed.
Change overview
Implement connection closing for Silabs platform.
Testing
Tested on Silabs EFR32 examples with chip-tool.
Cherrypick of https://github.com/project-chip/connectedhomeip/pull/36336.

@andy31415 Could you help merge this PR? It's a very small change.


[SkillsMenu] Upgrading skill now unlocks next skills

Changes

SkillInstance now tracks an unlocked status and the unlocked skills
SkillInstance now accepts 2 callbacks: on_new_skills_unlocked, and on_skill_unlocked
SkillHolder uses on_new_skills_unlocked to unlock the right instances
SkillMenuButton uses the on_skill_unlocked to render the button

Put in some test code again to test:

Great job! From what I'm gathering, you're about 75% done now. I'm going to accept the commit. There's just a few more things left for you to do in regards to this:

The visual branching of the skills, the tree part. For future proofing, we could try putting the displayed skills in a scroll container.
The upgrading of the class level. This is what boosts the related character's attributes by that class' growth points. Skill points are used for this. I don't think we have to worry about implementing a CharacterClassInstance object. We can just have a button that the player can press on that's tied to that character's CharacterClass.
Now, what to do based on the skill instance's rank, that's something we can talk about how we'll implement. So we can talk about that before any of us do something in regards to that.
This part is on me, so don't worry too much about it. I have to hook up the skill instances to the battle scene and all that jazz. I think I can safely remove the available_skills variable on Combatant since we're approaching our "real" implementation. The enemies can get their skills through their EnemyData object.


linux: provide a pre-made kernel signing key

Motivation for this change
Without this, the kernel would generate a random one for us which obviously
isn't reproducible.
nix-build -A linux --check succeeds now!
(Tested at different times with different kernel)
Note: This does not improve or worsen kernel security since we don't enforce
signatures.
Command used to generate key file:
nix run nixpkgs.openssl -c openssl req -new -nodes -utf8 -sha256 -days 36500
-batch -x509 -config x509.genkey -outform PEM -out r13yKey.pem -keyout
r13yKey.pem
x509.genkey:
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
prompt = no

[ req_distinguished_name ]
O = NixOS
CN = Public reproducibility key, DO NOT TRUST

Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

Not sure why GH thinks @raboof's commit I based off of isn't in staging already but it's the same one that was merged yesterday.
/marvin opt-in
/status needs_reviewer

Oi, gimme that label back @ofBorg.
Looks like the commit was rebased, not merged; rebased.

I'm not sure I'm in favor of this. I get the reproducibility aspect, but now if someone turns on signature enforcement in their config (e.g. with linuxManualConfig) I'd say it's a reasonable assumption that this would lead to a kernel for which you cannot build modules later and load them. As in, you can only load modules from that kernel build.
As is, this assumption would not be true anymore, in fact anyone could build modules and load them.
Maybe this could be conditional on the relevant signature enforcement options? IIRC the kernel build already uses the module system to do that kind of config matching magic in other places.

If your security relies on the kernel build generating a ephemeral key during build, you should enforce its ephermerality rather than assuming it IMO. Perhaps even build your config around CONFIG_MODULE=n.
Also, if you do something custom like that, you're on your own. I can't make sure people's manual configs don't break as an upstream contributor. I can only be expected to make sure Nixpkgs doesn't break.
Might be worth including in the release notes though.
Almost nothing in pkgs uses the module system, linuxManualConfig is passed an attrset of arguments, i.e. features. Most of the kernel config only depends on version and platform with only very few options decided by features' attrs. I could add something there but I think that's meant for big upstream features like Xen or grsecurity.

Note: This does not improve or worsen kernel security since we don't enforce signatures

I don't think this is strictly speaking true, in theory: we enable SECURITY_LOCKDOWN_LSM by default, and users could be doing "echo 'confidentiality' > /sys/kernel/security/lockdown". Without this PR, this would protect against loading malicious kernel modules. With this PR, it would no longer protect against it, since the attacker could use the private key from the repo to sign their malicious modules.
That said, I think it is also somewhat unlikely people are actually using SECURITY_LOCKDOWN_LSM. Specifically, I think people are unlikely to use SECURITY_LOCKDOWN_LSM on 'regular' NixOS machines: since this feature is intended to protect you even when the attacker has gained root, I think this is a feature you would use on machines where you don't build new kernels on the machine itself, but you'd generate images with something like nixos-generators. In that context you'd probably want to edit your kernel config to only ship the modules you want to be available, and indeed possibly CONFIG_MODULE=n them.
Given this, I think it would be better to disable MODULE_SIG and SECURITY_LOCKDOWN_LSM by default, instead of including a "publicly-known private key" in the repo. I suspect there will be few users actually using the SECURITY_LOCKDOWN_LSM features, and for those who do want it, we can document how to lock down things even better when using Nix. Including a "publicly-known private key" would be surprising for those users, and because of that a dangerous default.

Marvin pinged me, but I don't think this is really ready for review and/or merging, since the discussion around the PR and its consequences is not done yet.
I like the fact that the key explicitly says to not trust it, but should we even introduce potential security pitfalls (as described in earlier comments to this PR) as a sacrifice for reproducibility?
@Atemu does this configuration even boot with signature enforcement? Can an out-of-tree built-by-Nix module (e.g. openrazer drivers) be loaded? Will these modules be signed too? I think this PR needs lots of documentation before it's ready to merge, and before that, I can't say that I would merge this if I had rights to merge. I'll set "awaiting changes" so Marvin wouldn't bother us until the discussion is complete.
/status awaiting_changes

By default, there is no security issue here. The kernels built by hydra would be just as insecure as before.
The only potential security issue here exists for people who manually customise and build their own kernels with signature enforcement and rely on the ephermerality of the generated key.
As I said though, it is questionable whether we as upstream should have to worry about breaking such custom configs.
Out of tree module loading should not have changed. I didn't check but logic dictates that, previously, you should not have been able to load OOT modules with signature enforcement because the key required by the kernel was generated during its build process and deleted by the nix-daemon afterwards.
It would theoretically be possible now actually because the key is known and could be passed to the OOT modules' derivations but since enabling signature enforcement wouldn't provide a security benefit anymore, I don't count that.
I'll check if disabling module signatures completely is possible as that is indeed a cleaner solution, builds are running...

It works!
I had to disable SECURITY_LOCKDOWN_LSM though, did that do anything on our kernels?

Yes it did lock a few things down but, without enforced signatures, you could get access to those anyways because you could insert an arbitrary module so I don't think we'd lose anything.
https://github.com/NixOS/nixpkgs/pull/107625

I think this is supposed to be closed now, according to the new PR mentioned above, therefore closing.

I think it would've gotten closed when staging made it into master.


Define permissions for actions

The cosign action doesn't provide the default permissions that are required. This increases the attack vector. https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
It is recommended to define permissions.
https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions

thanks for the issue
@naveensrinivasan are you willing to open a PR to fix those issues?

Sorry, I don't have bandwidth now.

Thank you!


refactor!: reorganize repo towards more ergonomic API

Fixes #40 WIP
Motivation
Pursuant to #40, this is my idea of reorganizing the repo to make it more ergonomic. Marking this as a draft since it is an unsolicited major, breaking change. Hopefully this can serve as a source of discussion.
Features:

All features accessible from the root package and a single configuration struct
Names have been made more consistent, to aid in grouping and autocomplete
Newer V3 API endpoints (currently just functions) are supported by default. I also laid the foundations for incrementing them individually if necessary.
Auth providers are easier to create

functional-option style helper functions for the builtin auth types allow the user to easily create them without needing to call into docs or use the plugin names.
Errors will occur when creating the client
Transports are transparently layered and requests are cloned.
custom auth providers can also be created, provided they match the function signature.

Custom transport as a base is supported, using *http.Transport for a configurable base and only using http.Roundtripper internally.
Auth and rest internals are not exposed.
Pursuant to #39, errors are improved

errors should be testable using errors.As using the APIErr and ServerErr interface types.
The new IsNotFound(error) function can identify errors that are simply the result of something not existing

Things that need to be visible should appear in Godoc more clearly, such as the auth plugin names, definitions for the AuthParams. AuthParams that have a KV fallback are also noted in the Godoc.
Though there are more files in the root, the organization using the api_ and client_ prefixes help navigation, and the types can be grouped under endpoint if less files are desired.

What's next?
Since I really needed this for work, I will probably continue to work on it in the coming weeks by adding integration testing using the a current Pulsar Image and testcontainers-go The first priority is making sure all of the auth methods work correctly so a mock server like mock-oauth2-server with testcontainers will probably also play a role. Then I would probably start to exercise the various APIs using various authentication methods for better coverage. At some point, I'd also like to experiment with unifying the various function signatures, such as the way topics/list requires the special NamespaceName type, but many other methods take (tenant, namespace). Would love to discuss those things. Also keen to make a special type for topic lists that will present as a unified list, but allow you to break it into partitioned/non-partitioned, etc...
Modifications
See above
Verification
All current tests have been updated.

Close this in favor of tracking in https://github.com/apache/pulsar-client-go


LICENSE.md

Repo needs an open source license declaration!

I can add the license if you tell me which one.

Opinions, BAVC team? @kellyhaydon @bturkus

+1 for MIT.
On Wed, Feb 1, 2017 at 6:55 PM, Ashley<EMAIL_ADDRESS>wrote:

Opinions, BAVC team? @kellyhaydon https://github.com/kellyhaydon
@bturkus https://github.com/bturkus
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bavc/signalserver/issues/117#issuecomment-276854117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIkiXtBA8l9Xk7o5XzPbvnyEqUuJ7HfIks5rYUWogaJpZM4LdfuG
.

--
*Ben Turkus **| *Preservation Project Manager
*415.558.2158 |<EMAIL_ADDRESS><EMAIL_ADDRESS>*


Redux

Very much a WIP still. Took a bit longer than expected to get some stuff working. However, here is my progress so far from the weekend. Hoping can get everything into Redux by the end of next weekend.
There are already some noticeable improvements. Discover page and show page now reuse the same claim data and load pretty much instantly.

Awesome progress.
Whenever you think this is can go live without BC breaks, I'm fine to put it in even if we're not 100% doing things the Redux way. App development is hot and broad right now, so the more we can keep branches in check the fewer head aches down the road.

Will have this in a state where it can be merged by tomorrow morning @kauffj. Need to get published files and rewards working. Merging with master isn't going to be easy though :/

@6ea86b96 we'll own the merge. Can't wait!

Ok, so I think this is good now @kauffj
Bugs:

published files are showing up in downloaded files
reward for purchasing won't get claimed if the user refreshes the client before the download finished
Data doesn't get refreshed right now after initial fetch. Need to dispatch actions to fetch latest data in some places. Then perhaps when data is first being fetched when can display a loading message and on subsequent fetches we display the data along with a spinner saying it's updating.
Data not refreshing means content priced in dollars is going to get out of date
some reward callbacks might be missing
the URI we build to store fileinfo is different to the uri returned from featured content (which has a claim sequence number), so we start to see duplicates as we view files.
probably lots of other things :)

Todo:

refactor redux state to store files by sd_hash. Now I understand the data model better I think storing everything by URI is not right.
get rid of the content actions/reducer/selector
I think we can completely remove all the lbry file info subscribe events and rely on components being updated by changes to the global state.
refactor rewards out of components and into actions.
lots of loading/fetching state improvements. For example we know that the claim and or cost info is being fetched when loading featured content file tiles so we could display some nice loading message instead of "this file is pending confirmation".

Other things I came across:

lbry.sendToAddress seems to return true even when an address is invalid
would be nice if lbry.sendToAddress returned a transaction
lbry.removeFile(null) removes all every single downloaded file ever. Bug or feature? :)
Removing a paid file (including from fs) means you need to purchase it again to watch it

@6ea86b96 merged but I think I made at least a few mistakes. Coming back to this a bit later today or tomorrow depending on how things go.

Woah, that was insanely fast. Expected this to take much longer :) I will get a coffee now and take a look.


German translations.

I've done all german translations. Please integrate the translations into the nightly build. Thanks.
DLC.zip
#254

Can do, thanks for contributing!

Some minor tweaks, built on newest nightly.
cqui-AddedGermanInserts.zip

In CQUI_Text_General.xml line 27
  <!-- POPUPS -->     <Row Tag="LOC_CQUI_GREAT_PERSON_PROGRESS" Language="en_US">       <Text>Progress:</Text>     </Row>
has the command "Row" to be replaced with "Replace" for the translations, or keep "Row"?

Hmm! I hadn't even noticed that in the LOCs. I'm guessing it must work since nobody's reported any issues with it yet, but nonetheless I'd like that file to be consistent with the rest. Feel free to use whichever convention you prefer for now, I'll be doing a corrective styling pass for this in the future closer to release

Resolved in 24dad270f84770fe6a211475361a0ff3ea046c24


Horizontal Scroll

Just wondering, Is it hard to implement horizontal & paged scroll?

Horizontal is not hard, I think. But if you need paged scroll why don't you use a FlatList/ScrollView?

Yeah, I use flatlist.
Here is the case. I have 30 pages built with FlatList (Horizontal Paged), Each page have your library  which is the awesome recyclerview-list 😉 .
The pain part is navigating between pages. it's really slow and ruin the experience, i don't  know if it's the FlatList or recyclerview-list issue ☹  . checkout the video here

It seems a deep rendering issue. When you press the "Go to Juz" button probably you update the prop of a component that renders again the horizontal flatlist and then all the recyclerviews. Since there are 30 recyclerviews, the process is quite slow. You should not re-render all the components, but just call the scrollToIndex method of the FlatList. Do you do that?

Yes, the onPress props only contain the scrollToIndex method for changing the page, there is no updating props.

Mmm... you should investigate more on what's going on.

If you replace recyclerview-list with a colored View does the issue appear?
Try putting a console.log for each recyclerview-list when it renders. Are the recyclerview-list rendered many times?
Try putting a console.log for each item of the recyclerview-list when it renders. Are the items rendered many times?

Another idea... maybe the modal that contains the "Go to Juz" button when it closes it triggers a new render of the whole page

There is no action to trigger a new render. From my experience, it comes from the flatlist, if we navigate to the item that not in the view boundary it kinda have a delay from rendering.
Just like the vertical scroll, unlike your library, flatlist will show blank page if we navigate far down the list and sometimes it stop before the target  😁.

Ok understood.
Try tweaking the props initialNumToRender and windowSize of the FlatList, and initialListSize and windowSize of the RecyclerviewList. For example, I see from the video that your items are quite big, a value of 3 for initialListSize should be ok, and 6 or 9 for windowSize (of the RecyclerviewList).

Already did that, there still slight delay. 👍
I tried adding maxToRenderPerBatch = {2} to FlatList and
windowSize   = {5}
initialListSize = {4}

A bit faster now. But i am still hoping for horizontal,paging props on your libs to see the performance difference :)


Default implementation of PyNativeType::py is unsound.

Using PyNativeType::py it is possible to obtain a Python instance inside an entirely unlocked interpreter, which could make python programs that rely on GIL for soundness, unsound.
The reproducer below relies on the fact that you can pass an value of PyAny into a Python::allow_threads closure and then obtain another instance of Python from previously captured PyAny.
🌍 Environment

Your operating system and version: not applicable
Your python version: not applicable
How did you install python (e.g. apt or pyenv)? Did you use a virtualenv?: not applicable
Your rust version (rustc --version): not applicable
Are you using the latest pyo3 version? Have you tried using latest master (replace version = "0.x.y" with git = "https://github.com/PyO3/pyo3")?: using 0.8.2, but there are no changes in the relevant area of code

💥 Reproducing
fn foo(py: Python, a: PyObject) {
    let any1 = a.cast_as::<pyo3::types::PyAny>(py).unwrap();
    let any2 = a.cast_as::<pyo3::types::PyAny>(py).unwrap();
    py.allow_threads(|| {
        let stray_py = pyo3::PyNativeType::py(any1);
        stray_py.allow_threads(|| {
            let stray_py = pyo3::PyNativeType::py(any2);
            stray_py.allow_threads(|| {
            });
        });
    })
}

let gil = pyo3::Python::acquire_gil();
let py = gil.python();
foo(py, py.None());

Thank you.
I made PyAny !Send in #655.
Can you reproduce this by the latest master?

Yeah #655 seems to fix this.

FWIW I think this deserves a rustsec issue and also perhaps we should cut a new release sooner rather than later.


Encrypted CBZ archives

Closes #840
Hi,
I implemented an option to encrypt downloaded CBZ archives using zip4j.
Encryption
Files inside CBZ archives will be encrypted with AES 256
The user password will be encrypted with AES 256 CBC  and padded with PKCS7. The decryption key is stored inside the Android Keystore and the encrypted password is stored inside the Shared Preferences
Padding
Image files will have a random amount of characters added to their exif metadata and ComicInfo files will have them added to a new TachiyomiSY specific padding field. This is done to make identifying archives by the size of their individual files impossible.
Changes to local source manga
I changed the way local source manga behave when generating metadata files. If the option to password protect downloads is turned on, ComicInfo.xml files will be created inside password protected ComicInfo.cbm archives. I also added an option to either turn off the creation off cover.jpg files or to cache them internally.
Other
I decided to leave the original java zip file implementation in for now and only use zip4j for metadata and  password protected archives this can be changed if after sometime no user notices any bugs.
Internally stored local cover images will not be deleted automatically. They will instead be deleted when the user changes their preferred cover location or manually deletes them in security settings.
Most of the changes to ImageUtil are only necessary because zip4j does not support the mark() and reset() functions. I opened an issue and if buffered streams are ever supported those changes could be reverted.
The padding for webp files is untested because I could not find any test manga for it. It should, according to the ExifInterface documentation, work though
UI changes:
When opening Security settings:

Password Dialog:

After setting a password:

After turning on Password protected downloads:

I included it in the latest build with a few changes.

I moved encrypted database setting to advanced options and added a warning dialog when turning it on.
I had to rewrite how archives were decrypted due to main tachi using a new way to handle zip archives, they are now extracted to a tmp dir. If it has issues feel free to PR a fix.


Setting an empty scene

Describe the bug
View->setScene doesn't warn or error when an empty pointer is given.
To Reproduce
Steps to reproduce the behavior:
view->setScene(scene);
Works as expected
view->setScene(nullptr);
Stops all rendering from happening, a warning would be helpful when trying to debug issues with the rendering setup.
Expected behavior
Either some of the rendering should still happen (e.g. the background) or a warning should pop up explaining an empty scene is being rendered
Desktop (please complete the following information):

OS: iOS
GPU: Apple A14 GPU
Backend: [OpenGL/Vulkan]

Smartphone (please complete the following information):

Device: iPhone 12 Pro

Additional context
Add any other context about the problem here.

nullptr is a valid value to pass, as documented:
\p scene can be nullptr to dissociate the currently set Scene
     from this View.\n

There should be no warning when nullptr is passed as it is the correct way to "unset" the scene on a View.


obsidian banners plugin integration

Is your feature request related to a problem? Please describe.
Works with the syntax of the obsidian banners plugin to increase activity.
Describe the solution you'd like
AS-IS
banners: ![[image.png]]

TO-BE
image: assets/img/image.png

#210


Updated auto install instructions to match new create-astro wizard

These instructions walk through the new create-astro wizard.
Looking for feedback!
(I am undecided as to whether I like the steps of the wizard showing up in the right sidebar because of the header level. It wasn't my intention, but now that I see them there, I think I like them?)

Thanks for your comments @delucis ! Do you have a suggestion re: the editor comment from above? I have never used a local editor, so my terminal is always just a window within my editor in all my cloud options.
Which application do people normally launch first? (I'm inferring that your terminal and your code editor are two different applications, then?) I'd be on board with adding an "Open your editor" step where ever that's appropriate. Then, when you do open an editor locally, do/can you specify a project root at that time? (I can't image you're viewing your entire filesystem when you use a local editor...) Sorry for all this! Forgot how spoiled I am by Gitpod in some ways!

Do you have a suggestion re: the editor comment from above? I have never used a local editor, so my terminal is always just a window within my editor in all my cloud options.

Good question. I don’t actually know what “people” do. I usually use VS Code, which has a built-in terminal, so very much like your experience I imagine. Except I usually open a repo/project directory with VS Code, so you get a similar experience to an online editor: sidebar with files etc. But when running the wizard I don’t have the repo/directory yet, so tend to do that in the basic terminal window and then run code . to open the current directory in VS Code.
Maybe we can just add this as a TODO in the guide for now?

OK, @bholmesdev is up! Ignore all the conversation above, Ben. We tried to work out all the kinks before looping you in.
Happy to receive any feedback (mostly just re: Step 1 auto install via create-astro)! Did we faithfully reproduce what you were going for with the wizard??

Thanks for looking over it @aFuzzyBear ! As I mentioned, I think the keyboard thing came up before... maybe that's yet another Issue for the pile in general?

Putting this one out of its misery! Will react to any complaints in prod. At least the instructions are updated now.


feat: avro and attr bridge for event bus

Avro to Attr Bridge code:
This code handles converting betwen avro and attr. It can handle handle custom types such as datetime or CourseKey if the right extension classes are passed into the bridge.
Its still unclear how this will interact with kafka schema registry.
To see how this is used, see file "lms/djangoapps/arch_experiments/event_bus/course_events.py" in lms/djangoapps/arch_experiments/event_bus/course_events.py

JIRA: https://openedx.atlassian.net/browse/ARCHBOM-1944
** Testing Instructions **
make requirements
pip install attrs fastavro
pytest
Merge checklist:

[ ] All reviewers approved
[ ] CI build is green
[ ] Version bumped
[ ] Changelog record added
[ ] Documentation updated (not only docstrings)
[ ] Commits are squashed

Post merge:

[ ] Create a tag
[ ] Check new version is pushed to PyPI after tag-triggered build is
finished.
[ ] Delete working branch (if not needed anymore)

Managed to test this using the POC PR on devstack and verified that we are able to serialize and deserialize CourseKeys.

The cloudevents additions to schema produced by avro_attrs_bridge is based on cloudevents avro spec and OEP-41


The catch method of Promise seems unreasonable

The original Promise method will union the result of resolve with the result of catch
async function main() {
    const value = await Promise.resolve("1").catch(() => undefined);
    //     ^? const value: string | undefiend
}

But now the catch signature must return the same type as resolve.
interface Promise<T> {
  // ...
  catch(
    onrejected?: ((reason: unknown) => T | PromiseLike<T>) | null | undefined
  ): Promise<T>;
}

In my opinion await task().catch(() => defaultValue) is a good development experience
Similar to rust's unwrap_or
const value = await task().catch(() => defaultValue)

In addition, I think onrejected as optional will also bring some ambiguity.
The .catch() of the following code is actually useless
const value = awiat task().catch()

Therefore, I suggest modifying it as follows
interface Promise<T> {
  // ...
  catch<R>(
    onrejected: ((reason: unknown) => R | PromiseLike<R>)
  ): Promise<T | R>;
}

The original Promise method will union the result of resolve with the result of catch
async function main() {
    const value = await Promise.resolve("1").catch(() => undefined);
    //     ^? const value: string | undefiend
}

But now the catch signature must return the same type as resolve.
interface Promise<T> {
  // ...
  catch(
    onrejected?: ((reason: unknown) => T | PromiseLike<T>) | null | undefined
  ): Promise<T>;
}

Yes, this was intentional. It matches the type signature of the catch function in Haskell.
catch :: Exception e => IO a -> (e -> IO a) -> IO a

In my opinion await task().catch(() => defaultValue) is a good development experience

You can still do that. You just need to be explicit about the type of the awaited value.
@@ -1,4 +1,4 @@
 async function main() {
-  const value = await Promise.resolve('1').catch(() => undefined);
+  const value = await Promise.resolve<string | undefined>('1').catch(() => undefined);
   //     ^? const value: string | undefiend
 }

Similar to rust's unwrap_or
const value = await task().catch(() => defaultValue)

The unwrap_or method in Rust also requires that the type of the default value matches the type of the value contained within the Option. It does not use a different type for default, and return the union of the two types.
impl<T> Option<T> {
  pub fn unwrap_or(self, default: T) -> T {…}
}

In addition, I think onrejected as optional will also bring some ambiguity.
The .catch() of the following code is actually useless
const value = awiat task().catch()

Agreed. You should always provide a callback function to .catch. However, I made it optional because omitting the callback function, or providing null or undefined instead of the callback function, is valid. This is because internally .catch(f) calls .then(undefined, f). Besides, this error can be caught by eslint by enabling the promise/valid-params rule.
That being said, I wouldn't mind making the callback function of .catch mandatory.

Therefore, I suggest modifying it as follows
interface Promise<T> {
  // ...
  catch<R>(
    onrejected: ((reason: unknown) => R | PromiseLike<R>)
  ): Promise<T | R>;
}

In my humble opinion, using a different type for the result of .catch is bad because it's too lax. It allows you to return absolutely anything from the .catch handler. Thus, it will implicitly change the type of the awaited value to something that you might not expect. And, as The Zen of Python states, "Explicit is better than implicit." Hence, I think it's better that the result of .catch has the same type as the awaited value. It forces developers to explicitly provide the type of the awaited value.

@uinz Please consider closing this issue if my response solved your problem or was helpful in finding a solution to your problem.


Apache doesn't always start after reboot

Not sure of the cause but after a reload I will sometimes need to give apache a kick with "sudo service apache2 start"

I almost always provision post-reload, which will ensure services are running.

@jeffgeorge @Xenza  I'm also observing this issue each time I start precip (vagrant up) from a halted state (i.e., without a reload). Apparently, Apache starts before the Vagrant-provided default /vagrant synced folder is mounted (and according to /etc/mtab, it's mounted late), and fails to start because a configtest tries to validate the the first configured SSL certificate, which is not yet available at /vagrant/ssl/....
Console output from sudo service apache2 status:
* apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           `-apache2-systemd.conf
   Active: failed (Result: exit-code) since Sun 2017-08-20 03:48:53 EDT; 48s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1009 ExecStart=/etc/init.d/apache2 start (code=exited, status=1/FAILURE)

Aug 20 03:48:53 precip apache2[1009]: AH00112: Warning: DocumentRoot [/vagrant/util] does not exist
Aug 20 03:48:53 precip apache2[1009]: AH00112: Warning: DocumentRoot [/srv/www/d2iet/docroot] does not exist
Aug 20 03:48:53 precip apache2[1009]: AH00526: Syntax error on line 29 of /etc/apache2/sites-enabled/25-iet.vm-ssl.conf:
Aug 20 03:48:53 precip apache2[1009]: SSLCertificateFile: file '/vagrant/ssl/clwdev.vm.crt.pem' does not exist or is empty
Aug 20 03:48:53 precip apache2[1009]: Action 'configtest' failed.
Aug 20 03:48:53 precip apache2[1009]: The Apache error log may have more information.
Aug 20 03:48:53 precip systemd[1]: apache2.service: Control process exited, code=exited status=1
Aug 20 03:48:53 precip systemd[1]: Failed to start LSB: Apache2 web server.
Aug 20 03:48:53 precip systemd[1]: apache2.service: Unit entered failed state.
Aug 20 03:48:53 precip systemd[1]: apache2.service: Failed with result 'exit-code'.

Tail of /etc/mtab (current mounts):
<IP_ADDRESS>:/Users/cstuck/repos/precip/sites /nfs-www nfs rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=<IP_ADDRESS>,mountvers=3,mountport=674,mountproto=udp,local_lock=none,addr=<IP_ADDRESS> 0 0
vagrant /vagrant vboxsf rw,nodev,relatime 0 0
var_log_apache2 /var/log/apache2 vboxsf rw,nodev,relatime 0 0
etc_puppet_modules /etc/puppet/modules vboxsf rw,nodev,relatime 0 0
tmp_vagrant-puppet_environments /tmp/vagrant-puppet/environments vboxsf rw,nodev,relatime 0 0
bindfs /srv/www fuse.bindfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other 0 0

Can we avoid the config-test, configure the apache2 rc.d service to run later than the 'vboxadd-service.service systemdservice, or change the default/vagrant` synced folder to an NFS mount (which may or may not fix the issue, but, separately, will ensure access to that directory is more performant)?

Current VirtualBox and Vagrant versions on host environment:
cstuckmbp:precip cstuck$ VBoxManage --version
5.1.26r117224
cstuckmbp:precip cstuck$ vagrant version
Installed Version: 1.9.7
Latest Version: 1.9.7

You're running an up-to-date version of Vagrant!

This is likely an issue of this script no longer working in 16.04. We install it to /etc/init and it probably isn't firing anymore.

@Xenza Can you do a git pull on master and vagrant reload to confirm this fix resolves the issue for you as well?


Unable to initialize main class com.mygdx.game.desktop.DesktopLauncher

Issue details
I'm trying to use libgdx on Linux with Eclipse 2019-12 but it doesn't work. I used the setup tool to make a desktop-only application and imported it into Eclipse by importing a Gradle project. When trying to run the DesktopLauncher main class I get the following error:
Error: Unable to initialize main class com.mygdx.game.desktop.DesktopLauncher Caused by: java.lang.NoClassDefFoundError: com/badlogic/gdx/ApplicationListener
I would expect since this is a new project that I didn't mess with that it would at least run properly. I just want to see something work in my dev environment so I can experiment with it. I'm using Java: openjdk 11.0.6 2020-01-14
Version of LibGDX and/or relevant dependencies
Whatever is the version the tool downloaded for me... some of the dependencies say 1.9.10.
Please provide the version(s) affected.

[X ] Linux

Further to the previous post, it seems like the Gradle build is broken due to missing files. Is there a maven solution to this? It would be a whole lot easier.
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':desktop:compileJava'.

Could not resolve all files for configuration ':desktop:compileClasspath'.
Could not find gdx-platform-natives-desktop.jar (com.badlogicgames.gdx:gdx-platform:1.9.10).
Searched in the following locations:
file:/home/andrew/.m2/repository/com/badlogicgames/gdx/gdx-platform/1.9.10/gdx-platform-1.9.10-natives-desktop.jar
Could not find gdx-box2d-platform-natives-desktop.jar (com.badlogicgames.gdx:gdx-box2d-platform:1.9.10).
Searched in the following locations:
file:/home/andrew/.m2/repository/com/badlogicgames/gdx/gdx-box2d-platform/1.9.10/gdx-box2d-platform-1.9.10-natives-desktop.jar
Could not find gdx-controllers-platform-natives-desktop.jar (com.badlogicgames.gdx:gdx-controllers-platform:1.9.10).
Searched in the following locations:
file:/home/andrew/.m2/repository/com/badlogicgames/gdx/gdx-controllers-platform/1.9.10/gdx-controllers-platform-1.9.10-natives-desktop.jar
Could not find gdx-freetype-platform-natives-desktop.jar (com.badlogicgames.gdx:gdx-freetype-platform:1.9.10).
Searched in the following locations:
file:/home/andrew/.m2/repository/com/badlogicgames/gdx/gdx-freetype-platform/1.9.10/gdx-freetype-platform-1.9.10-natives-desktop.jar

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 0s
3 actionable tasks: 1 executed, 2 up-to-date

it sounds like an issue with your setup, maybe not related to libgdx. Better ask for help in Discord or Stackoverflow.

I'm not sure how missing files from the gdx setup tool could be a problem with my setup... all the other requires files appear to be there, but it seems to have failed to download everything. Thanks anyway.

yeah, sometimes there are some conflicts between local .m2 (maven) and gradle cache. Removing .m2 may fix it.