Keycloak Invalid RealmID

Describe the problem
We had some trouble setting up Netbird with Keycloak. After some testing we've found out that a RealmID with a space in it will result in Netbird not being able to "warm up cache" and not running as expected at all.
We did not use the RealmID "netbird" as suggested in the docs because our users are stored in the company default Realm "Company GmbH". This will result in an escaped url which looked like this for the admin endpoint:
https://id.customerdomain.tld/admin/realms/company%20gmbh
As I said using this RealmID, we couldn't get Netbird running. Connecting to the UI worked, but it showed a 401 token invalid error message. After renaming the RealmID from "Company GmbH" to "companygmbh", without changing any credentials only the urls, it worked.
To Reproduce
Steps to reproduce the behavior:
Follow the advanced Guide to setup a selfhosted instance with Keycloak.
Expected behavior
Netbird should work with all kinds of RealmIDs
NetBird version
0.25.5

Hi @JonnyBDev, we just made a short validation with Keycloak 23. It doesn't allow us to have any special characters in the realm name. See screenshot.
 Some things that may help:

Keycloack version
Was the realm created on some older version
What do you see if you go to the realm setting and check the URL shown in the browser, eg: http://localhost:8080/admin/master/console/#/test1/realm-settings. Where test1 is the realm name/id.


feat: ORV2-1679 - Update payment methods for refund and payment on frontend

Description
Please provide a summary of the change and the issue fixed. Please include relevant context. List dependency changes.

Update payment method and card type usage for payment and refund related logic and pages

Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Check that all payment and refund related functionalities (for amend/void/revoke) work as expected.

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have already been accepted and merged

Further comments

Thanks for the PR!
Deployments, as required, will be available below:

Frontend
Backend

Please create PRs in draft mode.  Mark as ready to enable:

Analysis Workflow

After merge, new images are promoted to:

Merge Workflow

with regards to working with money in JavaScript, I've found this lib really helps keeping the precision when working with money and currencies - https://mikemcl.github.io/decimal.js/


Support async methods in the IMaterializer

This is the main reason I am not using JSONAPI.NET's ApiController implementation yet. I have a service layer that has async CRUD methods that I want to await in async WebAPI actions, but the synchronous IMaterializer interface that ApiController<> uses gets in the way.
I propose converting the interface to the following:
Task<T> GetById<T>(params Object[] keyValues);
Task<object> GetById(Type type, params Object[] keyValues);
Task<T> Materialize<T>(T ephemeral);
Task<object> Materialize(Type type, object ephemeral);
Task<T> MaterializeUpdate<T>(T ephemeral);
Task<object> MaterializeUpdate(Type type, object ephemeral);

I think this is better than supporting both sync and async versions of each method, since you can easily wrap a synchronous method result in a Task.FromResult(), if you really need to.

Not opposed to the API change...we might want to provide a subclass shim (marked [Obsolete]) that does that Task.FromResult() and presents the old method signatures as a drop-in (I might do that myself to make things quicker for me anyway).
Besides the API change, will adjusting EntityFrameworkMaterializer to actually do work asynchronously be complicated, do you think?

Re: the shim: I said that wrong, what I meant is a shim that would wait on the async versions and return the result synchronously. That would provide the old signatures.

Updating the EF materializer should be easy, there are Async versions of all the necessary methods.
I'm not sure about the utility of maintaining the old signatures in the interface. The only user is ApiController<>, and it would switch to using the async ones. Up to you, though.

I'm thinking selfishly about some of my code that uses EntityFrameworkMaterializer methods in my ApiController...writing a shim will let me worry about that later instead of touching multiple ApiControllers :-)

lol, alright. Let's try to remove them before 1.0 though.

Ohhh...yeah that's a problem with my shim idea I hadn't thought of, the only thing that would change in the method signature would be the return type, which you can't overload or subclass differently...therefore you changed all the async method names, right.
I'm of two minds about this: usually Async methods end with "Async", so that's sort of a convention...on the other hand, ending the method name with Async sort of implies that there's a non-Async version, which we don't want long-term.
Unsure which way to go here, but I'm okay with dropping my shim/legacy method signatures idea given that it had consequences on the long-term method naming. What do you think?

Should have researched this a little before replying...according to folks who seem to know, it seems that it's desirable to suffix methods that return a task with "Async" anyway. So I think the naming in your PR should probably stand, and we'll leave in the legacy versions for now.


Unable to resolve keymirror

my iOS simulator on the Mac thros the following error:
Unable to resolve module 'keymirror' from ....../MyProject/node_modules/react-native-video/TextTrackType.js (also same for VideoResizeMode.js). Module doesnt exist in the module map or .../MyProject/node_modules directory.
I prefer to use Yarn and have updated that to the most recent version to try and resolve the problem but its not budging.

I encountered this today and restarting the yarn server fixed it. Were you able to get this resolved?


Charges - define ruleset for updating and stop charges

Description:
With this story, we will define a ruleset for how to persist charges in our sql database. The ruleset will also define how existing charge data will be updated in the database according to the incoming charge.
Assumptions:

A charge message received in ebIX will be mapped to ChargeCommand(s) in a cim context before this ruleset will be triggered. Side note; this context does not use OperationType as we currently know it with 'create', 'update' and 'delete'. In the CIM context it is just a period, open-ended or not. It does not tell if it is e.g. an update or not.
Hence, ebIX handling is out of scope.

Preconditions:

#205 must be done.
#204  must be done.

Acceptance criteria

AC#1 Ruleset for updating and stopping a charge has been documented. Please see BRS-guide on Charge Links for inspiration
AC#2 Ruleset has been approved by PO and SME (Irene)
- Update #206 to reflect the ruleset
AC#3 Close #141 and replace it with another story that implements "storing based on the ruleset"

The ruleset for persisting charges in our sql database can be found below.
PO has received this and we're pending his feedback.

Hey @prtandrup everything looks good according to the issues ACs. But both preconditions are still open? #205 is in the "Done" column, but #204 is still in development it looks like.
The drawing is such a good representation of a complex process. Good job!

Hey @prtandrup everything looks good according to the issues ACs. But both preconditions are still open? #205 is in the "Done" column, but #204 is still in development it looks like.
The drawing is such a good representation of a complex process. Good job!

Hey @lasrinnil, thx and nicely spotted. The original take was "test cases first, then define the rule set". Getting to a defined rule set went a bit different though (a bunch of scenarios being discussed which ended up with this result). Thus, I believe the #204 precondition mentioned here is incorrect and I decided to strike it out.


Fully objectify access to collections items

This will give us the ability to drop array access on collections, and
// Write this
collect($vimeo)->body->data->first()->metadata->connections->likes->total;

// Instead of
collect($vimeo)['body']['data'][0]['metadata']['connections']['likes']['total'];

Or
//  This
collect($vimeo)->body->data->reduce(function($carry, $item) use ($width) {
    return $carry + $item->files->where('width', $width)->sum('size');
});

// Instead of
collect(collect($vimeo)['body']['data'])->reduce(function($carry, $item) use ($width) {
    return $carry + collect($item['files'])->where('width', $width)->sum('size');
});

[X] SupportCollectionTest.php are passing?
[ ] Fix database related tests
[ ] Write more tests

I really never want to go down the road of accessing single objects using collections.


fixing the horizontal_skips_map construction, it was not going through

There two fixed here. One for horizontal_skips_map construction as default, another for uno_scaling.

Thanks @btolooshams !


[Bug]  the result of 'admin show frontend config'   is not correct

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
2.0.4-rc2
What's Wrong?

I set sys_log_delete_age=3d  and audit_log_delete_age=7d in fe.conf and restart fe
after restart fe,the  values  are not modified

but I if get the value from web(may be get by curl), the values are correct

What You Expected?
values updated
How to Reproduce?
just as the above procedure
Anything Else?
no
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

the latest version has fix it


PS-Investigation<EMAIL_ADDRESS>

i filed a claim for a partial on the larceny in SMALL CLAIMS - it is not reported either.

CRCMessages
Your message
To: CRCMessages
Subject: FW: *** LOCATED THE VIDEOGRAPHER FOR THE ZUCKERS… IN THE FEDERAL RECORD.
Sent: Sunday, February 6, 2022 5:15:51 AM (UTC+00:00) Monrovia, Reykjavik
was read on Monday, February 7, 2022 9:42:10 PM (UTC+00:00) Monrovia, Reykjavik.
To: CRCMessages
Subject: RE: ref.:   *** 101 west 55th street, new york, NY, 10019 **
Sent: Tuesday, February 15, 2022 10:05:39 AM (UTC+00:00) Monrovia, Reykjavik
was read on Tuesday, February 15, 2022 4:35:53 PM (UTC+00:00) Monrovia, Reykjavik.

Your message
To: PS Investigation
Subject: see also : camera NOT POINTED AT A WINDOW docket 49 + SHANKING THE PORTER you missed.
Sent: Sunday, February 6, 2022 8:06:50 PM (UTC+00:00) Monrovia, Reykjavik
was read on Monday, February 7, 2022 4:47:05 PM (UTC+00:00) Monrovia, Reykjavik.

To<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Cc<EMAIL_ADDRESS>MANHATTAN SKYLINE, LLC.
Subject:	FW: Read: *** THANK YOU FOR KINDLY ALERTING YOUR MANAGERS: ACCEPT THIS AS A REASONABLE REQUEST.
Sent:	2/10/2022 12:23 PM
was read on 2/10/2022 12:30 PM.
0900293850 - FW: ## BBO  >> THE KIDS PRIVACY , PRIORITY. SORRY.
Client Support
<EMAIL_ADDRESS>Region 	Telephone 	Prompts
Americas 	+1<PHONE_NUMBER> 	Option 1: BondEdge / ICE Data Analytics
EMEA 	+44<PHONE_NUMBER> 	Option 2: Pricing & Analytics
APAC - Australia 	+61 3 9071 4592 	Option 3: Consolidated Feed & Tick History
APAC - Hong Kong 	+852 3018 8279 	Option 4: Desktops
APAC - Singapore 	+65 6817 6211 	Option 5: ICE Data Derivatives
APAC - Tokyo 	+81 3 4520 8110 	Option 6: Indices & IOPV

nov 16 - 2021.pdf


libc: newlib: Enable extensions

This commit enables the following newlib extensions to allow the use
of various de facto standard functions:

POSIX.1-2008 (_POSIX_C_SOURCE=200809)
SUSv4; POSIX.1-2008 plus XSI (_XOPEN_SOURCE=700)

Signed-off-by: Stephanos Ioannidis<EMAIL_ADDRESS>

One major problem with globally enabling the newlib POSIX extensions is that the newlib pthread definitions are included and these conflict with the Zephyr pthread definitions when posix portability support is enabled.
At the time of writing, the newlib does not allow selectively disabling only the pthread component when _POSIX_C_SOURCE is set (while there exists _POSIX_THREADS definition, this is derived from _POSIX_C_SOURCE and cannot be overridden) and the only workaround possible is to individually add #define _GNU_SOURCE (or similar) before including the newlib headers in the files that require the POSIX extension.
A potential solution to this problem would be to create a Zephyr newlib fork and implement full Zephyr support in it (including thread safety locks, pthread, ...).

Closing for now, as this is not feasible with the current newlib integration approach.
For now, adding #define _GNU_SOURCE to the source files that require these extensions should suffice.

FYI @jfischer-phytec-iot


Rubyzip failure to allocate memory issue on Windows Server 2008

On Windows Server 2008 & 2008R2 the following exception occurs:
================================================================================
  Error executing action `install` on resource 'chef_gem[rubyzip]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of C:/opscode/chef/embedded/bin/gem install rubyzip -q --no-rdoc --no-ri -v "1.1.7" ----
STDOUT:
  STDERR: [FATAL] failed to allocate memory
---- End output of C:/opscode/chef/embedded/bin/gem install rubyzip -q --no-rdoc --no-ri -v "1.1.7" ----
Ran C:/opscode/chef/embedded/bin/gem install rubyzip -q --no-rdoc --no-ri -v "1.1.7" returned 1

This does NOT happen on Windows Server 2012 & 2012 R2.

http://blog.huangzhimin.com/2012/10/02/avoid-using-rubyzip/

I think I will try powershell:
http://stackoverflow.com/a/26843122/4548096

A better solution expand.exe: https://support.microsoft.com/en-us/kb/80751

@dhoer: FYI, this error is not related to rubyzip itself: https://support.microsoft.com/en-us/help/2786401/cannot-allocate-memory-error-when-you-run-a-shell-script-in-windows-7


Expected object at root, got string Error If YAML Encoding UTF-16

While generating some YAML files to setup Backstage for a POC at work I ran into this error - "Expected object at root, got string" - once I went to add them as static configuration. In the end the issue was somehow my PowerShell Out-File encoding was UTF-16 using UTF-8 solve the issue and the files imported fine. I'm not sure how other encoding formats get handled so that might be worth taking a look at
Expected Behavior
Files import without issue in a perfect world, otherwise a warning that the file does not use a supported file encoding
Current Behavior
If you use a file that is UTF-16 you'll get this error message: "Expected object at root, got string"
Possible Solution
I didn't dig into the code to see how I might implement this check or logging so I'm not sure how I would handle this.
Having something for this would be really helpful as this error could send you down a rabbit hole trying to figure out if you have something wrong with your file syntax. Encoding can be easily overlooked, at least I know I take it for granted
Steps to Reproduce

Create a YAML files that has a correct Component, User, or Group spec but the file encoding is UTF-16
Add the file as static configuration in the app-config.yaml
Start up the backend with yarn start in the packages\backend folder

Notice in the output there will be an error with the message: "Expected object at root, got string"
Your Environment
I'm running this against an Azure DevOps Server 2020 instance in a Windows environment

Thanks for reporting!


Decouple the MatcherPolicy from MVC and make it solely based on routing.

The implementation could be made more generic by using endpoint metadata directly instead of the ActionDescriptor to stash the API information. Instead of doing SetProperty the data could be stored here.
I haven't looked deeply to see what other tentacles reach into MVC.

Interesting that you mention that. A few people have asked how that might be achieved.
Switching from storing things in an ActionDescriptor to EndpointMetadata, or more specifically Endpoint.Metadata, is feasible - with the right amount of refactoring. API Versioning was around before Endpoint Routing (and helped flush out some of the design with Ryan and James). The two main reasons the information is still in a property are:

Historical
Continues to work for those still using legacy routing (they're still out there)

#2 can be addressed by the fact that you can't use both routing systems simultaneously. A strategy can be used to control where the information is accessed to avoid a bunch of branching conditions. Today, this would normally be detected through MvcOptions.EnableEndpointRouting. If MVC were removed, then it would probably be assumed true and only possibly switch when integrated with MVC.
I've also be considering breaking things further apart; something like Abstractions. This work and feature would likely align to those changes. Any thoughts or suggestions are most certainly welcome.
TL;DR
The fundamental challenge to removing MVC completely is how the metamodel is currently discovered. Version discovery and collation are largely done through the ApplicationModels namespace. In the strictest sense, API Versioning doesn't really care about that and isn't bound to it. A fairly early design point was API version information is purely metadata. It is provided by way of IApiVersionProvider. This is most commonly achieved by way of attributes, but there is a conventions fluent API as well. The Application Model afforded by MVC provides a nice way to inspect and apply API version metadata by interrogating the developer's code.
API version collation is one of the more difficult challenges. Despite what some people may think, it's achieved using the controller's name. Again - it's doesn't have to, but it was a natural choice. It might seem more logical to group by route template, but this can go sideways pretty quickly. For example, api/v{ver:apiVersion}/{id} and api/v{version:apiVersion}/{id:int} are semantically equivalent (and obvious to developers reading it), but is quite difficult - as well as likely slow - to match up. There are other scenarios where the route template just doesn't give you enough information. For example, what if value/{id} and value/{id}/subvalue/list should, or shouldn't, be grouped together? It's a bit more nuanced than that, but hopefully that paints a picture.
Armed with that information, what I conceptually think could work if those other issues are addressed would be something like:
app.UseEndpoints(endpoints =>
{
	// version-neutral api
	endpoints.MapGet("/ping", c => Task.CompletedTask)
	         .IsApiVersionNeutral();

	// 1.0 endpoint
	endpoints.MapGet("/hello", c => c.Response.WriteAsync("Hello world v1!"))
	         .HasApiVersion(1, 0);

	// 2.0 endpoints (grouped for convience)
	endpoints.WithApiVersion(2, 0, api =>
	{
	      api.MapGet("/hello", c => c.Response.WriteAsync("Hello world v2!"));
	});
});

I suspect this approach breaks or inhibits API Explorer features for those that care about it - usually for OpenAPI documents. I believe that's already an issue and an understood decision point for choosing this type of setup.

We're interested in this so we'll investigate what it would take to make it work in the .NET 7 timeframe.

@davidfowl,
I just wanted to let you know that this work has been completed (but I'm not closing the issue just yet). Due to changes in the project that have just been announced, we're still a little bit out from publishing the corresponding packages. If you're interested in taking a peek, you can see the implementation here. Things are now split apart from core HTTP and MVC Core, where API Versioning is possible without any part or direct references to the MVC Core assembly. This also sets up the foundation for Minimal API support.

As it relates to Minimal API, everything will tie together like this:
builder.Services.AddApiVersioning();

var app = builder.Build();

app.DefineApi()
   .HasApiVersion( 1.0 )
   .HasApiVersion( 2.0 )
   .ReportApiVersions()
   .HasMapping( api =>
    {
        // GET /weatherforecast?api-version=1.0
        api.MapGet( "/weatherforecast", () =>
            {
                return Enumerable.Range( 1, 5 ).Select( index =>
                    new WeatherForecast
                    (
                        DateTime.Now.AddDays( index ),
                        Random.Shared.Next( -20, 55 ),
                        summaries[Random.Shared.Next( summaries.Length )]
                    ) );
            } )
           .MapToApiVersion( 1.0 );

        // GET /weatherforecast?api-version=2.0
        api.MapGet( "/weatherforecast", () =>
            {
                return Enumerable.Range( 0, summaries.Length ).Select( index =>
                    new WeatherForecast
                    (
                        DateTime.Now.AddDays( index ),
                        Random.Shared.Next( -20, 55 ),
                        summaries[Random.Shared.Next( summaries.Length )]
                    ) );
            } )
           .MapToApiVersion( 2.0 );

        // POST /weatherforecast?api-version=2.0
        api.MapPost( "/weatherforecast", ( WeatherForecast forecast ) => { } )
           .MapToApiVersion( 2.0 );

        // DELETE /weatherforecast
        api.MapDelete( "/weatherforecast", () => { } )
           .IsApiVersionNeutral();
    } );

@commonsensesoftware We're doing route grouping in .NET 7 https://github.com/dotnet/aspnetcore/issues/36007.
cc @halter73 @captainsafia

@davidfowl,
Preview 2 is now available. The 🐀 🧶 has been eliminated. To the greatest extent possible, everything now only considers endpoints and their metadata.
New Packages:

Asp.Versioning.Http - Minimal APIs
Asp.Versioning.Mvc - MVC Core
Asp.Versioning.Mvc.ApiExplorer - API Explorer extensions

Examples:

Minimal API
Minimal OpenAPI

The discussion on route grouping is progressing well, but some help may be needed in dotnet/aspnetcore#39604. Customers don't want to wait until .NET 7 for me to release an iteration. Ideally, I'd like to release within the next month. Since things are in preview now with a lot of breaking changes from previous versions, I'm ok with a few more. I don't want to repeat that in the .NET 7 release. Anything that we can to align direction (e.g. design + signatures)  should be good for all. As can be seen here, I've had to resort to some pretty 🤮 hackery to retain parity with the out-of-the-box Minimal API support for the API Explorer.
@halter73 and I have had some discussion, but nothing is settled - yet.

Hey @commonsensesoftware, super happy to see this landing but I'm very concerned with the amount of code copied and the layering of the approach you landed on here. I think there are 2 things being coupled here that I'd like to see split up:

The metadata for defining an API version policy, and the matcher policy
The builder API that defines that policy for a single endpoint or group of endpoints.

What you have right now in Asp.Versioning.Http looks like its both things. This coupled with the fact that to get the desired API you've had to replicate all of the extensions (and the associated bugs) bothers me quite a bit.
I wonder if we could have an API version policy object that could be added to multiple endpoints manually.
var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddApiVersioning();

var app = builder.Build();

var apiPolicy = new ApiVersionPolicyBuilder()
            .HasApiVersion(1.0)
            .HasApiVersion(2.0)
            .ReportApiVersions()
            .Build();

// GET /weatherforecast?api-version=1.0
api.MapGet("/weatherforecast", () =>
{
        return Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateTime.Now.AddDays(index),
                Random.Shared.Next(-20, 55),
                summaries[Random.Shared.Next(summaries.Length)]
            ) );
})
.WithApiVersionPolicy(apiPolicy)
.MapToApiVersion(1.0);

// GET /weatherforecast?api-version=2.0
app.MapGet("/weatherforecast", () =>
{
    return Enumerable.Range(0, summaries.Length ).Select(index =>
        new WeatherForecast
        (
            DateTime.Now.AddDays( index ),
            Random.Shared.Next( -20, 55 ),
            summaries[Random.Shared.Next(summaries.Length)]
        ) );
})
.WithApiVersionPolicy(apiPolicy)
.MapToApiVersion( 2.0 );

// POST /weatherforecast?api-version=2.0
app.MapPost("/weatherforecast", (WeatherForecast forecast ) => { })
    .WithApiVersionPolicy(apiPolicy)
    .MapToApiVersion(2.0);

// DELETE /weatherforecast
app.MapDelete("/weatherforecast", () => { } )
    .WithApiVersionPolicy(apiPolicy)
    .IsApiVersionNeutral();

I'd prefer to have you focus on the pure API versioning data model and let us worry about how to apply policies to multiple endpoints (via route grouping).

@davidfowl ,
First, thanks for taking to the time to provide feedback.
Philosophically, we are aligned. The goal of API Versioning has always been to provide ways to bolt on the metadata and let you define routes as you always have. In the most naive sense, the mental model is meant to be that API versions serve as nothing more than a way to disambiguate otherwise ambiguous endpoints. When going through the initial design review with Ryan and James, this was, and still is, achieved with a custom IEndpointSelectorPolicy.
Certain 404 responses as well as 405 and 415 have always been a challenge for API Versioning, but #744 really highlights the issue. I thought it might have been a mistake in the routing system itself. After some discussion with Javier, it became clear that a custom INodeBuilderPolicy is also necessary so that versioned endpoints are eliminated before other policies and the correct response is returned. This steams from the fact that, while you know that a candidate is invalid, you don't know why. The addition of a INodeBuilderPolicy addresses each of these problems and has an added benefit of eliminating candidates faster. This workflow illustrates the endpoint candidate selection process.
Building a versioning policy by hand is possible, but puts the onus on the developer and is primed for errors. Collation and construction of a policy per endpoint has always been one of the key features of API Versioning.
It's important to understand a declared API version versus a mapped API version. Declaring an API version is what is exposed on the surface area and reported. Mapping an API version only disambiguates a specific endpoint API version. Think of mapping as analogous to method overriding or interface mapping; e.g. for given endpoint E and method M, map it to API version A.
Let's reconsider a sample setup with more annotations:
app.DefineApi()          // ← MapGroup (?); hope to align signatures in 6.0 so 7.0 uses final design
   .HasApiVersion( 1.0 ) // ← all endpoints in this group declare 1.0
   .HasApiVersion( 2.0 ) // ← all endpoints in this group declare 2.0
   .ReportApiVersions()  // ← all endpoints in this group reports their versions
   .HasMapping( api =>
    {
        // GET /weatherforecast?api-version=1.0
        api.MapGet( "/weatherforecast", () => new WeatherForecast[]{ new() } )
           .MapToApiVersion( 1.0 );   // ← explicitly maps to 1.0

        // GET /weatherforecast?api-version=2.0
        api.MapGet( "/weatherforecast", () => new WeatherForecast[]{ new() } )
           .MapToApiVersion( 2.0 );    // ← explicitly maps to 2.0

        // GET /weatherforecast/{id}?api-version=1.0|2.0    ← implicitly maps to 1.0 and 2.0
        api.MapGet( "/weatherforecast/{id}", ( int id ) => new WeatherForecast() );

        // POST /weatherforecast?api-version=1.0|2.0    ← implicitly maps to 1.0 and 2.0
        api.MapPost( "/weatherforecast", ( WeatherForecast forecast ) => { } );

        // DELETE /weatherforecast[?api-version=1.0|2.0]   ← implicitly maps to 1.0, 2.0, or unspecified
        api.MapDelete( "/weatherforecast", () => { } ).IsApiVersionNeutral();
    } );

When the /weatherforecast endpoint reports its versions, all endpoints with the exception of DELETE (because it's version-neutral), will report the header:
api-supported-versions: 1.0, 2.0

In MVC, this is achieved using IActionFilter via ReportApiVersionsAttribute. For Minimal APIs, it is achieved using a decorator which is applied as a convention. The developer doesn't have to add each and every convention. They express their intent and the right thing happens. This invariably means customizations to the underlying builders so that a Minimal API can live up to its name.
While I appreciate, and even like, the simplicity of attaching a policy, there's a bit more to it. I feel it's important that the API Versioning setup be as similar to a standard Minimal API setup as possible. API Versioning has already had its own conventions API for a long time. The current design is inspired by melding those two together. I don't want the Minimal API setup to be a completely new and different approach.
Ultimately, I do not want to copy or duplicate a bunch of intrinsic code that supports Minimal APIs. For the 6.0 release, I doubt there is any way around that. It's not too late for the 7.0 release though. I'm calling out the pain points and limitations I'm facing as early has possible so that there is a path to an agreeable solution. I'm highly interested and invested in following the Grouping work so we are aligned. I'd also like to see the limitations in the existing design remedied. Several things are internal, use internal members, or are sealed for no particularly good reason. I need some help driving that.

Sidebar: I faced similar challenges in the legacy IActionSelector design. While some of the bits were opened up in later releases, quite a bit of internal stuff had to be duplicated because there was no other way to use or consume it.

The problem is that it will exist forever and it does not compose with the existing APIs. Think about what would happen if other libraries did the same thing? They would all create their own grouping constructs that don't compose and it would be chaos (that's why we're doing it in .NET 7).
As a compromise, can you split the builder API into a separate opt-in package?
PS: This is your package and feel free to ignore this feedback but I feel pretty strongly about this and I would argue this isn't minimal APIs, it's your own version of it. When issues show up because people move code from the top level to the version API version builder, we'll have to treat them as external bugs.

I'm highly interested and invested in following the Grouping work so we are aligned. I'd also like to see the limitations in the existing design remedied. Several things are internal, use internal members, or are sealed for no particularly good reason. I need some help driving that.

👍🏾

@davidfowl,
Agreed. I strive to avoid forking code whenever I can. I'm not interested in owning it. I'm also aware of a few scenarios with teams who shall not be named that have not followed that recommendation and it bit them down the road. I'll just say that I'd rather not be a target of the meme:
"When David Fowler gives you sound advice and you don't follow it."
I'd like a mulligan. I've gone back to the whiteboard using the skeleton of what you proposed. Here's what I've come up with:
// shortcut for: app.Services.GetRequiredService<IApiVersionSetBuilderFactory>().Create(default(string));
var versionSet = app.NewApiVersionSet()
                    .HasApiVersion( 1.0 )
                    .HasApiVersion( 2.0 )
                    .ReportApiVersions()
                    .Build();

// GET /weatherforecast?api-version=1.0
app.MapGet( "/weatherforecast", () => default(WeatherForecast))
   .UseApiVersioning( versionSet )
   .MapToApiVersion( 1.0 );

// GET /weatherforecast?api-version=2.0
app.MapGet( "/weatherforecast", () => default(WeatherForecast))
   .UseApiVersioning( versionSet )
   .MapToApiVersion( 2.0 );

Names are important. Policy sounds great, but it's a misnomer in this context. The object is not fully constructed at this point. A policy would be more indicative of the final thing constructed. This might be possible completely out-of-band, but it would be verbose and look ugly methinks. There also doesn't seem to be a way to reference the endpoints out-of-band to make the correlations. The API versioning information can be collated across more than one endpoint.
A version set seemed to more accurately represent that, but I'm not entirely married to that name. The established WithXXX extension methods add metadata to the endpoint. At this point in the composition, the metadata is not added. Only when the Endpoint is finally constructed is ApiVersionMetadata applied from all builder operations.
I hacked and slashed all the preview code. No code is forked, copied, or duplicated now. However, the existing ASP.NET Core 6.0 design has some limitations IMO.

The builder pipeline is difficult or impossible to extend because you can only apply a convention
The IEndpointConventionBuilder has no access to services

The first issue is annoying, but it can be worked around. The second issue is more painful. Since there is neither a way to access the information that has been collected in the builder chain (say a monad of builder metadata) and there is no access to services, I was forced to bridge the two with an interface that unions the necessary behaviors. I don't see a way around this without sacrificing or changing long established features and behaviors.
public interface IVersionedEndpointConventionBuilder :
    IEndpointConventionBuilder,
    IMapToApiVersionConventionBuilder
{
    bool ReportApiVersions { get; set; }
    ApiVersionMetadata Build();
}

This allows the result of UseApiVersioning to retain the intrinsic built-in functionality, while adding API Versioning specific behaviors. This also removes builder ordering issues. UseApiVersioning will be required for even the most simple setup because there is no other way to get or request information such as the configured ApiVersioningOptions. This can't and doesn't need to change for 6.0, but at least adding IEndpointConventionBuilder.Services in 7.0 should be considered.
Even though I don't need to as a one-person show, I try to be in the habit of creating PRs so the community can see what I'm doing and potentially comment on it. As such, PR #816 is up with all the current changes I'm considering for Preview 3. A big part of the PR is this refactoring. If you'd like to comment directly on it, feel free to do so. All the changes for this topic are in a single commit. If that is TL;DR and you just want to see the changes, you can look at the source branch here. The example projects have been updated as well. Any additional thoughts or ideas are certainly welcome.

The IEndpointConventionBuilder has no access to services

https://github.com/dotnet/aspnetcore/pull/41238 adds access to the ServiceProvider to the EndpointBuilder class which means that you can access it when adding conventions to your builder. I'm not sure if that is enough of an access point for your particular implementation but it should be available to play around with in .NET 7.

@captainsafia this is great news! Having access to services, even just on the EndpointBuilder, will be an improvement. Armed with this knowledge, I will the necessary adjustments for the 6.0 release knowing this change will come in 7.0. Thanks for sharing.

@davidfowl, 6.0 is finally signed and published with all the of aforementioned goodness. I'll start the process of looking into adding the officially supported grouping constructs for .NET 7.0 and see how things line up.
I'll also look at the changes provided by @captainsafia for ways to streamline policy configuration and make it more natural.
Thanks for all the discussion and feedback. The project landed in a better place for it.

 Thanks a lot!


[stable/redis-ha] mkdir: can't create directory '/data/conf/': Permission denied

Describe the bug
Installing of redis-ha halts, claiming that it has no permissions to create a directory.
Version of Helm and Kubernetes:
Kubernetes-Version: v1.13.5
Helm-Version: v2.10+unreleased
Which chart:
stable/redis-ha
What happened:
Installation is stuck
Messages:
in Rancher:
Container with incomplete status [config-init]
CrashLoopBackOff: Back-off 5m0s restarting failed container=config-init pod=redis-ha-server-0_redis-ha(4d606898-8146-11e9-8dad-e4b97a6bc1b3)

config-init container:
Could not connect to Redis at redis-ha:26379: Try again
mkdir: can't create directory '/data/conf/': Permission denied

What you expected to happen:
Finish the installation until the pod is running
How to reproduce it (as minimally and precisely as possible):

Create a cluster
Add a PV with min. 10Gb storage
Install with "helm install stable/redis-ha"

Anything else we need to know:
I'm using rancher v2.2.3 in a single-node installation on an ubuntu 18.04LTS
Edit:
I temporarily fixed it by adding answers for values.yml during helm installation with the following values
securityContext:
  runAsUser: 0
  fsGroup: 0
  runAsNonRoot: false
hostPath:
  ## path is evaluated as template so placeholders are replaced
  # path: "/data/{{ .Release.Name }}"

  # if chown is true, an init-container with root permissions is launched to
  # change the owner of the hostPath folder to the user defined in the
  # security context
  chown: false

May you should check Pod‘s nodeName and check if this node has path of your pv & pvc


container fails to start with "[8] System error: Unit docker-.scope already exists."

Found in https://github.com/weaveworks/weave/issues/1188
Not sure if it happens at all without the proxy. It's intermittent, so possibly a race condition.
Reproducible with:
#! /bin/bash

. ./config.sh

start_suite "Stress test container restarts"

weave_on $HOST1 launch --log-level debug

# 2 containers on each host, all with the same names
proxy docker_on $HOST1 run -dti --name=foo $SMALL_IMAGE /bin/sh
proxy docker_on $HOST1 run -dti --name=bar $SMALL_IMAGE /bin/sh

# now stop and start the containers a bunch of times
for i in $(seq 50); do
  proxy docker_on $HOST1 restart foo 1>/dev/null
  proxy docker_on $HOST1 inspect --format="{{.State.Running}}" foo | grep true 1>/dev/null
  proxy docker_on $HOST1 restart bar 1>/dev/null
  proxy docker_on $HOST1 inspect --format="{{.State.Running}}" bar | grep true 1>/dev/null
done

end_suite

This goes away with docker 1.8, so probably be worth leaving.

This goes away with docker 1.8

says who?

says who?

Is your assertion based on the fact that a) https://github.com/docker/libcontainer/pull/617/files has been merged, and b) a version containing that merge has been vendored into docker?

I would be much happier to leave this alone if we were able to reproduce it w/o the proxy.

yes, and c) with that version I'm unable to reproduce the failure.


Some question about PSNR metric

Codes:
https://github.com/open-mmlab/mmeval/blob/e2f6dbf160d41adfa185caed211f2ac50747f3ba/mmeval/metrics/psnr.py#L71-L100
Seems channel_order will not be used if channel_order is not None
way to fix:
maybe change self.channel_order -> channel_order is OK?

@BIGWangYuDong, thanks for your reporting! I will check all metrics related to low-level vision and fix this problem as soon as possible!

closed by #89


feat(3VM): disallow characteristics based on a contract type

Summary
Adds KindValidator trait to primitives.
Relates to t3rn/3vm#52
Checklist

TODO: Validate if the contract type has a storage

Please check that your PR completes the requirements as follows

[ ] Tests have been added for bug fixes/features
[ ] Acceptance criteria from the issue has been completed

Closing since this is super outdated, opening a new pr instead


PointLight2D shadow buffer error

Tested versions
Reproducible from v4.4.dev.mono.custom_build [190ae9f9d]
System information
Godot v4.4.dev.mono (190ae9f9d) - Ubuntu 24.04.1 LTS 24.04 on Wayland - X11 display driver, Multi-window, 3 monitors - Vulkan (Forward+) - integrated AMD Radeon Graphics (RADV RENOIR) - AMD Ryzen 7 5800H with Radeon Graphics (16 threads)
Issue description
Using a PointLight2D with shadow enabled leads to:
ERROR: Can't allocate memory for buffer of size: 0, error -3.
ERROR: servers/rendering/rendering_device.cpp:749 - Condition "!buffer.driver_id" is true. Returning: RID()
ERROR: Storage buffer supplied (binding: 0) must provide one ID (0 provided).
ERROR: Buffer argument is not a valid buffer of any type.
ERROR: servers/rendering/rendering_device.cpp:4436 - Parameter "uniform_set" is null.

in the editor output and
E 0:00:00:0439   buffer_create: Can't allocate memory for buffer of size: 0, error -3.
  <C++ Error>    Condition "err" is true. Returning: BufferID()
  <C++ Source>   drivers/vulkan/rendering_device_driver_vulkan.cpp:1530 @ buffer_create()

E 0:00:00:0439   storage_buffer_create: Condition "!buffer.driver_id" is true. Returning: RID()
  <C++ Source>   servers/rendering/rendering_device.cpp:749 @ storage_buffer_create()

E 0:00:00:0439   uniform_set_create: Storage buffer supplied (binding: 0) must provide one ID (0 provided).
  <C++ Error>    Condition "uniform.get_id_count() != 1" is true. Returning: RID()
  <C++ Source>   servers/rendering/rendering_device.cpp:3640 @ uniform_set_create()

E 0:00:00:0439   buffer_update: Buffer argument is not a valid buffer of any type.
  <C++ Error>    Parameter "buffer" is null.
  <C++ Source>   servers/rendering/rendering_device.cpp:487 @ buffer_update()

E 0:00:00:0439   draw_list_bind_uniform_set: Parameter "uniform_set" is null.
  <C++ Source>   servers/rendering/rendering_device.cpp:4436 @ draw_list_bind_uniform_set()

in the debugger.
The culprit seems to be #100302.
Does not happen with Compatibility render mode. Only tested on Ubuntu 24.04.
Steps to reproduce
Create a point light, add a light texture, and enable shadow. The errors will start to appear immediately in the output.
Minimal reproduction project (MRP)
mrp.zip

Cannot confirm on Windows 11 so seems to be Linux specific

Cannot confirm on Windows 11 so seems to be Linux specific

I just tested it myself on Windows 11 and I get the error. So it might be GPU related?

Seems like maybe this happens when shadows are enabled but there are no occluders? I'll investigate

Seems like maybe this happens when shadows are enabled but there are no occluders? I'll investigate

Can confirm. When an occluder intersects the light (independent of the mask) the error disappears.

Here is a PR with the fix https://github.com/godotengine/godot/pull/100612 Please test it and confirm that it fixes the issue for you (I tested with my own project and your MRP and the errors are gone for me)

Thanks, that was quick. The PR fixes it for me.


"false" or other string values in a Date dimension seem to cause a crash

As reported by Alex Brey, who provided a file to recreate the issue: https://twitter.com/alexbrey/status/763826306471649281

Should be fixed on the main site


Firefox weird extensions installed

Why is there some weird extensions installed on my firefox is the dotfiles spyware?

Indeed, it looks strange.
In fact, these are extensions that allow you to expand the functionality of Firefox.
DarkReader - an extension to have a dark theme on all sites.
UnpayWall - an extension to unblock content on some sites that ask for a subscription to read the article further.
TVP - page translator
TamperMonkey - an extension for implementing a real-time YouTube video translator (from Yandex)
All extensions have a good rating on the Firefox extension marketplace.
I understand your concern, so I will most likely make it so that when assembling the distribution, you can choose whether to install customization for Firefox or not.
Sorry for the inconvenience. I wanted to make everything as convenient as possible for the user.


⚠ Bofrost.de has degraded performance

In 3977ff5, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 887 ms

Resolved: Bofrost.de performance has improved in 0501297 after 9 minutes.


error message during setup for disabled reporting

export REPORTING_DISABLED=1
./zebrunner.sh setup
Zebrunner General Settings
Protocol [http]: https
Fully qualified domain name (ip) [localhost]: hostname
Port [80]: 443
Zebrunner URL: https://hostname:443
Continue? y/n [y]:
./zebrunner.sh: line 510: reporting/minio-storage/.disabled: No such file or directory

closing as can't repro

Not repro.
Closed.


scipy.io.mmwrite raises type error for uint16

mmwrite doesn't seem to support unsigned integers. Is there a reason for that?
I could use int32 instead, but using an uint16 would use less memory and prevent accidentally adding negative values.
Reproducing code example:
from scipy.sparse import coo_matrix
import scipy.io
import numpy as np
#  0 , 0,  0
# 88, 99, 11
#  0, 22, 33
matrix = coo_matrix(( [88,99,11,22,33], ( [1,1,1,2,2], [0,1,2,1,2] ) ), dtype=np.uint16 )
scipy.io.mmwrite( 'matrix', matrix )

Error message:
Traceback (most recent call last):
  File "process_data.py", line 161, in <module>
    scipy.io.mmwrite( 'matrix', matrix )
  File "/usr/lib64/python3.5/site-packages/scipy/io/mmio.py", line 102, in mmwrite
    MMFile().write(target, a, comment, field, precision, symmetry)
  File "/usr/lib64/python3.5/site-packages/scipy/io/mmio.py", line 448, in write
    self._write(stream, a, comment, field, precision,symmetry)
  File "/usr/lib64/python3.5/site-packages/scipy/io/mmio.py", line 683, in _write
    raise TypeError('unexpected dtype kind ' + kind)
TypeError: unexpected dtype kind u

Link to scipy/io/mmio.py", line 683 - doesn't seem to have a case for unsigned integers
Scipy/Numpy/Python version information:
# scipy, numpy, python versions
1.0.0 1.13.3 sys.version_info(major=3, minor=5, micro=4, releaselevel='final', serial=0)

Can I please take this up??

@ilayn Can I get info if kshitij12345 had fixed this issue? If not, I can do it.

We don't really know if the issue is picked up or not. Let's try pinging first @kshitij12345

@Tokixix  @ilayn  I have submitted a pull request.


Improve CVE entry management in OSV

The current OSV structure combines vulnerability data from different resources (e.g., NVD, Alpine, Debian) into a single CVE entry  based on shared CVE IDs. This approach leads to overly large and difficult to maintain CVE entries. With Ubuntu also publishing its security tracker data to OSV.dev using CVE IDs, this issue will likely worsen.
We probably need a better solution for managing CVE entries. One idea is to add a source-specific prefix or suffix to the CVE ID, creating separate entries for each data source. For example, Alpine-CVE-2024-0001 and Debian-CVE-2024-0001 would be displayed as two distinct records on OSV.dev.

As someone that does not have a view of the whole osv.dev machinery, I think the main question is, why would you want to combine CVE entries?

why would you want to combine CVE entries?

The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.

From your first message, the thing that is not clear to me is, if you are not going to combine CVEs anymore, then why would you need to still add the prefixes (e.g. Debian-CVE-2024-0001) ?  Aren't those completely separate buckets?

why would you want to combine CVE entries?

The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.

From your first message, the thing that is not clear to me is, if you are not going to combine CVEs anymore, then why would you need to still add the prefixes (e.g. Debian-CVE-2024-0001) ? Aren't those completely separate buckets?

For OSV,  ID prefixes must be unique, and be associated with a home database. Debian security tracker, Alpine etc didn't have a unique ID before, so we were combining them into a single CVE record. If we don't combine them, then they would need their own prefix.

why would you want to combine CVE entries?

The initial reason was that Alpine SecDB uses CVE IDs to publish their vulnerabilities. So, we created a tool to combine their data into our existing CVEs, as long as they use the same vulnerability ID. Then, we wanted to add Debian security tracker data into our OSV to better support container scanning, so we continued to combine everything into our CVE entries to keep it consistent, as the Debian security tracker also uses CVE IDs.
However, the problem now is that we continue to combine more and more data into a single record, increasing the difficulty of our maintenance. So, we are considering some better changes to this approach.

From your first message, the thing that is not clear to me is, if you are not going to combine CVEs anymore, then why would you need to still add the prefixes (e.g. Debian-CVE-2024-0001) ? Aren't those completely separate buckets?

For OSV, ID prefixes must be unique, and be associated with a home database. Debian security tracker, Alpine etc didn't have a unique ID before, so we were combining them into a single CVE record. If we don't combine them, then they would need their own prefix.

Thanks for clarifying it, and would the prefix also be necessary for the filename itself? or could we have a filename CVE-2024-0001.json and inside of it id = "UBTU-CVE-2024-0001?

Thanks for clarifying it, and would the prefix also be necessary for the filename itself? or could we have a filename CVE-2024-0001.json and inside of it id = "UBTU-CVE-2024-0001?

We do prefer the filename to match the ID name to keep it consistent for other ecosystems. Are there any concerns for Ubuntu in changing the filename?

Thanks for confirming! We prefer UBUNTU- to align with our current naming schema. Same as https://osv.dev/vulnerability/CURL-CVE-2024-7264

Hey @dodys, I have two questions about Ubuntu CVE OSV records (ubuntu-security-notices/osv).
First, I'm curious why some affected packages lack the ubuntu_priority field. This field is from the vulnerability level and should be consistent across all affected packages. But I've noticed that some packages are missing this field while others within the same vulnerability have it. Example: https://osv.dev/vulnerability/CVE-2024-21131
Second question is about the status field. I can't find it in the Ubuntu OSV records, not sure if it's an important one. But I'm wondering if there's a filtering mechanism that determines which records Ubuntu sends to OSV (like not sending all records with a status of DNE or not-affected ?).

Hey @dodys, I have two questions about Ubuntu CVE OSV records (ubuntu-security-notices/osv). First, I'm curious why some affected packages lack the ubuntu_priority field. This field is from the vulnerability level and should be consistent across all affected packages. But I've noticed that some packages are missing this field while others within the same vulnerability have it. Example: https://osv.dev/vulnerability/CVE-2024-21131

Indeed, for now we only added the ecosystem_specific part (including ubuntu_priority) when the CVE was fixed. In the next batch of update to our scripts, we plan to add the ecosystem_specific to all.

Second question is about the status field. I can't find it in the Ubuntu OSV records, not sure if it's an important one. But I'm wondering if there's a filtering mechanism that determines which records Ubuntu sends to OSV (like not sending all records with a status of DNE or not-affected ?).

Since OSV has the affected field, which is for only packages that are vulnerable to such "vulnerability" (CVE) or "set of vulnerabilities" (USN), for CVEs, we only list the ones that are affected or are still pending investigation. That means that the following status are always included:
needed -> means vulnerable/affected
needs-triage -> means that it needs investigation, therefore we consider it vulnerable until investigation is done
deferred -> means that we tried to investigate but we still don't have enough information to do so, therefore it is vulnerable until confirmed
pending -> means that the package is vulnerable and a fix is on its way
released -> means that we patched it in such release
Some status are more complex and will depend on other factors:
not-affected (<version>) -> if the <version> exists in that specific Ubuntu release, we consider it similar to released, if the <version> is an old one, e.g. the first version to contain the fix and not vulnerable anymore, then we don't add it since that Ubuntu release is not vulnerable at all.
ignored -> it will only be included for releases that are still "alive", as ignored can be used for different reasons.
And some status we just don't include:
DNE -> package doesn't exist in such Ubuntu release
active -> even though it is in the docs we still don't use that status.
Does that help clarify?

Does that help clarify?

Thanks Eduardo! It's very detailed and helpful!
Having all the ubuntu_priority info should be sufficient for us, especially considering you've already helped us filter out DNE and some not-affected ones.

I forgot to ask one thing Holly
For the USN data, should we change the related field to refer to the UBUNTU-CVE-... or should we keep it as CVE-...?

I forgot to ask one thing Holly For the USN data, should we change the related field to refer to the UBUNTU-CVE-... or should we keep it as CVE-...?

Are you referring to data from USN notes such as USN-6969-1? I think for this type of data, we can just keep its original USN- prefix, no change needed. Just for Ubuntu CVEs, we can add UBUNTU-CVE- as its prefix.

Hmm, I think @dodys is asking about what to put inside related for USN- entries? I think under our schema definitions, it would make the most sense to:

Put UBUNTU-CVE- in aliases, if it exists, given that they're both Ubuntu-specific advisories talking about the same vulnerability.
Put CVE- in related.

Thanks both!

Holly and Oliver, I've just pushed the CVE changes to our github repo, let me know if now looks as expected and the sync to osv.dev can be re-enabled

Hey @dodys, thanks for the Ubuntu CVE updates! It looks good overall. One thing to mention is the aliases/related part.
I noticed that CVEs- are added as aliases to UBUNTU-CVE-, but Oliver previously mentioned we wanted to put UBUNTU-CVE- in USN- aliases. Doing both would make OSV treat the CVE- and USN- as aliases of each other because aliases are considered symmetric and transitive. This is not exactly what we want (see https://github.com/google/osv.dev/issues/2374#issuecomment-2216588085 for explanation). We're trying to avoid making Linux distro vulnerabilities aliases of CVEs.
In the current OSV USN- data, the aliases field is still empty, so it will not cause the problem. But putting CVE- in UBUNTU-CVE- aliases is not ideal because we think CVE- and UBUNTU-CVE- are not always the same thing and shouldn't be aliases to each other. ("Aliases should not be used to refer to vulnerabilities in packages upstream or downstream in a software supply chain from the given OSV record’s affected package(s).").
I talked with Oliver, and we think there is no perfect solution at this point. But to keep things consistent with other Linux distros, we think it's best to put all vulnerabilities in related instead of aliases. We might find a better way to show the relationship between Linux distro CVEs and CVEs later on.
With all that said, we don't need to change the current USN data as it doesn't contain any aliases. The only change we probably want is to move CVE- to the related field of UBUNTU-CVE-.

The new UBUNTU-CVE prefix will also need to be added here and here in the OSV Schema.

ok, CVE files fixed and PR open: ossf/osv-schema#265

CVE files look good to me. Thanks for fixing them!

Thanks for verifying Holly!
Let me know if you need anything else from my side.
I believe for the sync to be re-enable is just a matter of addressing the ignore pattern:
https://github.com/google/osv.dev/blob/master/source.yaml#L303C20-L303C36
But I will leave it to you if you want to do some testing before re-enabling it, so we don't create another issue for you.

But I will leave it to you if you want to do some testing before re-enabling it, so we don't create another issue for you.

Hey Eduardo, we have re-enabled UBUNTU-CVE- back to OSV.dev, and the linux query timeout issue has been fixed. But I am also wondering why some CVEs don't have purl field while some have it?

But I will leave it to you if you want to do some testing before re-enabling it, so we don't create another issue for you.

Hey Eduardo, we have re-enabled UBUNTU-CVE- back to OSV.dev, and the linux query timeout issue has been fixed. But I am also wondering why some CVEs don't have purl field while some have it?

Hi Holly,
sorry, but I am confused, both examples you shared have purl. Was it a wrong paste?

Hi Holly, sorry, but I am confused, both examples you shared have purl. Was it a wrong paste?

Oh yeah, sorry. That was a wrong paste. Example without purl: https://github.com/canonical/ubuntu-security-notices/blob/main/osv/cve/2023/UBUNTU-CVE-2023-0120.json, https://github.com/canonical/ubuntu-security-notices/blob/main/osv/cve/2023/UBUNTU-CVE-2023-1296.json, https://osv.dev/vulnerability/UBUNTU-CVE-2023-46726, https://osv.dev/vulnerability/UBUNTU-CVE-2024-8354 (it seems all come from Ubuntu:Pro?)

Hi Holly, sorry, but I am confused, both examples you shared have purl. Was it a wrong paste?

Oh yeah, sorry. That was a wrong paste. Example without purl: https://github.com/canonical/ubuntu-security-notices/blob/main/osv/cve/2023/UBUNTU-CVE-2023-0120.json, https://github.com/canonical/ubuntu-security-notices/blob/main/osv/cve/2023/UBUNTU-CVE-2023-1296.json, https://osv.dev/vulnerability/UBUNTU-CVE-2023-46726, https://osv.dev/vulnerability/UBUNTU-CVE-2024-8354 (it seems all come from Ubuntu:Pro?)

We are only adding purl  for vulnerabilities that were fixed. We could change that, if that's what is preferred :)

We are only adding purl for vulnerabilities that were fixed. We could change that, if that's what is preferred :)

Yes, please. We also prefer the purl to not contain affected range information, which means it shouldn't include a version.  Our purpose in using the purl field is to find the package itself.  For example, in other ecosystems, you might see a purl like pkg:deb/debian/chromium?arch=source.
So for Ubuntu, regardless of whether a fix is available, the package purl should only contain the package information (distribution information is fine to keep).
Original one: pkg:deb/ubuntu/py7zr@0.11.3+dfsg-4ubuntu0.1?arch=src?distro=jammy
Expected one: pkg:deb/ubuntu/py7zr?arch=src?distro=jammy
@michaelkedar  do you have anything to add?

We are only adding purl for vulnerabilities that were fixed. We could change that, if that's what is preferred :)

Yes, please. We also prefer the purl to not contain affected range information, which means it shouldn't include a version. Our purpose in using the purl field is to find the package itself. For example, in other ecosystems, you might see a purl like pkg:deb/debian/chromium?arch=source.
So for Ubuntu, regardless of whether a fix is available, the package purl should only contain the package information (distribution information is fine to keep).
Original one: pkg:deb/ubuntu/py7zr@0.11.3+dfsg-4ubuntu0.1?arch=src?distro=jammy Expected one: pkg:deb/ubuntu/py7zr?arch=src or pkg:deb/ubuntu/py7zr?arch=src?distro=jammy
@michaelkedar do you have anything to add?

Thanks Holly,
I've made the changes and refreshed the data.

Thanks Holly, I've made the changes and refreshed the data.

Thanks Eduardo! It all looks good now!

If I understand correctly, in order to call this issue "done", we'd have to render combine-to-osv obsolete, which would mean:

Debian Security Tracker converted records have their own prefix (and are ideally published directly by Debian)
Alpine converted records have their own prefix (and are ideally published directly by Alpine
NVD converted CVE records are published natively (which nvd-cve-osv supports doing today)


is it completely in managed code?

Hi
I think the title explains it all, also a question of stability
Many thanks

Yes, it is completely managed code. Some of the standard library shims
(like _msvcrt) use P/Invoke calls.
IronPython3 is not likely to be very usable right now; time has not allowed
for much work on it.
On Wed, Sep 9, 2015 at 11:47 PM, emersont1<EMAIL_ADDRESS>wrote:

Hi
I think the title explains it all, also a question of stability
Many thanks
—
Reply to this email directly or view it on GitHub
https://github.com/IronLanguages/ironpython3/issues/57.

Question seems to be answered.


CEC L1 Test case changes based on L2 Interface Update

There are few changes that needs to be done on HDMI CEC L1 due to the recent change in interface file during L2.

Remove all the CECTxAsync references for both source and sink devices.
Physical address check should be done with F.F.F.F and not with <IP_ADDRESS>
There are few test cases for source device which looks to add and remove logical address.  Now as the interface files clearly says that source devices has to return NOT_SUPPORTED, these test cases needs to be changed.

@krishna-1809 , all changes concerning the latest interface file are now addressed in PR #36.  Please check if it satisfies all the above requirements.  If yes, we can close this issue.

@srinivasgtl , PR #36 has the above changes. Hence closing this issue


docs(MeshGateway): try to make multi-zone clearer

Closes #1004

Maybe someone who had problems with this could review, do you remember who was that? (like who caused us to create the issue)

@lahabana do you remember? I think it's happened multiple times to be honest. I think it's usually a MeshGatewayInstance being created in global.
I can't think of anything to do except call it out where we introduce the resources. MeshGatewayInstance in particular doesn't have its own "policy page" so this is the only place.
I thought we had validation in the webhook for tis actually but I don't see it in fact. That's something to check/add as well.


samples: more DT cleanups

More incremental progress towards:

dropping outmoded APIs like device_get_binding
avoiding (driver-specific) DT_INST API usage in samples

As prep work:
Fixes: #31280

@mbolivar-nordic These are nice clean-ups, thanks. It's a bit much squashed into one PR - new macros, lots of samples touched, lots of commits. Why not split this PR into smaller PRs to ease the review process?

@gmarull @mnkp I've addressed your comments; thanks for review.
Other changes beyond those specific comments:

get both lora samples (I accidentally only did lora/send; I meant to get lora/receive too)
add release notes for all the new GPIO macros
fix a copy/paste bug in the  threads sample (I had the wrong node when setting the gpio_pin_name for led1)

Just a rebase to see if I can get green CI.

Coding guidelines failure is spurious:
samples/subsys/nvs/src/main.c:51:WARNING: Violation to rule 5.1 or 5.2 (Identifiers shall be distinct) DT_NODE_BY_FIXED_PARTITION_LABEL length 32 > 31

A couple of changes for CI; one is a real fix, one is a workaround to keep the build succeeding for waveshare_open103z in the can sample.

CI failures seem spurious too:
/workdir/zephyr/drivers/sensor/max17262/max17262.c:343:13: error: Macro is deprecated [-Werror]
  343 | DT_INST_FOREACH_STATUS_OKAY(MAX17262_INIT)

I'm not touching this driver in this PR. It looks like a device_pm_control_nop issue.

It looks like a device_pm_control_nop issue.

Indeed it is, and was fixed in https://github.com/zephyrproject-rtos/zephyr/pull/34870


Add maccy

Types of Changes

[x] New addition to list
[ ] Fixing bug in existing item in list
[ ] Removing item from list
[ ] Changing structure (organization) of list

Proposed Changes
Maccy is simple and clean.
PR Checklist
Put an x in the boxes once you've completed each step. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING guide
[x] I have explained why this PR is important
[x] I have added necessary documentation (if appropriate)

Further Comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

@einverne thx!


HM-LC-Dim2T-SM only one channel available

I've a 2 channel dimmable switch HM-LC-Dim2T-SM . Within Home Assistant only the first channel ist visible and switchable.
Output xmlapi/devicelist.cgi:
<device name="Dimmer-Holzhütte" address="LEQ1182624" ise_id="7166" interface="BidCos-RF" device_type="HM-LC-Dim2T-SM" ready_config="true">
<channel name="Licht-Holzhütte-Innen" type="27" address="LEQ1182624:1" ise_id="7186" direction="RECEIVER" parent_device="7166" index="1" group_partner="" aes_available="false" transmission_mode="DEFAULT" visible="true" ready_config="true" operate="true"/>
<channel name="Licht-Holzhütte-Aussen" type="27" address="LEQ1182624:2" ise_id="7208" direction="RECEIVER" parent_device="7166" index="2" group_partner="" aes_available="false" transmission_mode="DEFAULT" visible="true" ready_config="true" operate="true"/>
</device>

See also: https://community.home-assistant.io/t/homematic-hm-lc-dim2t-sm-second-channel-missing/70338
Home Assistant version (if applicable):
Running Homematic version 2.29.22 @ CCU2 and Home Assistant version 0.78.3 @ RPI 3B+ (via HassOS 1.10)
Expected behavior
Second channel shout be available and dim/switchable within Home Assistant

Could you please manually apply the changes from commit 80a956dc0fb845709564cc2c464f9520a59249a7 (the or ... part in actors.py - Line 104) and see if it fixes the problem?

I guess I've to do this on a manual installation of pyhomematic? If yes, then unfortunately it has to wait until next week. Or is there any way to do this inside HassOS / Homeassistant? (I didn't find anything inside the HassOS Docker container, not even the Home Assistant stuff, but I've to say I'm completely new to Docker & Home Assistant)

There is a way so get into the Home Assistant part on HassOS, but since I don't use that I don't know exactly how that is done. But it can wait until next week.

After applying your changes, the second channel is available and switch/dimmable.
Thanks!


Added icons for password-protected channels

These icons should work for the light and the dark theme equally well.
I'm far from being an artist and thus coloring might have to be adapted in the future.
These icons are needed for https://github.com/mumble-voip/mumble/pull/3929

Admittedly these aren't the most beautiful icons ever and someone (perhaps even myself) should tweak them a bit or redesign them. My main concern is that these icons are included in order for my above mentioned PR to get mergeable.
In my opinion restyling these icons can be done, after the feature-backend is mature (and merged)


[task - rts] log events for workflow events

Changing the scope of this issue to adding the support for sending analytics events.


Multi Language?

When i click English and German Language, i have only the German one. Issue or no Multi Language Support?

@93493 are you sure? You should be able to change the audio track in e.g. VLC Player whilst the later episodes are somehow of track sometimes.

Yes i checked in VLC the Language. There is only the German

Alright. I'll have a look into it as soon as I got some free time, please be patient!

@93493 I'm sorry but this will take time. This issue is due to changes by the South Park website, meaning that this will be fixed in the new, rewritten version of this downloader that I will start working on in a bit. But the rewriting itself will take time...


Issue on UNZ segment

Hello
I've recently reinstall pydifact with PyPI.
My programm load a file, do some changes in data and serialize.
All was working with version pydifact-0.0.5. Edifact is parsed ok by my banking software.
But with the last version, when i load an existing edifact file with from_file() and then serialize, my bank software reports error during controls.
UNZ in the original file is : 'UNZ+1+XXXDVINT'
In the serialized file, the function get_footer_segment changes the value by : 'UNZ+17+XXXDVINT'
I not sure (i am not an edifact expert...) but second value should be 1 and not 17.
Maybe the function should only count UNH segment ?
Thanks

I'll have a look at this. Should not happen.

According to here(EDIFACT tutorial, PDF), page 15, you can see that functional groups are meant to be UNG/UNEenvelopes. And these are counted in UNZ, if not segments.
So i thought first this is the case.
However, all my EDIFACT files I get in real-lif (and these are many) have no UNG/UNE envelopes, and one UNB/UNZ message. So you may be right, and the documentation is a bit misleading here...?
This is definitely not correct, as +2 does not apply to UNZ, only to * UNT*, see #44.
if cnt == 0:
        cnt = len(self.segments)+2

I'll try to fix that ASAP.


Use warning emoji instead of external image

Under some conditions (e.g., when submodules are modified, like here) Highfive posts warning messages. The beginning of the warning looks like this:

The warning icons in that message are an SVG from an external location (here). At this point, GitHub supports a diverse set of emoji, including a warning icon: ⚠. This PR replaces the use of the external SVG with the emoji. This will be more future proof and it is generally nicer to use the built-in emoji, as long as you are all right with the color change. Here's how the beginning of the warning looks with the emoji:

Good call, thanks!


Remove duplicate draw logic

skip-lock builds fail because of https://github.com/wyfo/apischema/issues/316


validation: Delete the branch from the previous test run

The "Opened PR trigger" validation test is failing since the end of May,
b/c creating the new branch to test fails, as it already exists.
Update the test to delete the branch left over from the previous test
run.
Signed-off-by: Hunor Csomortáni<EMAIL_ADDRESS>

Updated this so that the script creates a different branch for each deployment. Please take another look :)


Feat : adding night time filter to big screen

This PR aims at extend the process of alert time filtering during night time to big screen and modify the logo position

All good thinks !


[R] Script installation for R

Quick installation of MXNet for R via a bash script. Also updated python script

I changed in both scripts the MXNET_HOME for consistency


move populate volume to populators

moved populate volumes to existing populating functions file also add tests.

ping @containscafeine

ping @containscafeine

All I can say is, you all need to come to a conclusion. This discussion can't go on forever.


⚠ Roblox TextFilter Api has degraded performance

In ef1d191, Roblox TextFilter Api (https://textfilter.roblox.com) experienced degraded performance:

HTTP code: 200
Response time: 930 ms

Resolved: Roblox TextFilter Api performance has improved in 800eed4.


certificate verification failed :(

Ladybird built successfully on ArchLinux using your 'Basic workflow' build steps. It runs, too, but when I go to any SSL site, I get:
ResourceLoader: Starting load of: "https://google.ca/"
Loaded 0 CA Certificates
verify_chain: No trusted root certificate found before end of certificate chain
verify_chain: Last certificate in chain was signed by /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
certificate verification failed :(
null secret
Possible failure cause(s):
- No one knows.

I don't it built on my machine but it may be because you need to specify the port in the URL. Something like https://google.ca:443

Nope. Does exactly the same thing.

Here's the whole output running it with gdb. I'm not, entirely, sure what I'm looking at, but it seems like it doesn't know about root certificates. Is there something I can do to mitigate this?
(gdb) run
Starting program: /home/mark/build/ladybird/Build/ladybird
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Set favoicon path to /home/mark/build/ladybird/Build/serenity/Base/res/icons/16x16/app-browser.png
[New Thread 0x7ffff07ff640 (LWP 409812)]
Have Error: 1
Have Error: 1
Have Error: 1
Have Error: 1
Have Error: 1
[New Thread 0x7fffed04c640 (LWP 409814)]
[New Thread 0x7fffec84b640 (LWP 409815)]
ResourceLoader: Starting load of: "https://google.ca/"
Loaded 0 CA Certificates
verify_chain: No trusted root certificate found before end of certificate chain
verify_chain: Last certificate in chain was signed by /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
certificate verification failed :(
null secret
Possible failure cause(s):
- No one knows.

Thread 1 "ladybird" received signal SIGABRT, Aborted.
0x00007ffff3a8e36c in ?? () from /usr/lib/libc.so.6

You need to copy ./Build/serenity/Base/etc/ca_certs.ini to /etc/ca_certs.ini, which seems to be the only path it looks for this file at.

Thanks. Now I can load pages.

@DelilahHoare it would be nice if you add that to the readme file 😉


Default scaffold produces stale yarn lockfile

Is this a bug report?
Yes

Did you try recovering your dependencies?
Yes, but I shouldn't have to for newly scaffolded apps

(Write your answer here.)
Which terms did you search for in User Guide?
yarn, stale, lockfile

(Write your answer here if relevant.)
Environment

(paste the output of the command here)
Steps to Reproduce
npx create-react-app foo
cd foo
yarn --frozen-lockfile

Expected Behavior
Should produce no errors.
Actual Behavior
yarn install v1.7.0
[1/4] 🔍  Resolving packages...
error Your lockfile needs to be updated, but yarn was run with `--frozen-lockfile`.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

It's a minor difference with react version:
<EMAIL_ADDRESS><EMAIL_ADDRESS>version "16.4.1"
resolved "https://registry.npmjs.org/react-dom/-/react-dom-16.4.1.tgz#7f8b0223b3a5fbe205116c56deb85de32685dad6"
dependencies:
@@ -5600,7 +5600,7<EMAIL_ADDRESS>optionalDependencies:
fsevents "^1.1.3"
<EMAIL_ADDRESS><EMAIL_ADDRESS>version "16.4.1"
resolved "https://registry.npmjs.org/react/-/react-16.4.1.tgz#de51ba5764b5dbcd1f9079037b862bd26b82fe32"
dependencies:


Added Csv-to-Json-converter

Developer Checklist

[X] Followed guidelines mentioned in the readme file.
[X] Followed directory structure. (e.g. ProjectName/{USERNAME}/...yourfiles)
[X] Starred ⭐ the Repo (Optional)

Summary
Its a javascript project which converts your csv to json structure using webworkers
Screenshot

Live Project Link
add a working project link here

That was left by mistake raised new Pr


[Feature Request] show etcd cheet when open project

With issues:

Use the search tool before opening a new issue.
Please provide source code and commit sha if you found a bug.
Review existing issues and provide feedback or react to them.

Description

How to reproduce
Steps to reproduce
Expectations
Actual result
Environment

idea version:
operating system:

cheetsheet source: https://lzone.de/cheat-sheet/etcd


Update rocketmq client maven version

当使用 4.3.0 版本依赖时，当调用同步发送消息代码时，提示：Exception in thread "main" org.apache.rocketmq.client.exception.MQClientException: No route info of this topic，修改为当前最新版本 4.9.1 后问题解决。

Coverage increased (+0.1%) to 54.206% when pulling ced5843faf2a58b7b37ae3c11339dd6ea1af84e4 on zhouwentong1993:patch-1 into fb8bc64e2a2551e76da24cb6af0fb3e5f986f8b3 on apache:master.

Codecov Report

Merging #3335 (ced5843) into master (fb8bc64) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #3335      +/-   ##
============================================
- Coverage     47.98%   47.98%   -0.01%
+ Complexity     4562     4557       -5
============================================
  Files           552      552
  Lines         36521    36521
  Branches       4818     4818
============================================
- Hits          17525    17524       -1
- Misses        16781    16782       +1
  Partials       2215     2215

Impacted Files
Coverage Δ

...a/org/apache/rocketmq/filter/util/BloomFilter.java
59.13% <0.00%> (-2.16%)
:arrow_down:

...he/rocketmq/client/trace/AsyncTraceDispatcher.java
77.72% <0.00%> (-1.49%)
:arrow_down:

...mq/client/impl/consumer/RebalanceLitePullImpl.java
48.52% <0.00%> (-1.48%)
:arrow_down:

...e/rocketmq/client/impl/consumer/RebalanceImpl.java
39.45% <0.00%> (-1.18%)
:arrow_down:

.../rocketmq/broker/filter/ConsumerFilterManager.java
73.09% <0.00%> (-0.90%)
:arrow_down:

...org/apache/rocketmq/store/ha/WaitNotifyObject.java
71.42% <0.00%> (ø)

...ketmq/client/impl/consumer/PullMessageService.java
75.55% <0.00%> (ø)

...he/rocketmq/client/impl/consumer/ProcessQueue.java
59.53% <0.00%> (+0.46%)
:arrow_up:

...lient/impl/consumer/DefaultMQPushConsumerImpl.java
40.17% <0.00%> (+0.52%)
:arrow_up:

...n/java/org/apache/rocketmq/store/ha/HAService.java
71.94% <0.00%> (+0.66%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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

hi, it is better to change this pr to develop branch.

Plz create an issue to relate this pull request


change name for level option for gif optimization

when you call optimized method, you don't know what type of image it is, and level option for png and  level option for gif should have different name

Coverage remained the same at 100.0% when pulling 902eb29336ac9eba625872a8556eee0f002de1c9 on netiko:gifsicle into 09e808c6717b4dc5df6cdd73d923f64203634e43 on jtescher:master.


Negative block height causes compiler to crash

Description
A block that ends up having a negative height causes the compiler to crash.
This is the code that can be used to reproduce the crash:
#block(height: -10cm)

Reproduction URL
No response
Operating system
Web app
Typst version

[X] I am using the latest version of Typst

Duplicate of
https://github.com/typst/typst/issues/5262


Fix #1018. Improve the "Next" and "Previous" buttons

Fix #1018

Currently the arrow on the button appears using the rotateY transformation. Perhaps this is precisely why a strange vertical line appeared on the screenshot in the issue description. I've used the opacity property instead. It has fewer pitfalls.

Noticed that the edge of the word on the button blinks on hover. This is because the pseudo-element with an arrow first covers a part of the word, and then moves to the side. To fix this, I placed the pseudo element outside of the button. There it is invisible thanks to the overflow property of the button. Now on hover the button becomes wider and the arrow drives inward.

Removed a large piece of code regarding the background, color and shape of the pseudo-elements. The background and shape may simply be absent, and only the color of the arrow is important. But it is enough to use the inherit value to get the actual color of the button.

There is no need for special code for the rounded button too.

Added two constants for the indentation of these buttons.

Updated the code for the Previous button in the same way.

What needs to be improved? What have I not taken into account?

Great work as always thanks!


Create private epinio CA

fix #603
Merge should wait for #590 to be merged, and then rebased.

Made wip again ... The app cert signer is still self-signed, not the private CA I expected ... Investigating ...

Ok. Definitely broken, and getting the switch to it as default actually done exposed it.
The issuer itself is apparently not getting ready
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  creationTimestamp: "2021-07-14T09:50:25Z"
  generation: 1
  name: epinio-ca
  resourceVersion: "15037"
  uid: 4e916a47-3acc-4849-bb60-866b20f955a2
spec:
  ca:
    secretName: epinio-ca-root
status:
  conditions:
  - lastTransitionTime: "2021-07-14T09:51:16Z"
    message: 'Error getting keypair for CA issuer: certificate is not a CA'
    reason: ErrInvalidKeyPair
    status: "False"
    type: Ready

References

https://github.com/jetstack/cert-manager/issues/2497
https://cert-manager.io/docs/configuration/#supported-issuer-types
https://docs.cert-manager.io/en/release-0.8/tasks/issuers/setup-ca.html

... Ah :facepalm: and :scream: ... I seem to have forgotten the line isCA: true for the root cert when I pulled things from https://cert-manager.io/docs/configuration/selfsigned/#bootstrapping-ca-issuers

And with that fix it works.


CT_PPr.get_or_add_rPr()

But a "w:rPr" is existed under node "w:pPr", it is automatically created when the paragraph is autonumbering, with the node "w:numPr" at same time. how can I access it to modify the font attribute?
  Okay, so what you want is `CT_PPr.get_or_add_rPr()` which _could_ be there (`w:pPr` can have a `w:rPr` child) but unfortunately is not. So you would need to add it if you want it. The procedure would be something like:

from docx.oxml import OxmlElement
rPr = OxmlElement("w:rPr")
pPr.append(rPr)

Originally posted by @scanny in https://github.com/python-openxml/python-docx/issues/1288#issuecomment-1795856369

@ghmole Please do not open a new issue to continue an existing conversation. If you have something more to ask or say just do it in the existing conversation.

Sorry, I have comment in an old conversation, but no reply.
By the way, How to solve this issue?

This question is answered in #1288


[5.5] Fix eachSpread mapSpread with nested collections

I recently PR'ed the ability to use the keys in eachSpread and mapSpread, but it caused a regression when using nested collections (see https://github.com/laravel/framework/commit/2f2886e0d5a162c0b09b0c6755ce1850e8ebaf27#commitcomment-24046152)
This PR fixes that regression and adds some more tests.

Thank you Sebastian :+1:


ss3t_csd_beta1: [ERROR] Need b=0 data and a single non b=0 shell

I tried to use the reconstruction option "mrtrix_singleshell_ss3t" of qsiprep and encountered the following error:
ss3t_csd_beta1: 3 unique b-value(s) detected: 5,999,1998 with 8,50,53 volumes
ss3t_csd_beta1: [ERROR] Need b=0 data and a single non b=0 shell
Could I do a tensor fit using the b=1000 shell via the reconstruction pipeline of qsiprep? Would you please suggest how to set this up in qsiprep? Thank you.

Hi there, just chipping in; I'm the developer of SS3T-CSD (ss3t_csd_beta1).  I have the feeling there's some confusion here; @layerConnectome, can you clarify your ultimate goals with the data?  I would partially echo @smeisler's comments; but there is some nuance.  Just to split up between a few distinct goals:

If you're ultimately after a tensor fit, as in "diffusion tensor imaging (DTI)", then yes, you'd preferably use b=0 and b=1000.  But again, that's for the DTI model.
If your ultimate purpose is WM fibre orientation distributions (FODs), so the interest is in constrained spherical deconvolution (CSD) techniques, then there are generally two reasonable options with your data: MSMT-CSD using the entire dataset (all b-values, as @smeisler suggested correctly), or alternatively SS3T-CSD --however-- the latter would typically be using the highest b-value (so b=0 and b=2000 here).  Both are sensible options.  The latter SS3T-CSD choice would be motivated by higher angular contrast-to-noise ratio and/or less extra-axonal signal contributions for the purpose of quantifying apparent fibre density.  With 53 gradient directions, you have the data to support it.
As mentioned, SS3T-CSD (for the purpose of WM FODs) using your lowest b-value is generally not advisable and sub-optimal compared to both of the aforementioned two other options (MSMT-CSD using all b-values or SS3T-CSD using the highest b-value). The only reasons for doing such a thing, would be if there are strong concerns or issues with your highest b-value data, such as unusually low SNR and strong Rician biases.  I've only seen this in a couple of particularly exceptional scenarios; so this likely doesn't apply to your case.

...but as mentioned, I got the feeling this question arose from a confusion with tensor modelling (DTI).  If you do need a specific set of b-values extracted upfront, you can indeed use @smeisler's suggestion via Scilpy, or e.g. the dwiextract command in MRtrix.  Other packages probably have similar commands as well.
We described several things related to acquisitions/data for WM FOD reconstruction in our recent fixel-based analysis review paper here: https://www.sciencedirect.com/science/article/pii/S1053811921006923 .  A lot of this is based on the original apparent fibre density paper by David Raffelt ( https://www.sciencedirect.com/science/article/pii/S1053811911012092 ), and Sila Genc's work on the impact of b-values on estimating apparent fibre density ( https://onlinelibrary.wiley.com/doi/full/10.1002/hbm.24964 ).

This is worth adding to the documentation


Try out Greenkeeper for dependency management

Keeping up with dependency updates is quite time consuming. It's not really necessary, but ideally we want to be able to leverage bug fixes, new features, and improvements.
Greenkeeper.io is a service that sends PRs for out of date dependencies. It runs the tests, and indicates in the PR whether or not they pass. The service is used by several of our dependencies, e.g. request, and I think it would be great to try it out.
Some of our dependencies are deliberately held back at specific versions. After some research I found there's a hidden feature that can be used to ignore certain dependencies.
My intention is to submit a PR adding the ignore statement, and once merged, try out enabling greenkeeper to see if it's useful, or if the noise turns out to be too much.

So, I tried enabling greenkeeper, and this happened: https://github.com/TryGhost/Ghost/pull/6460
Which tried to update our pinned dependencies as well as over-update things like knex.
For now, I've done https://github.com/TryGhost/Ghost/pull/6463
And I've opened 2 issues against greenkeeper:

https://github.com/greenkeeperio/greenkeeper/issues/132 (ignores not working - already fixed)
https://github.com/greenkeeperio/greenkeeper/issues/133 (over-updating to prereleases)

This is done and working 💃


Php missing xsl, even when specified

Composer error
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for magento/framework 100.1.3 -> satisfiable by magento/framework[100.1.3].
    - magento/framework 100.1.3 requires ext-xsl * -> the requested PHP extension xsl is missing from your system.
  Problem 2
    - Installation request for magento/product-community-edition 2.1.3 -> satisfiable by magento/product-community-edition[2.1.3].
    - magento/product-community-edition 2.1.3 requires ext-xsl * -> the requested PHP extension xsl is missing from your system.
  Problem 3
    - magento/framework 100.1.3 requires ext-xsl * -> the requested PHP extension xsl is missing from your system.
    - magento/theme-frontend-luma 100.1.2 requires magento/framework 100.1.* -> satisfiable by magento/framework[100.1.3].
    - Installation request for magento/theme-frontend-luma 100.1.2 -> satisfiable by magento/theme-frontend-luma[100.1.2].

  To enable extensions, verify that they are enabled in those .ini files:
    - /data/etc/php/php.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

boxfile.yml
    extensions:
      - curl
      - gd
      - intl
      - mbstring
      - mcrypt
      - pdo
      - pdo_mysql
      - simplexml
      - soap
      - xsl

php.ini
$ grep xsl /data/etc/php/php.ini
extension=xsl.so
$ php --info | grep xsl

version
$ php -v
PHP 7.0.15 (cli) (built: Jan 25 2017 22:39:07) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

Seems xsl must come after xml...


DocsArchive-<IP_ADDRESS>Auto archive content

Auto archive content from https://github.com/opstest2/docs-archive-test-source.git

Docs Build status updates of commit 43a1531:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error: RepositoryUnauthorizedWithSourceCommit] Git data access to 'https://github.com/opstest2/docs-archive-test-target' (branch: Release_Archive_main_2022-01-28-02-32-04) is not authorized.. It looks like this might be the first time user: v-alji submitted a pull request to this repo. Before user can run builds in a pull request, he/she can enable 'v-alji' GitHub account in Docs by visiting Docs Portal (https://ops.microsoft.com). After enabling his/her account (v-alji), close and then reopen this pull request to start another build.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add CODEOWNERS file

Resolve #5253
Description

CODEOWNERS is a file used on GitHub "to define individuals or teams that are responsible for code in a repository." This repository even has one such file.
Checklist:

[x] I am adding a new language.

[x] The extension of the new language is used in hundreds of repositories on GitHub.com.

Search results for each extension:

filename:codeowners - 126K results

[x] I have included a real-world usage sample for all extensions added in this PR:

Sample: CODEOWNERS licensed under CCBY4.0

[x] I have included a syntax highlighting grammar: preview

Failed test just says license needs review: Unlicense

Thanks for the prompt response to my issue (#5253)! 👍


submodule

if bundle directory is inside of a git repo, bundles should be added as submodules and not cloned.

It looks to me like #185 allows you to bootstrap your vundled-vim by ignoring your bundle directory, adding vundle itself as a submodule, and then letting vundle manage the other plugins:
cd ~/.vim
git init
echo "bundle" >> .gitignore
git submodule add -f git@github.com:gmarik/Vundle.vim.git bundle/Vundle.cim
git add .

The add . allows you to pick up non-vundle-managed config (e.g. .vim/indent/ruby.vim) including (with vim 7.4) a .vim/vimrc!
Then one you've cloned this you can just do vim -c ":BundleInstall" and vundle will grab all of your plugins for you. No need to worry about managing submodules for each plugin - your vim git repo only need change when you edit your vimrc or add any manual configuration.


Latex error

While running simple sample code (which is given in Quick start at Manim community) I am getting Latex error.
here is code:
`from manim import *
class HelloLaTeX(Scene):
def construct(self):
tex = Tex(r"\LaTeX", font_size=144)
self.add(tex)`
this is the error:
ValueError: latex error converting to dvi. See log output above or the log
file: media\Tex\07fd8c4c1d6550a5.log
[6700] Execution returned code=1 in 74.809 seconds returned signal null
Command failed:
'' is not recognized as an internal or external command,
operable program or batch file.
however, I had installed Latex using command
choco install manim-latex
please help.

Under Windows I would recommend to rather install MikTeX using its native Windows installer and not using Choco for this.
The error message simply means that Manim is not able to find the LaTeX executable, LaTeX is an external software which has nothing to do with Manim, but is needed by Manim to render mathematical equations in MathTex and text in Tex objects. In order for this to work, Manim/Python need to be able to call the corresponding executable files which thus have to be on the Windows search path.
On a Windows powershell or command prompt (from where you also execute Manim) try what you get when calling pdflatex --version
You can find MikTex and its installer here: https://miktex.org/howto/install-miktex

@uwezi  Sir, I had MikTeX already Installed. But, still this code, showing an error. Please help. Further, I had run above command, mentioned in your comment (pdflatex --version). This gives me following:
C:\Users\akash>pdflatex --version
MiKTeX-pdfTeX 2.9.7029 (1.40.20) (MiKTeX 2.9.7050 64-bit)
Copyright (C) 1982 D. E. Knuth, (C) 1996-2018 Han The Thanh
TeX is a trademark of the American Mathematical Society.
using bzip2 version 1.0.6, 6-Sept-2010
compiled with curl version 7.61.1; using libcurl/7.61.1 WinSSL
compiled with expat version 2.2.6; using expat_2.2.6
compiled with jpeg version 9.3
compiled with liblzma version 50020042; using 50020042
compiled with libpng version 1.6.35; using 1.6.35
compiled with libressl version LibreSSL 2.8.2; using LibreSSL 2.8.2
compiled with MiKTeX Application Framework version 4.6961; using 4.6961
compiled with MiKTeX Core version 14.7079; using 14.7079
compiled with MiKTeX Archive Extractor version 1.6882; using 1.6882
compiled with MiKTeX Package Manager version 6.7100; using 6.7100
compiled with poppler version 0.60.1
compiled with uriparser version 0.9.2
compiled with zlib version 1.2.11; using 1.2.11
As we can see, there are two version of Latex (since I already had MiTex installed on my Laptop, before installation of Manim)

can't we continue this discussion on Discord? Checking for new answers on github is a bit cumbersome...
https://docs.manim.community/en/stable/faq/general.html?highlight=discord#where-can-i-find-more-resources-for-learning-manim
Since your operating system seems to be able to find your latex, I have a hard time understanding the cause of your problem.
Oh wait a second now... your error message contains 2 parts. I only had seen the second one and assumed that you had omitted something like "latex.exe is not recognized..." but first it says that actually LaTeX was running on your code and produced and error which is supposed to be documented in media\Tex\07fd8c4c1d6550a5.log
So I have two questions now:
a) what is the missing part in "is not recognized as an internal or external command"
b) what is the content of media\Tex\07fd8c4c1d6550a5.log

@uwezi ok sir, let's continues on the discord. But, I didn't how to post this question there. Further, I don't know about (a) & (b). Please help.

On Discord you would start a new discussion in the "help forum"
However, let's stay here...
a) in your original post you were citing parts of the output you got from Manim. But you left out some essential parts. Something is missing at the beginning of this line

b) the message also gives the name of a file on your system media\Tex\07fd8c4c1d6550a5.log where media is a subdirectory in the same directory where you have stored your .py file. This file, 07fd8c4c1d6550a5.log , is generated by LaTeX and may contain important information about the cause of your problem.

Closing due to inactivity


getting false positives with advanced threat protection

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-threat-detection-overview
We are running some code generated by a third party tool on our ADW (azure data warehouse) and are getting alerted for potential sql injection. The code is benign so please let us know a way to turn off the white noise. We do not want to turn off the alerts.

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

ID: 84969b1b-b82c-ddc5-5716-e22a2a37d505
Version Independent ID: 24a33dfd-bb0d-e228-aaf9-44802b625aa8
Content: Advanced Threat Protection - Azure SQL Database
Content Source: articles/sql-database/sql-database-threat-detection-overview.md
Service: sql-database
Sub-service: security
GitHub Login: @monhaber
Microsoft Alias: ronmat

Thank you for reaching out.
We are actively investigating and will get back to you soon.

@pvemula2 I am not sure if suppressing alerts for individual queries is supported at the moment.
@monhaber Could you please confirm and evaluate if the documentation needs to be updated accordingly.

We will proceed to close this issue now.
If there are further questions regarding this matter, please comment and we will gladly continue the discussion.