dotnetCorePackages.dotnet_{8,9}.vmr: switch CDN URL

As it was announced in dotnet/announcements#336, the CDN for .NET assets is changing, so change those ahead of time.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 367825

can we fix the:
artifactsUrl=https://dotnetcli.azureedge.net/source-built-artifacts/assets/Private.SourceBuilt.Artifacts.$artifactsVersion.centos.9-x64.tar.gz

as well so it works if we later remove the substitution below?

done


More fixes for Purr data compatibility

As promised (and a lot quicker than expected, too).
Provided a dummy implementation of pd_undo_set_objectstate for now (this is needed for the guis which haven't been ported to nw.js yet anyway). The missing declaration for obj_findsignalscalar in m_imp.h was a glitch on the Purr Data side, fixed in the testing branch now.
This now also compiles cleanly on the Mac, and doesn't crash with the gui objects like keyboard on Linux any more, which is progress. :)
It still throws a gazillions of legacy tcl command warnings for the gui objects, but that's expected at this point. Non-gui objects should be working now (I only tested a handful of the help patches, but these all seemed to work fine).

great, like I said, I couldn't see the else objects in the test builds, would love to try'em too

Thanks, that was quick, almost real-time. ;-)

I couldn't see the else objects in the test builds

No, I'm still building them out of tree for now. But with all the compilation issues sorted out, getting ELSE integrated as a submodule in Purr Data should be a piece of cake now. I'll give you a heads up when I'm done with this, but don't hold your breath just yet, I have some other tasks on my TODO list for this week. The end of our winter semester is coming up, though, and then I should hopefully have some more time to work on this.


Combine Extractor and Resolver for DependencyCollector into a single type

Keeps the logic of this process internal to a new class and does not pollute the schema class.
Removes the need to re-inspect the receiver type again at runtime.

@bot-gradle test and merge

The merge queue build has failed. Click here to see all failures.

@bot-gradle test and merge

Sorry some internal error occurs, please contact the administrator @gradle/bt-developer-productivity


Dynamic Code Evaluation prevents Flagsmith to run on Next.js middlewares

Hi,
I'm trying to run flagsmith on a Next.js middleware to load different routes depending on flags as below:
import flagsmith from "flagsmith/isomorphic";
import { NextRequest, NextResponse } from "next/server";

flagsmith.init({
  environmentID: {{ENVIRONMENT_KEY}},
});

export default async function middleware(request: NextRequest) {
  const url = request.nextUrl.clone();

  if (flagsmith.hasFeature(url.pathname)) {
    const UUID = crypto.randomUUID();

    await flagsmith.identify(UUID);
    url.pathname = flagsmith.getValue(url.pathname) as string;

    const response = NextResponse.rewrite(url);

    return response;
  }
}

It runs locally, but fails on build with the error:
./node_modules/flagsmith/index.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function') not allowed in Middleware pages/_middleware

Import trace for requested module:
./pages/_middleware.ts

I would like to know if there is a plan to support Next.js Middlewares in the near future.
For reference:
Edge Runtime Unsupported APIs

UPDATE
The Function calls are added when AsyncStorage is used.  If you don't pass it as a parameter and build the project, it will not include any dynamic code evaluation on the index files.
// index.ts - line 6
const flagsmith = core({ fetch });

This is not a solution, just some progress on the investigation.

@dabeeeenster all of the flagsmith code is obfuscated and compiled. you don't provide unobfuscated source. what's the best way for us to help?

my bad, i couldn't find the correct file :)

This is now available in flagsmith 3.3.2, there's a working example here

Nice @kyle-ssg! Thank you!

No problem! I'd love to hear about what you do with it, had a play around with it today, it looks like the main use cases would be redirecting for abn tests maybe


fix containerd CVE-2023-25153

Ⅰ. Describe what this PR did
fix containerd CVE-2023-25153
https://github.com/containerd/containerd/security/advisories/GHSA-259w-8hf6-59c2
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

lgtm


Dask arrays from open_mfdataset not loading when plotting inside a multiprocessing instance

Code Sample
Unfortunately I cannot include the original data, as it is quite large, but I can make an accessible dropbox folder if needed.
debug = False
if not debug:
    import matplotlib
    matplotlib.use('Agg')

import matplotlib.pyplot as plt
import xarray as xr
import metpy.calc as mpcalc
from metpy.units import units
from glob import glob
import numpy as np
import pandas as pd
from multiprocessing import Pool
from functools import partial
import os
from utils import *
import sys

variable_name = 'cape_cin'
projections = ['de','it','nord']

def main():
    """In the main function we basically read the files and prepare the variables to be plotted.
    This is not included in utils.py as it can change from case to case."""
    files = glob(input_file)
    dset = xr.open_mfdataset(files)
    # Only take hourly data
    dset = dset.sel(time=pd.date_range(dset.time[0].values, dset.time[-1].values, freq='H'))
    # Parse metadata for metpy
    dset = dset.metpy.parse_cf()
    # Select variable
    cape = dset['CAPE_ML'].squeeze().load()

    # Get coordinates
    lon, lat = get_coordinates(dset)
    lon2d, lat2d = np.meshgrid(lon, lat)

    time = pd.to_datetime(dset.time.values)
    cum_hour=np.array((time-time[0]) / pd.Timedelta('1 hour')).astype("int")

    levels_cape = np.arange(250., 2000., 250.)

    cmap = truncate_colormap(plt.get_cmap('gist_stern_r'), 0., 0.7)

    for projection in projections:
        fig = plt.figure(figsize=(figsize_x, figsize_y))
        ax  = plt.gca()
        m, x, y =get_projection(lon2d, lat2d, projection, labels=True)

        # All the arguments that need to be passed to the plotting function
        args=dict(m=m, x=x, y=y, ax=ax, cmap=cmap,
                 cape=cape, levels_cape=levels_cape,
                 time=time, projection=projection, cum_hour=cum_hour)

        print('Pre-processing finished, launching plotting scripts')
        if debug:
            plot_files(time[1:2], **args)
        else:
            # Parallelize the plotting by dividing into chunks and processes
            dates = chunks(time, chunks_size)
            plot_files_param=partial(plot_files, **args)
            p = Pool(processes)
            p.map(plot_files_param, dates)

def plot_files(dates, **args):
    first = True
    for date in dates:
        # Find index in the original array to subset when plotting
        i = np.argmin(np.abs(date - args['time']))
        # Build the name of the output image
        filename = subfolder_images[args['projection']]+'/'+variable_name+'_%s.png' % args['cum_hour']

        # Do the plot
        cs = args['ax'].contourf(args['x'], args['y'], args['cape'][i],
                                                 extend='both', cmap=args['cmap'],
                                                 levels=args['levels_cape'])

        if first:
            plt.colorbar(cs, orientation='horizontal', label='CAPE [J/kg]', pad=0.03, fraction=0.04)

        if debug:
            plt.show(block=True)
        else:
            plt.savefig(filename, **options_savefig)

        remove_collections([cs, an_fc, an_var, an_run])

        first = False

if __name__ == "__main__":
    main()

Problem description
My task is to routinely plot output from weather models in an automatized way. The main driver script is written in 'bash' and calls different 'python' scripts at the same time.
Given that the input data is always dimensioned '(time, level, latitude, longitude)' and that I have to do one plot per timestep it seemed natural to me to use multiprocessing to split the load of different time-chunks over different processors. Since I also have to pass some parameters/variables I call the function to do the actual plotting plot_files using the partial constructor plot_files_param=partial(plot_files, **args). This way I can then unpack all the needed parameters/variables in the function itself without needing to declare them as global variables. Note that this is fundamental as, to make everything fast, I only create most of the variables/instances once and then update them at every iteration.
This works fine if I load the input netcdf file with open_dataset, but instead if I use open_mfdataset (as in some case I have many files scattered in a folder) then I have to be careful in explicitly loading the arrays before passing them to the plotting function, otherwise the script will hang.
More specifically.  if I remove the .load() statement from this line
cape = dset['CAPE_ML'].squeeze().load()

then cape stays a dask array and gets passed as argument to plot_files. Then I was expecting the plot call to load it as array in memory before doing the plot, but this does not happen (I think) and then the script just hangs (does not post any error). Interestingly enough, if I use the option debug = True, which instead of parallelizing the plotting just plot 1 timestep and directly show the output, everything works fine, although the array passed is still a dask array. So, this is definitely something related to the use of the partial construct.
In theory I would like to keep the .load() usage as small as possible as data can be pretty huge and I only want to load it into memory when I have to plot it.
It may well be that my code is somehow malformed but as far as I know this should not be the expected behaviour. Please apologize if I'm doing something wrong; every suggestion is highly appreciated! Thought that I report the error as I found it to be non-expected behaviour.
Expected Output
Array should load into memory when plotting without the need to do it explicitly.
Output of xr.show_versions()

INSTALLED VERSIONS
------------------
commit: None
python: 2.7.15 | packaged by conda-forge | (default, Nov 29 2018, 06:43:57)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)]
python-bits: 64
OS: Linux
OS-release: 3.16.0-7-amd64
machine: x86_64
processor:
byteorder: little
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LOCALE: None.None
libhdf5: 1.10.3
libnetcdf: 4.6.1
xarray: 0.11.2
pandas: 0.23.4
numpy: 1.15.4
scipy: 1.2.0
netCDF4: 1.4.2
pydap: None
h5netcdf: None
h5py: 2.8.0
Nio: None
zarr: None
cftime: <IP_ADDRESS>
PseudonetCDF: None
rasterio: None
cfgrib: <IP_ADDRESS>
iris: None
bottleneck: None
cyordereddict: None
dask: 1.0.0
distributed: 1.25.0
matplotlib: 2.2.3
cartopy: 0.17.0
seaborn: 0.9.0
setuptools: 40.6.2
pip: 18.1
conda: None
pytest: None
IPython: 5.8.0
sphinx: None

Sorry we didn't get to this — we should have replied requesting an MCVE. Closing now, though.


Fix knex d.ts to work with Node16 module mode

Currently, the knex type declarations use export default as if it were an ES module. This has not mattered up until recently with Node's increased ESM support and TypeScript's node16 module setting, which is the TypeScript's team recommended setting for Node users.
Bear with me - this is a bit convoluted. Node's behavior when importing CJS from an ES module is to make module.exports the default export. TypeScript adheres to this, which leads to some weird quirks when we look at knex's type declarations. TS properly detects knex as a CJS module, and when it sees a default export in the declarations, it assumes that the knex function is set to module.exports.default (which it also is) but not to module.exports.  So to TS, under node16 module mode, the default export from knex is simply an object with a default property. It cannot be called as a function, even though this is perfectly legal at runtime.
What's the fix here? It's quite simple. Use export = syntax to describe the CJS export, and declare the circular references set in knex.js. This works perfectly in both the new world and old, since we are explicitly telling TS the shape of the proper CJS export rather than having it make assumptions.

@OlivierCavadenti - would really appreciate a look at this one. The TypeScript team is really pushing Node users to move to module node16 and the current typings make this very difficult. Let me know what else I can do to help!

https://arethetypeswrong.github.io/?p=knex%402.5.1

@kibertoad I have not found a way to configure the type definition testing tool to test using module node16/nodenext in addition to the current settings. The tool seems to only allow for one tsconfig configuration in the package.json. If someone has a way to do this I am happy to give it a shot.

Is there plans to release a new patch version soon that includes this fix?

@kibertoad will this be published this week? Thank you :)

Does this not resolve #5358?

It does @Jiralite ! We need a new version published with this code though.

Awesome. Yeah, I was more pointing out that issue should ideally be closed then.

Sorry for the delay. 3.0.0 is now out! Please let me know if it works as expected.

@kibertoad Thank you, it’s now working as expected.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.4.134",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d04958a348e560938410e04a12fb99da9c7e6a00"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "d04958a348e560938410e04a12fb99da9c7e6a00",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "scsi: iscsi: Fix conn use after free during resets\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.4.134 by commit d04958a348e560938410e04a12fb99da9c7e6a00. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001335


yv4: sd: reset the WDT after the platform reset event

Description:

Reset the WDT after the platform reset event

Motivation:

After updates BIOS and system reboots, BMC logs the event "Event: HostX BIOS FRB2 Watchdog Timer Expired, ASSERTED"

Test Plan:

Update BIOS and reboot system, check event logs

I've re-pushed the commit.


Markdown bold not rendered as bold.

Editing an .md file, with :set conceallevel=0 (default), I see this:
**foo** and _bar_
i.e., I see the word "foo" in plain style and the word "bar" in italic style. (Ignore apparent spaces after or before asterisks or underlines; they're an artifact ot backticks used in composing this issue post.)
With :set conceallevel=2 the asterisks and underlines disappear but the styles don't change.
Summary: Markdown italic works, but bold doesn't work. In nvim/Terminal.app bold is rendered in red letters rather than in bold style, and italic (underline before and after) does not work.
I have the Menlo typeface specified in settings.toml; Menlo has bold and italic variants. I also have Menlo specified in Terminal.app preferences.
nightly-1-gccee4b8

@proofer
Hi, Sorry for late reply.
In summary, am I correct in understanding that in buffers of Markdown file types, the bold style is not applied and the normal style is used?
(I also understand that this is essentially a file type-independent issue.)
If so, it is most likely a font typeface issue.
For example, what about other font typefaces?
I understand that you have Menlo set up in your environment and that this font also has a bold typeface.
Goneovim uses Qt for its GUI framework, and I believe the issue is whether the Qt framework properly associates and recognizes the bold typeface in the given font family.

@akiyosi
Correct. Because the issue is not in goneovim I'll close it.

@proofer
Please don't get me wrong, the above comment is a general statement, but at this point I am not sure if the problem is caused by goneovim, Qt, or the OS environment.
If you could provide me with additional information, such as how the problem is reproduced in different font typefaces, I would be more than willing to help investigate the cause on an ongoing basis in terms of the goneovim.

The only two monospaced typefaces with regular, bold, and italic styles that I have are Courier New and Menlo. I see the issue of bold displaying in regular style in .md files only with Menlo; with Courier New, bold does display correctly. I don't know what might explain the "deficiency" of Menlo.
macOS 12.6
Characteristics of typefaces based on Font Book application.


SqlServer Custom Identity class names

I am using a "Database first" approach   with "Users", "Roles"  as my Identity tables .I am also using EF 7 MVC 6  with Web API  . In my DbContext class I map  the default AspNetUser class to my Custom  table "Users"  using modelBuilder.Entity().ToTable("Users");
But I get this error  "Cannot use table 'Users' in schema '' for entity 'ApplicationUser' since it is being used for another entity"   when I run the application .

Found the solution . The error was a result of mapping the ApplicationUser class to entity tyoe Users as well as having a separate Users entity . After deleting the Users entity everything now works fine .


Unit test fixes for python 3.9

This partially implements the updates in #1717, for the specific tests that were failing under 3.9. There is some overlap with #1854.

Codecov Report

Merging #1858 (14dbed3) into main (f0b2719) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1858   +/-   ##
=======================================
  Coverage   93.72%   93.72%
=======================================
  Files         536      536
  Lines       34015    34015
=======================================
  Hits        31881    31881
  Misses       2134     2134

Any update on the cause of the integration test error?

@andrewwhitehead -- we have conflicts. Can you please fix, and see if the other updates you made will resolve the integration test failures?  Thanks!

After talking with @dbluhm, we both agree that we would like to see this PR merged before we make more updates on #1854 . We intend to handle conflicts as we update #1854.


Update documentation references

PR Summary
The PR updates the documentation links and references. More specifically:

PR changes the master branch links to use main branch which set to be the default of this repository.
Commit 1754fa778666d1d368fdf6770b2a9dcffb3941bb renamed doc directory to be docs. PR updates sources to changes.
Commit 2431a2a360d5a9cbae44de788cb592c07464f73b renamed docs/security.md to be docs/assurance-case.md. PR updates sources to changes.
Commit 5b9592d1b09671260bf0928e9b019d39a2df462d renamed test/features/login_test.rb to be test/system/login_test.rb. PR updates sources to changes.

Thank you so much! I appreciate it.
Why are the vcr_cassettes being updated though?

@david-a-wheeler, thank you for review. I updated all files that indicated they had changes. Should I revert the changes to the vcr_cassettes?

Yes, please revert in this PR. We can review those cassette changes separately, but such review is more complicated.

BTW, thanks so much for this work. Documentation is important and it's sometimes hard to get people to review/fix things in it :-).

@david-a-wheeler reverted the vcr_cassettes changes 😄

@david-a-wheeler please merge this PR when you get the chance

Awesome! Thank you!

In the long term we'll need to have the translators update, but this is a great start.

@david-a-wheeler please merge this small PR when you get the chance. Thank you for review 😄


Importing the first account ever does not open it automatically

When exporting our default account and importing it into a new Cutecoin install, nothing seems to happen as we stay on the welcome page.
As it is the first and only account, it should be automatically opened after import.

Done in e6360fd7010edc99cb340b1f8b73ac7fc8806eaa


Use the library with listview

Im trying to use the library, but parallax is not showing in my example.
Im using a listview
<ListView
                dataSource={this.state.dataSource}
                renderRow={this.renderRow}
                style={Styles.listView}
                />

And in in the renderRow method, I have this
<Parallax.Image
                    parallaxFactor={PARALLAX_FACTOR}
                    style={{ height: 90 }}
                    scrollY={this.state.parallaxScrollY}
                    source={{ uri: "http://loremflickr.com/1200/990/" + SECTIONS[random].keyword}}
                    >
                    <View style={Styles.container}>
                      .........
                    </View>
                </Parallax.Image>

The effect Im getting is this. No movement, just showed it misplaced, like the parallax was just applied without scrolling.
Any help?
Thanks!

You need to add scrollEventThrottle={16} and onScroll={this.onParallaxScroll} to your ListView.


Feature documentation

Some initial scaffolding of the documentation.

@Bohdan-Anderson-Rangle Few minor things overall LGTM.


Named tensors

PyTorch has experimental support for named tensors achieving some compelling design goals while keeping existing code compatible. For example, binop broadcasting is still based on dimension order (unlike in xarray), consistent with standard NumPy/JAX/... semantics, but checks that aligned dimension names match.
It would be great to have named tensors that work both in op-by-op and under function transformations in JAX.
@shoyer In https://github.com/google/jax/issues/1565 you mentioned that this could be done by wrapping JAX based on https://github.com/google/jax/pull/611. According to my current understanding, this means:

Add name rules for lax primitives, returning the output dimension names for given input dimension names.
Add a corresponding eval_names transform.
Add a NamedDeviceArray subtype of DeviceArray that adds a names property.
We want names to be propagated in op-by-op mode on NamedDeviceArrays. For that,

make a named version of jax.numpy, wrapping each op with the named transform.
attach it to NamedDeviceArray using https://github.com/google/jax/pull/611 (+1 for merging). Alternatively, one could rewrite jax.numpy using numpy_dispatch.get_array_module from https://github.com/google/jax/pull/4076 (appears cumbersome).

Make jitted functions propagate names when applied to NamedDeviceArrays.

Is this plan sound? @shoyer @mattjj Would you update (and merge, if successful) https://github.com/google/jax/pull/611 just for this application? In that case, I'd be interested in prototyping a named tensor library for JAX, with a good amount of passion, in accordance with https://github.com/google/jax/issues/1565. (:

Have you started working on this @JuliusKunze ?

We are actually working on something that will pretty much realize the plan that @JuliusKunze has outlined here, with some additional benefits too (e.g. making it very easy to shard those programs with named axes over multiple accelerators).

@Jeevesh8 No, and now I won't anymore. (: @apaszke That's great to hear! Will this go into the JAX repo?

Do I assume correctly that this evolved into named axes, or is there another module I did not find?

That's correct.

@apaszke @froystig That looks awesome! Rad choice not taking into account order of named axes and broadcast by name! That's semantically cleaner and more future-proof than I expected. (: The thing that I thought would make this impractical is that it's hard optimize misaligned dot product axes (and similar operations) where silent transposes will happen on device. I guess this is not the case, or axis order optimization could (and should) be automated anyway in the future? Very curious how you arrived at this design.
+1 for allowing arrays and operations with named axes outside of xmap, i. e. make named axis arrays first-class in jax as suggested above.

A more powerful implementation is to use first-class dimensions, and torchdim uses objects as dimension "variables"

@apaszke Perhaps it could be further independent of axis position? By utilizing the named tensor feature, operations that do not depend on axis position can be achieved.

For example, the for loop operation can directly specify which axis to loop on, and the framework automatically advances the axis to the first dimension. The entire operation is transparent, and users do not need to write any additional code.
For example, we can directly use axis names and indices on that axis to access tensors.

# tensor.named_shape={'batch':32, 'time':100, 'hidden':200}

t[{'time':0, 'hidden':0}] = 1000 # Select tensor with axis time 0 and axis hidden 0, and set tensor to 1000 with broadcast.

for t in tensor['time']:
# Jax automatically performs dimension permutation for operations: tensor: batch, time, hidden -> time, batch, hidden
# t.named_shape = {'batch':32, 'hidden':200}
    ...

@Bit0r I built your suggestion into some code I wrote for operating on a tuple or namedtuple of tensors
https://github.com/kentslaney/umap-cam/blob/7be1b04c509850cca4b192d821f9c6761ec6b218/src/umap-cam/group.py#L192-L203


Remove redundant flags from webhook-based autoscaler

Ref #623

Actually just realised the values.yaml [charts/actions-runner-controller/README.md] docs have references to the old flags and need updating as part of this PR

@toast-gear Good catch! Fixed in 4f1d9ac

Thanks for reviewing ☺


Image Background Remover

Describe the solution you'd like
Using the Grabcut Python cv2 algorithm user can subtract the background from the image and only the foreground remains in focus.
I am a GSSoC'21 participant, Kindly assign me the same.
@avinashkranjan

/assign

@iamakkkhil assigned to you


⚠ ESPN has degraded performance

In 69c00a2, ESPN (https://espn.com) experienced degraded performance:

HTTP code: 200
Response time: 1545 ms

Resolved: ESPN performance has improved in 02ddf33.


Allowing breadcrumbs to show/hide consistently with or without parentSite

I'm building a project without a parentSite and my first level of breadcrumbs weren't showing up unless I set up a parentSite.
This should resolve the issue.

I thought we were using our own filter for breadcrumbs, but we’re actually using a function from the eleventy-navigation plugin.
If we were using own own filter, Frankie’s approach might work, but given how this currently works, this is a really nice and clear way of fixing this issue.
Thanks for the PR!


Maximize - Ability to toggle animation on and off

Hi mauricius,
Great work with this component so far! 👍
I have added a new property to the component namely : animate (boolean)
This property toggles the animation in the fillParent function.
Hope you accept this pull request.
If you do : Please can you update the NPM package as well?
Thanks a million!

Hi again,
Any chance you have had a look at this?

Hi @deathblade89, sorry for the delay.
I looked at your PR, but it seems to have a few issues. If you try to maximize the component and immediately you try to resize it without deactivating, it goes back to the original size. Probably this is not what you were trying to achieve.
Also I decided to remove the maximize behavior from the new major version, which is available on the develop branch. It was completely useless to be honest.
Version 1 is going to be deprecated soon.

Hi @mauricius ,
Thanks for the reply. I did miss that resize issue, but since you are going to be removing this functionality there is no real reason to add onto it.
I just found that resizing to fit the container bounds was unnecessary to animate in. If you decide to keep this feature in the main branch, consider making a snap to full screen without animation.
Thanks for the response.


Generate final tag and publish draft release for Wazuh 4.9.0

Description
This issue attempts to publish draft release and generate final tag for version 4.9.0 in the wazuh-dashboard repository.
Tasks

[x] Generate final tag v4.9.0 from branch 4.9.0 on wazuh-dashboard repository.
[x] Publish GitHub draft release from tag v4.9.0.

LGTM


Correlation ID on API requests

If a customer runs generate-script, then runs the generated-script which executes 500+ API calls. It would be nice if we could understand from the logs that those 500 requests were all part of the same "run".
Could maybe have a correlation ID that is randomly generated as part of generate-script and set as an env var. Then each command could pass that as an extra HTTP header to each API call and we can capture it in the backend logs for reporting purposes.

IMO this is not a high priority, going to close it. Can always revisit later.


Parallel

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

could we please add description to the PR and meaning PR title ? Please could we make it a norm going forward ?


Docker design feedback

This issue is for users to provide feedback on their experiences with integrating Mutagen's Docker support into their Docker workflows.  Mutagen itself provides the minimal set of tools necessary to synchronize with Docker container filesystems, but it will be most useful when coupled with orchestration tools and other higher-level container management workflows that can automatically set up synchronization.
In order for Mutagen to provide the best API and configuration options to support these tools, users are encouraged to experiment with integrating Mutagen into their workflows and reporting any issues that they run into or ideas that they might have about how to make things easier.  Everybody's setup and use case is different, so it's difficult to predict how exactly Mutagen will be used.  Ideas about additional commands, flags, URL formats, environment variables, or other behavioral control mechanisms to allow for easier embedding would be helpful.  The more concrete and specific the feedback, the more useful it will be.  For example, feedback like "it would be helpful if the create command had a flag to do X (because Y)" is more helpful than "Make it work with Kubernetes!"
The feedback provided here will be instrumental in evolving and expanding Mutagen's Docker support.

I'll start the ball rolling with some initial ideas:

Mutagen requires that containers be running to synchronize with them, so it might be useful to have a flag that can be passed to mutagen create (e.g. --docker-autostart=true) or specified in global configuration to allow Mutagen to automatically start containers when connecting to them.  This could be stored as a session configuration parameter so it always applies to sessions for which this flag was specified.
Since Mutagen needs to stop and restart Windows Hyper-V containers in order to copy agent executables into them, it currently has a prompt that requires user confirmation before installing agents in these cases.  For tooling that wants to tell Mutagen to do this automatically (i.e. without interactive input), an additional flag to create (e.g. --docker-auto-confirm=true) might be useful.
Since Docker synchronization doesn't require interactive input other than the above cases, mutagen create could be modified to detect when it's not connected to a TTY and avoid attempting to prompt in these cases (failing if prompting is required).  It could also be made to print out session identifiers that are easier for tooling consumption in these cases.

In general, we want mutagen to manage the synchronization between a host folder and a docker volume, which then can be mounted by another container. That decouples the synchronization from the actual application container, and allowing orchestration tools to manage the application containers without having to constantly reinstall the agent. This also plays nice when you have multiple instances of the same container.
Based on that, I think a good first building block is to allow an agent to be manually started in the foreground, and allowing the daemon to connect to a running agent.
This would allow an agent to be the main ENTRYPOINT/CMD for a docker image, which can then wait for session creations from the daemon running on the host.
A more concrete example would be:
FROM debian:stretch
COPY mutagen-agent /bin/mutagen-agent
VOLUME /mutagen
CMD mutagen-agent --foreground /mutagen

Then, assuming we start a container built from that docker image:
docker run -d -v a-docker-volume:/mutagen -n mycontainer mutagen-agent

We would be able to run mutagen create /foo docker://mycontainer to start the session on that specific agent, running inside mycontainer.
Something like this would open up a lot of possibilities, including having an official docker image for a mutagen agent and would be very flexible and play well with all other existing tools.

The idea of synchronizing to a single Docker volume that is then shared with a number of containers seems like a smart approach (and avoids the need to re-establish a session if you change containers).
I think your proposal seems like the most straightforward way to do this (i.e. creating an image with the agent as its entry point).  I'd like to take a few days to think about the exact mechanics, especially how such an image might be re-used.  I'd still like the ability to sync into arbitrary containers as exists now, but I could imagine (e.g.) adding another protocol that Mutagen understands, something like mutagen-docker:// that uses this shared image or expects the provided image or container name to have the agent as its entry point.  I also want to make sure that this approach also supports Windows containers.
I'll think about this and try to prototype soon.  Thanks again for the suggestion.

i have issues creating a sync with docker not using root:
error: create failed: unable to connect to beta: unable to connect to endpoint: unable to install agent: unable to invoke agent installation: exit status 1
but since i am sync'ing a webapp i need the files to have www-data as user and not root.

similarly it seem not to transport the right file permissions to the docker container

@kritop When you say "not using root", do you mean that you have a USER directive in your Dockerfile or that you are using a Mutagen URL of the form<EMAIL_ADDRESS>

Mutagen URL with a different User www-data int hat case, correct.

Sorry, one more question. When you say

similarly it seems not to transport the correct file permissions to the docker container

Which file permissions are you referring to?  Were you able to eventually get the synchronization to work?  Or are you referring to the permissions on the agent binary that it copies into the container?
Regarding the issue, I'll try to reproduce ASAP.  I'm moving at the moment, so my Linux system is packed up in a box.  I may have a chance to get it out this weekend, but if not I'll try to reproduce on Travis.  This is almost certainly something to do with Mutagen's roundabout way of setting permissions on the agent binary copied into the container.  The issue is that the docker cp command's behavior when it comes to permissions is under-documented and changes (see e.g. moby/moby#34096).  Mutagen tries to work around this by manually invoking chmod, but the implementation may not be perfect.
Actually, it would be useful to know the client/daemon version in your case from docker version, if possible.

the files have locally (macOS mojave) rwr-r- and rw---- on the docker after the sync.
 Version:           18.09.0-ce-beta1
 API version:       1.39
 Go version:        go1.10.4
 Git commit:        78a6bdb
 Built:             Thu Sep  6 22:41:53 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.0-ce-beta1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       78a6bdb
  Built:            Thu Sep  6 22:49:35 2018
  OS/Arch:          linux/amd64
  Experimental:     true````

the files have locally (macOS mojave) rwr-r- and rw---- on the docker after the sync.

This part is intended behavior at the moment.  Mutagen only transfers user-level (i.e. not group or other) permissions for security reasons.  Specifically, something that is group/other-accessible on a developer's laptop might not make sense to be group/other-accessible on a remote system (especially a shared one).  However, Mutagen will preserve permissions on remote systems, so if you do something like chmod -R go+r <path> on the remote system, Mutagen will preserve those permissions when synchronizing changes.  Mutagen may add a flag to do full raw POSIX permissions transfers at some point, but it would be at least a few releases away.  Also worth noting is that, like rsync, Mutagen will transfer executability bits for group/other in cases where group/other has a corresponding read bit, so if you do manually add readability via chmod on the synchronized copy, Mutagen will take that as a cue to start propagating executability bits for group/other.
Regarding the other issue though, i.e. the inability to install the agent and synchronize as www-data, I'll take a look at this as soon as possible.

@Jarzebowsky Sorry to hear it's not working smoothly.  Can you tell me:

Are you using Linux containers or Windows containers?
What version of Docker for Windows are you running? Specifically, what's the output for docker version, both the client and server portions?
What exactly is the failure mode? Is there a failure message printed? Does Mutagen simply fail to connect?
What is the issue that you're having with docker-sync? Is it possibly related?

my eyes are looking at you @havoc-io

I'll do what I can.  Docker support in Mutagen is still experimental, and it's definitely going to have some initial issues given how many potential Docker setups are available, but hopefully most of the issues can be ironed out quickly.

@havoc-io

Dunno if Docker for Windows provides any more option to change container types. How can I get that information?
Here is the output:
`Client:
Version:           18.06.1-ce
API version:       1.38
Go version:        go1.10.3
Git commit:        e68fc7a
Built:             Tue Aug 21 17:21:34 2018
OS/Arch:           windows/amd64
Experimental:      false

Server:
Engine:
Version:          18.06.1-ce
API version:      1.38 (minimum version 1.12)
Go version:       go1.10.3
Git commit:       e68fc7a
Built:            Tue Aug 21 17:29:02 2018
OS/Arch:          linux/amd64
Experimental:     false `

Can't reproduce that at thsi moment but it couldn't get into beta container which was docker defined with path like: docker://container_name_php/usr/share/nginx/html/project

Docker sync is just going to be dead for Docker users on Windows. All commands return errors and other things in cmd. Would be so much grateful for helping me to get your Mutagen work with my containers smooth as for now Magento with Docker mounting volumes is not working at all.

Hope we can resolve the issue and will be one of those to give you somewhat feedback about it as for now it's unusable for me.

@Jarzebowsky

Dunno if Docker for Windows provides any more option to change container types. How can I get that information?

Usually Docker for Windows asks which container type you want to use when installing.  I think you can check from the tray icon which type you're using, but based on the path that you provided I assume you're using a Linux container.

Can't reproduce that at thsi moment but it couldn't get into beta container which was docker defined with path like: docker://container_name_php/usr/share/nginx/html/project

Without more information, it's difficult to debug the issue.  I'll try to play with Linux containers via Docker for Windows and see if I can reproduce any issues.  If there's a specific error message you receive, that would be very helpful.

@havoc-io Will come to you with the messages today. Just working on Vagrant and would need to restart PC to turn on Hyper-V which kinda can't be done right. The thing is I would like to get it to work by the end of the week :P Maybe I'm just missing something :)

@havoc-io I'm comming back with error messages.
Docker containers got run with docker compose up via cmd. Docker got defined container_name: test_php when running command `mutagen create ./../ docker://test_php/usr/share/nginx/html/test it returns this:
Error: create failed: unable to connect to beta: unable to connect to endpoint: agent handshake failed with error output:
Error: endpoint terminated: handshake transport error: unable to receive client magic number: EOF

@Jarzebowsky Thanks for the error messages.
Can you confirm that the container is running and not halted?  E.g. try running the following command
docker exec test_php uname

Does that output "Linux" or an error?
Mutagen is only able to synchronize with containers while they are running since they use docker exec (which requires the container's primary entry point to be running, probably nginx or some web server in your case).  If the container isn't running, that would probably explain the issue.
Also, would it be possible for you to share part or all of your Dockerfile so that I can get a better idea of what the container looks like?
Unfortunately Docker is a bit weird and it only provides error messages to standard output, not standard error, and since Mutagen uses standard output to receive data, it's hard to also capture error messages.  What I will do in the near future is find some mechanism to tee the output stream so that I can try to scrape Docker's error messages.
Thanks again for your help in debugging.

@havoc-io The command you provided returned Linux.
File you want is docker-compose or Dockerfile for that one container I want? One more question would be, do I need to setup volume from container or it just need to have a container?

The filesystem in the container itself should be sufficient, no need to set up a volume.  Just the Dockerfile for that one container would be good.
If you don't mind running a few more commands and returning their output, it would help a lot:
First, can you dump the home directory for the container user?
docker exec test_php env | grep 'HOME='

Also, can you try
docker exec -i -w $(docker exec test_php env | grep 'HOME=' | cut -c 6-) test_php .mutagen/agents/0.7.0-beta1/mutagen-agent version

Can you then attach to the container (using docker exec -i -t test_php /bin/sh) and provide the output of the following commands:
ls -lash ~/.mutagen
ls -lash ~/.mutagen/agents
ls -lash ~/.mutagen/agents/0.7.0-beta1
~/.mutagen/agents/0.7.0-beta1/mutagen-agent version

For command docker exec test_php env | grep 'HOME=' output is HOME=/root
For command docker exec -i -w $(docker exec test_php env | grep 'HOME=' | cut -c 6-) test_php .mutagen/agents/0.7.0-beta1/mutagen-agent version is not working or I'm using it wrong the output is:
cut: invalid byte/character position ')'
Try 'cut --help' for more information.
Error: No such container: exec

For rest the output in order is:
root@c09ad8939e49:/usr/share/nginx/html/test# ls -lash ~/.mutagen
total 12K
4.0K drwx------ 3 root root 4.0K Oct 12 19:30 .
4.0K drwx------ 1 root root 4.0K Oct 12 20:54 ..
4.0K drwx------ 3 root root 4.0K Oct 12 19:30 agents

root@c09ad8939e49:/usr/share/nginx/html/test# ls -lash ~/.mutagen/agents
total 12K
4.0K drwx------ 3 root root 4.0K Oct 12 19:30 .
4.0K drwx------ 3 root root 4.0K Oct 12 19:30 ..
4.0K drwx------ 2 root root 4.0K Oct 12 19:30 0.7.0-beta1

root@c09ad8939e49:/usr/share/nginx/html/test# ls -lash ~/.mutagen/agents/0.7.0-beta1/
total 4.7M
4.0K drwx------ 2 root root 4.0K Oct 12 19:30 .
4.0K drwx------ 3 root root 4.0K Oct 12 19:30 ..
4.7M -rwxr-xr-x 1 root root 4.7M Oct 12 19:29 mutagen-agent

root@c09ad8939e49:/usr/share/nginx/html/test# ~/.mutagen/agents/0.7.0-beta1/mutagen-agent version
0.7.0-beta1

@Jarzebowsky
Thanks for all of the additional information, it's very helpful.  I'm going to have to sleep on this and get back to you.  Everything looks okay in terms of files and permissions, so I'll probably have to try to replicate the issue myself.

Also got question. I share that one path /usr/share/nginx/html/test on 2 docker containers one is php and 2nd one is nginx how I can handle that with Mutagen

What @divoxx proposed above (and I agree with) is to create a Docker volume that is shared between multiple containers and to create one Docker container whose only job is to synchronize to that volume.  Unfortunately mutagen-agent can't be used as a container entry point, so that synchronization container would probably need to run some blocking no-op command for now.  Once I get started on Mutagen v0.8.x in November, I'll making supporting a scenario like this a priority.

I would really want to get it working till Sunday EOD :P

I can't make any promises on that.  I'm traveling for a conference at the moment and won't be home until Sunday afternoon, and I have quite a bit of other work to do.  But if I can find a simple solution, I'll be sure to let you know.  I may be able to replicate this issue on AppVeyor if I get a few minutes free tomorrow.

@havoc-io any updates on that? :)

@Jarzebowsky Not yet, sorry.  Won't have time to look at it until at least this evening, but can't make any promises about that. I tried to reproduce on AppVeyor unsuccessfully, so I'll need to unpack my Windows desktop to reproduce.  I'll keep you up to date.

@Jarzebowsky I've had about 45 minutes to work on this and I am not able to reproduce.  The synchronization seems to function in my case.
However, I have two ideas about what might be causing the issue.  Can I ask you to run two more commands?
First,
docker exec -i -w /root test_php .mutagen/agents/0.7.0-beta1/mutagen-agent version > version.txt

Second,
docker exec -w /root test_php .mutagen/agents/0.7.0-beta1/mutagen-agent endpoint > endpoint.txt

The second command should print an error like Error: endpoint terminated: handshake transport error: unable to receive client magic number: EOF, but please let me know if it prints anything else.
Now you will have two files in the directory where you ran these commands, version.txt and endpoint.txt.  Can you email these to me?  My email address is in my GitHub profile.
If that isn't enough information to find the problem, I will ship 0.7.0-beta2 as soon as possible, probably next weekend.  This will include additional error debugging information for Docker containers.
Sorry I couldn't make it work for you tonight.

@havoc-io Sorry to bother here but it's not that much informations provided from files.
1st command returned only version and that's the content 0.7.0-beta1
2nd command somehow hang while it was executed and wasn't able to finish it - that's the content of it '�

@Jarzebowsky Thanks, that's exactly what I was looking for.
My original thought was that there might be additional error output when trying to run mutagen-agent via docker exec or that the output stream might have some encoding transformation applied by Docker (since Go has some built-in UTF-8<->UTF-16 conversion for certain output streams on Windows), but it looks like neither of those is the case.  There's no error output and the weird values you saw from the second command are exactly what's expected.
It is interesting though that the second command hung.  Are you sure that you ran it without the -i flag?  It should only hang if you pass the -i flag.  It should have exited immediately with the Error: endpoint terminated: handshake transport error: unable to receive client magic number: EOF error.
If it's hanging without -i, the behavior seems to be reversed, or at least behaves that way.  In your case, when you don't pass the -i flag, standard input is connected, and when you do pass it (or when Mutagen does at least), standard input isn't connected.
Can you tell me what terminal you're using on Windows?  Specifically, where do you run the mutagen daemon start command?  In cmd.exe?  PowerShell?  mintty?  I'm wondering if perhaps there's some environment variable that Docker is detecting (or not detecting) that is causing this sort of inverted -i behavior.
Looking through the various Docker/Moby issue trackers, it seems like there are issues with using -i with certain terminals, and if the Mutagen daemon is started from one of those terminals, then it may be inheriting environment variables that cause Docker to think that it can't support interactive usage.
The terminal I use Cmder with standard cmd in it, used also WSL Bash with same effect if I remember correctly.

@havoc-io Don't know what's the difference between CMD from Cmder and Window's CMD but it connected without a problem. I came up right now with it connected and going forward to test it. So you can check it via Cmder application as it provided me above problems.

@Jarzebowsky I was doing a bit of research earlier regarding Cmder, which seems to use ConEmu under the hood.  Based on a few Docker issues, it seems like Docker and ConEmu have some incompatibilities, and I think that might be causing the issue you saw.  Even though the Mutagen daemon process is running as a detached process, it may have some environment variables it inherited that make Docker think it's running inside ConEmu.  I plan to play with this over the weekend and see if I can figure out exactly what the problem is.  I think I can fool Docker into realizing that Mutagen is not really running inside ConEmu.

@jpambrun Thanks for your additional feedback, all of these experience reports are helpful.
Regarding the one-way sync w/ a "clean" operation, it's definitely useful to have this concrete use case to understand the utility of such a feature.  The easiest way in which Mutagen could implement a one-way sync would make it behave like rsync --delete ..., which obviously wouldn't be helpful in your case.  Perhaps such an implementation should endeavor to be more like rsync's standard non-deletion behavior, but I'll have to think a little bit more about how that would look inside Mutagen.  I think it might be doable just as easily.
Regarding your Docker container question: yes, if you wanted a container whose sole purpose was acting as a synchronization point, using sleep as an ENTRYPOINT could work as a solution for the time being, though a container with mutagen-agent as its ENTRYPOINT command could conceivably provide simpler lifecycle management, avoid the permissions complications that have already arisen with docker cp, give better performance, etc.  I plan to keep Mutagen's low-level direct-to-container sync infrastructure as is, but I think there's definite value in adding a "pre-packaged" solution with the agent as its entry point, especially for integration with orchestration tools.  That'll take some tweaking of the agent implementation, but it's doable.

@Jarzebowsky That looks normal.  The Last error field should disappear after the next successful synchronization cycle (i.e. after staging completes and changes are applied).
That particular error isn't anything to worry about.  It happens when there are concurrent modifications to the filesystem, which Mutagen watches for and then waits for the filesystem to stop changing long enough for a synchronization cycle to complete.  If it doesn't go away, please open an issue.
Actually, if you're already at Staging files on beta, it means the error has already corrected itself.  I should probably modify error tracking to hide errors as soon as they're corrected, rather than waiting for a full synchronizatoin cycle.  I'll put that on the TODO list for v0.8.x.

@Jarzebowsky Do you mean excluding certain paths from synchronization?  That already exists.  Maybe you mean something else though?

@havoc-io Seems like i missed that one somehow. Gonna check it out.

I have been playing mutagen and docker. I like it, but it's prone to error. I had setup syncing, then docker volume rmed the volume. When I restarted the container, the mutagen daemon restarted syncing automatically and started deleting my host files. I think its needs a no delete on host option (perhaps in addition to one-way syncing).
Also, having the agents tar around is a bit cumbersome. It would be cool to have entry in my docker-compose file and only the 10MB mutagen statically linked binary to carry around.
A per-project .mutagen file would be nice as well. Ideally devs would just type mutagen <enter> to get started.

@jpambrun Thanks for the feedback.  Mutagen does have a root deletion detection safety feature where it will halt a synchronization session if the synchronization root is deleted on one side.  My understanding is that, in your case, the volume itself was the synchronization root, so the path to the volume still existed but the contents of the volume had been erased.  This is definitely a bit of a footgun that needs to be fixed, because using a Docker volume as a synchronization root is probably going to be a common case.  Sorry you ran into that trouble.
One thing I've been thinking about for a while is to add additional safety heuristics.  E.g. if N% of files in a synchronization root disappear at the same time, have Mutagen pause the session until the user confirms that this was intentional.  This is a bit of a delicate balance, because on the one hand you don't want to trigger it too often (people do delete files, after all), but on the other hand you don't want inadvertent mass deletions to propagate.
What about extending the existing safety check so that if the synchronization root moves from having some contents to no contents, the session is also halted?  That would cover the case that you experienced I think.  This would be a quick fix to implement until one-way sync can be added.
Obviously one-way sync would also solve this problem, and that's probably something that's going to have to be prioritized.  It makes even more sense in the Docker world, where you generally want to use Docker containers as slave replicas for the code you're developing.
Regarding the agent bundle, that's probably going to be part of Mutagen indefinitely, because it's what facilitates its one-side-only install.  But there are plans to build an official Mutagen Docker image that will have the agent as an entry point and thus negate the need to copy agents into it.  If you're only using that mechanism, then you can avoid the need to carry around the agent bundle since Mutagen will know that it doesn't need agent binaries in that case.
Per-project mutagen.toml++ - acknowledged!

I expected it might remove the host files after I removed the docker volume, so it was no trouble at all. You assumption were also correct. I synced the volume mount point itself so when syncing started again the root was there but empty.
I am not sure heuristics are a better idea as it would probably introduce even more confusion. On the other hand, syncing a complete deletion of the entire root is probably more likely to be a bad user manipulation than something that was intended to be replicated on the remote.
I totally understand that agent bundle will always be part of the distribution. But it would be a small development experience improvement if I the main binary could work without it.
Lastly, there is a couple of project in this space. With the agent design (that we might not need for docker, but is super neat everywhere else), the speed and current feature set, I think mutagen will go places. Keep it up. You got an awesome project.

I have been playing a bit more with mutagen and docker.
I have changed workflow a bit. The dedicated volume volume became a bit cumbersome.
Now I am using COPY a image build  time to copy the current state in the app container and am attempting to use mutagen to sync later edits. In that case, the docker cp method with the agents is extremely handy. However, I have two significant friction points:
1- I can't mutagen create if the docker container is not up, but it can reattach if the docker is restarted. I have the impression that if it can recover from a restart, it could be set up while container is down and just attach later.
2- The conflict resolution is incompatible with this workflow. All is fine the first time after the initial COPY on build. But if I make some change and restart the container, the container files will be reverted to the build state and I will always get unresolvable conflicts or my host will be reverted.

@Jarzebowsky After some research, I think ConEmu (which Cmder users) may have been the issue, but the good news is that it should be fixed in an upcoming Docker release.  It looks like there was a check for ConEmu environment variables in Docker that was causing some issues (see moby/moby#28814 and Maximus5/ConEmu#958), and it was fixed in moby/moby#37600.  This was fixed in early August, so it hasn't made it to a tagged Docker release just yet.  I don't know what their release cycle looks like, but I imagine that it will be out in the near future.  Until then, using PowerShell, cmd.exe or mintty is probably your best option.
Internally, what happened was that the Mutagen daemon inherited the environment variables from Cmder, which made any process it launched inherit them, causing the failure.  I've been thinking about making Mutagen strip out all environment variables from the daemon's environment, but this is more complicated than it sounds, especially on Windows.  There are a number of environment variables that are required, and it would require a lot of research to come up with an appropriate list.  Since this issue will be solved by Docker soon anyway, I'm going to punt on that idea for now.

@jpambrun Thanks for your additional feedback.
Regarding 1, I think the answer is to add some mechanism to better align Mutagen session lifetime with the lifetime of containers.  I have some ideas about doing this, and @matthew-gill put together this project to do something similar.  I think this is just going to take some iteration on my end.
Regarding 2, that also feeds into design decisions about unidirectional sync a bit more.  Perhaps it even makes sense to have an option that starts unidirectional and then switches to bidirectional.  I'll also need to play with this design.  I'll CC you for your thoughts once I've written up a proposal.
In general, what became cumbersome with the volume + dedicated "sync" container approach?  Is it a friction point that could be resolved?  Maybe with a "prepackaged" Mutagen Docker image?

On a Linux host, before trying mutagen/unison, I had my source mapped to a read-only volume. That source volume was mounted as the lower of a overlayFS within the docker container. The top was a RW mounted docker volume (called build-artefacts). As a result, the source was read from host through the mounted RO lower volume and all built stuff was trapped into the upper build-artefacts docker volume. When I wanted to clean I would just docker volume rm build-artefacts. My local host folder would never get littered with  built stuff. Unfortunately, that didn't work at all on MacOS/Windows.
What was nice about that is that the source would be available as soon as the container would launch. My first attempt at syncing with external tools was to mimic the samba RO volume setup, but the code is not available at container launch; it needs to be copied first. I don't really have a good solution for that. Ideally, I want other devs to be able to just docker-compose up (or docker-compose build && docker-compose up if I have no choice)to be up and running on any platform.
Now I am trying to copy the source at image build time and update with unison (for now.. ideally mutagen..) every time the container spun up. However, as more commits are made, the delta from the build-time source and the current source will increase. I could use start/stop instead of up/down, but that will probably only delay the issue.
Sorry for the deorganized comment.. the tl;dr is that I still didn't find a good workflow.. Am open to any suggestions..

@jpambrun I'm trying to work out a good workflow for docker and mutagen.
I'd suggest never baking source code into your docker image.
The best way I've found is to use docker compose. Create a volume for your code, also create persistent volumes for your third party dependencies.
My workflow is as follows:
One time
Create persistent docker volumes
docker-compose up
Start mutagen sync (excluding git and any third party dependencies). Once initial sync has completed, I enter my container and download third party dependencies (vendor, node_modules etc)
I can then start developing
Once finished developing I run
docker-compose down -v
This deletes the code from my container but persists my third party dependencies
Development in general
docker-compose up
Mutagen sync start
Wait for files to sync
Do my development
docker-compose down -v
My project https://github.com/matthew-gill/mutagen-stack helps to wrap the development in general part of this comment into these two commands:
./mutagen-stack start
./mutagen-stack stop --clean
Hopefully that makes sense!

@jpambrun A non-daemon mode makes sense for a lot of applications, but it would take some architectural refactoring to make it a reality.  My aim is to have a GUI in the near future for monitoring Mutagen sessions, which is one of the main reasons for routing sessions through a daemon (so that you can monitor all synchronization sessions in one place), but I see the value in a "standalone" use case.  One approach I've considered is something like a --temporary flag to mutagen create that would cause the command to block while the session is alive, and the session to be automatically terminated once the command is terminated.  That would "look" the same behaviorally to users as your proposal, though it would still route via the daemon and allow for GUI monitoring.
Can you elaborate a bit on the Windows host executable permissions problem?  Issue #33 is more about allowing for different base permissions or extending POSIX-to-POSIX permission transfers - I'm not sure there's going to be much action there on the Windows side.  Windows executable permissions don't really map well conceptually to POSIX executable bits, and they aren't generally used directly by users.  Mutagen currently ignores them, but should correctly preserve executability bits on a POSIX endpoint when syncing back and forth with Windows, even when the file with executable permissions is edited on the Windows side.  Can you give me more details about the Windows permissions that you're trying to propagate?

Is the workflow described by @divoxx in this comment currently possible? That is, syncing from a host (of any platform) into a named Docker volume?

@eysi09 Yes and no.  It's not currently possible to use the Mutagen agent as the ENTRYPOINT for a container as described in that comment, but it is possible to create a Docker container dedicated to synchronization (with some sort of no-op ENTRYPOINT, e.g. top -d1000), attach the named volume to that container, and then synchronize into the volume via that container using Mutagen.  I'm hoping to release a dedicated Mutagen Docker image in the near future (hopefully in the next 1-2 weeks) that will have the agent as its entry point and allow to turnkey synchronization into a named volume.

@havoc-io that's what we've been doing too. We have a tail -f /dev/null as a no-op command for the entrypoint and then we inject the agents inside the container.
The only real limiting issues we have are the weird CPU spikes, which sometimes causes the container to become unresponsive, and the conflicts when pulling changes from git while the agent is not running.
If those two are addressed, I think mutagen will be a great tool to use in these scenarios.

@divoxx Thanks for the follow-up.
I'll try to take a look at the CPU spikes tomorrow - I've finally got my MacBook Pro back from repair, so I should be able to run Docker for Mac.
Additional conflict resolutions are also on the docket for this week.
I appreciate your perseverance in the mean time!  The feedback is helpful.

Using: 0.8.0-beta3
I gave it a try with my project and at first it went really fine. Sync was working. Pretty awesome by the way 👍 .
But then my Macbook shutdown as it ran out of battery. After charging and starting all up again suddenly the sync could not connect to beta anymore.  Here is what I did:

Start Macbook
mutagen daemon start
mutagen list showed my project with status "Connecting to beta..."
Started my docker containers with docker-compose up -d
Expected to see mutagen connecting and syncing instead nothing happened, it still showed "Connecting..."
Did a mutagen terminate with the intention to recreate that sync
mutagen create /my/folder/... docker://container_name/path/inside/container gave me

Connecting to agent (POSIX)...
Error: create failed: unable to connect to beta: unable to connect to endpoint: unable to create agent command: unable to probe container: container probing failed under POSIX hypothesis (exec: "docker": executable file not found in $PATH) and Windows hypothesis (exec: "docker": executable file not found in $PATH)

Nothing really changed, same terminal, docker command is in the PATH, same container name, etc.
Tried a few of the commands you suggested to @Jarzebowsky earlier and all seemed to work.
Running out of ideas unfortunately.

Hey @derschatta, sounds like the Mutagen daemon can't find the docker executable.  This is also the issue at the heart of #67, which I'll aim to fix ASAP.  That may be what's going on here.  Did you use mutagen daemon register by any chance?  If so, the daemon that launches on restart will be started by launchd, which strips out all path information (the aforementioned #67).  If so, then just do mutagen daemon stop, mutagen daemon unregister, and then redo mutagen daemon start with the path to the docker binary in your PATH.
Otherwise, if you run which docker, does it print /usr/local/bin/docker?  If it prints some other path, e.g. /some/path/to/bin/docker, can you ensure that /some/path/to/bin is in your PATH environment variable when you run mutagen daemon start?
Let me know if that helps.

Thanks @havoc-io stopping, unregistering and starting the daemon helped. 👍

@derschatta Cool, sounds like maybe the same issue as #67 then.  I'll see if I can add a quick patch before the final v0.8.0 release tomorrow.

Pretty good job by the way! 😄  👍
I was using docker-sync and was having a lot of problems with it. Syncing always stopped at some point and could only be brought back by restarting the whole thing. It seems mutagen could just replace docker-sync for me hopefully working faster and more stable. The usage is really straight forward and the docker integration is absolutely great.

@derschatta Issue #67 should be fixed in v0.8.0, so you can now do mutagen daemon stop, mutagen daemon register, and then mutagen daemon start to get automatic restarts on reboot without running into this issue on macOS.

Thanks @havoc-io. Works 👍

For now, mutagen seems to work well as a docker-sync replacement. Especially when looking at used resources.
As a newbie to this project, i could point a few things that could improve:

documentation does not say explicitly that session can be created without passing user
mutagen does not provide any command which starts the sync, waits for first full sync and then exits. This makes it complicated to integrate with any Makefile or other scripts which simplifies running some actions (eg. starting dockers, starting sync, running some command in the container).
there is no way to specify sync mode in mutagen create, in opposition to what documentation says

Hey @adiq, thanks for the input.

documentation does not say explicitly that session can be created without passing user

The Docker documentation (even the outdated one) includes the following:

The user component is optional and tells Mutagen to act as the specified user inside the container. If unspecified, Mutagen uses the default container user (usually root for Linux containers or ContainerAdministrator for Windows containers).

I'm not really sure if there's a clearer way to state this.

mutagen does not provide any command which starts the sync, waits for first full sync and then exits. This makes it complicated to integrate with any Makefile or other scripts which simplifies running some actions (eg. starting dockers, starting sync, running some command in the container).

This can be emulated by creating a session using the no-watch file synchronization mode and then using the mutagen flush command to manually invoke synchronization cycles.  This should hopefully become a bit easier with the scripting improvements outlined in #43.

there is no information in the documentation in which version certain things was introduced

I'm not sure I plan to track this at the moment.  Maybe once Mutagen hits v1.0 and starts being packaged it would make more sense, but for now only the most recent version is really supported and thus the documentation assumes that's what you're using.  A lot of new stuff was introduced with v0.8.0.  I'm still in the process of upgrading and migrating the documentation, but hopefully that'll be done today.  The best resource right now is the website-based documentation and not the repo-based documentation.
Regarding your previous question about synchronization modes, more information is available here.

@havoc-io that was my 5 cents; hope it helps somehow. I am really happy that you guys decided to introduce docker support and save everyone using docker 4 mac 😄
Regarding the user in docs, it's there. And it's clear. I must have mistaken this with other page. I am certain I saw somewhere docker://user@container/path without the brackets, can't remember where tho.
I also get why you don't want to keep a strict changelog, as things are moving forward quickly. Just a thing that you should keep in mind for the future.
Regarding the scripting... nice solution with the no-watch and flush. It will do the job for now. But think this would still be valuable for users to have some flag on either create or monitor to make it simpler.

@adiq

Regarding the user in docs, it's there. And it's clear. I must have mistaken this with other page.

This is definitely my fault - the docs are in a slight state of disarray at the moment due to the refactor of the website, and it's not clear what's the definitive location.  The website should be considered the canonical source, but it's definitely easy to get lost in the different docs at the moment.
There's also still a lot of editing to be done on the website docs as well.  For example, that particular line could be done as a little highlighted "extra information" callout or something.  I'll definitely work on it.

I also get why you don't want to keep a strict changelog, as things are moving forward quickly. Just a thing that you should keep in mind for the future.

A change log is doable, and certainly it's good policy to track such things.  For now all of the changes are archived in the associated release notes, so later we can go back and consolidate everything. Adding something like annotations in the notes (e.g. something like "mutagen command-name is available in Mutagen vX.Y.Z+")... that's more of a manpower issue (right now I'm just short on time).  It's also less of a priority for the time being since Mutagen isn't packaged into repositories (where someone might be "stuck" on some earlier version of Mutagen and need to know which features are available).

Regarding the scripting... nice solution with the no-watch and flush. It will do the job for now. But I think this would still be valuable for users to have some flag on either create or monitor to make it simpler.

Cool, let me know.  That's all new in v0.8.0, so it's not 100% clear how it will integrate with workflows.  Please feel free to open a feedback issue.  Once we figure that out, we can write up some "best practices" or "recommended workflows" docs to elaborate on what works well and what doesn't.
I've considered more ephemeral "one-shot" sessions in the past, maybe similar to running rsync but with the extra synchronization modes and options available.  The biggest issue is that Mutagen has to track most-recent-ancestor information for synchronization sessions to be able to effectively do any sort of automatic conflict resolution.  But if the only loss is automatic conflict resolution, then there might still be quite a bit of value to be had.  I guess the other issue is that this ancestor information is also used for differential transfers of the filesystem snapshots, so a "one-shot" session might be a little slower (though for local Docker daemons it'd be inconsequential).

@havoc-io  "I'm hoping to release a dedicated Mutagen Docker image in the near future that will have the agent as its entry point and allow to turnkey synchronization into a named volume."
Have you had a chance to make a docker image for a default sync container? working with lando and mutagen. thanks, just checking


Access colors in XAML

How can I access the color resources in XAML?
I tried adding the XF.Material library as a xmlns like this:
xmlns:material="clr-namespace:XF.Material.Forms.Resources;assembly=XF.Material.Forms"
But I can't seem to get the color properties that is in XF.Material.Forms.Material.Color.Primary.
I'm guessing I'm using XAML wrong, thanks for any help.

You can access them using the DynamicResource extension in XAML.
Like this:
<Button BackgroundColor="{DynamicResource Material.Color.Primary}"
        Text="Click Me!" />

Thanks!


[Languages] Unirest, JSONNode, JSONObject: The best way to consume external resources in Java

Topic Suggestion
[Languages] Unirest, JsonNode, JSONObject: The best way to consume external resources in Java
Proposal Submission
Proposed title of article
[Languages] Unirest, JsonNode, JSONObject: The best way to consume external resources in Java
Use keyword research to improve your article's SEO.
Proposed article introduction
It is not enough to consume API's (endpoints from APIs); you need a reliable client to do this and an amazing mechanism to cut into the eventual response, make sense of it and make out your own response. Ideally, you are not suppose to just pass the response from the external service to your own service's frontend or requesting client. What is ideal is to make sense of what has been generated and create yours thereby.
In this tutorial, using a small API consumption project, we will interact with an external service using the Unirest HTTP Client, see the response and build out our own response from it. So basically this article will teach three-fold process - consume an API, make sense of the response and build a custom response from it, by using a custom-made APIResponse class
ONLY viable topics to pick from:

API
Artificial Intelligence
Blockchain
Containers
Edge Computing
Languages
Machine Learning
Networking
Node.js
Security

Key takeaways
At the end; you should:

understand HTTP Clients and what they do
know how to use the Unirest client
know how to work with JsonNode
know how to work with JsonObject

Article quality
How is your article unique? Tell us what makes your approach different from similar articles that have published on the same topic?
Is yours more in-depth? Does it cover additional topics? Do you provide handy tips or anecdotal advice?
Yes my article is unique. This is because it combines the action of one of the major HTTP Clients with the reliable workings of two JSON libraries in Java, to fix API calls and eventual responses.
References

http://kong.github.io/unirest-java/#requests

Please fill in the Article Quality section so we can review your article.

@louisefindlay23 I have done as you have said. Thank you for your comment. Looking forward to hearing

@afropolardev
Closing due to inactivity - if you'd like to continue working on the topic. Please let us know.


[BUG]: drizzle-zod doesn't respect .json().$type<>()

What version of drizzle-orm are you using?
0.33.0
What version of drizzle-kit are you using?
0.24.2
Describe the Bug
When I create a JSON field like this field1: json('field1').$type<string[]>().notNull().default([]) and create a Zod schema from that table with createInsertSchema(), I get errors on data types when I parse the schema into params from a request to insert it with Drizzle.
Example:
const someTable = pgTable('someTable', {
  field1: json('field1').$type<string[]>().notNull().default([]),
  // createdAt, updatedAt ...
})

const someThingSchema = createInsertSchema(someTable)
  .omit({ createdAt: true, updatedAt: true })
  .partial()

/// ..

const params = someThingSchema.parse(await request.json())
const [item] = await drizzleDbInstance.insert(someTable).values(params).returning()`

I get typing errors which breaks the build and I have to manually cast the proper type inferred from the table schema again.
And same happens with custom types as well. Removing .partial() doesn't really affect the result.
...
      Types of property 'field1' are incompatible.
        Type 'Json | undefined' is not assignable to type 'string[] | SQL<unknown> | Placeholder<string, any> | undefined'.
          Type 'null' is not assignable to type 'string[] | SQL<unknown> | Placeholder<string, any> | undefined'.

Expected behavior
I expect JSON data types are properly inferred from the schema definition.
Maybe I misuse something? I suppose there should also be something like createUpdateSchema maybe?
Environment & setup
"drizzle-zod": "0.5.1".

You can use the second parameter refine of createInsertSchema function to specify your json structure once.
Something like createInsertSchema(someTable, { field1: z.array(z.string()) })
Hope this helps!

You can use the second parameter refine of createInsertSchema function to specify your json structure once.
Something like createInsertSchema(someTable, { field1: z.array(z.string()) })
Hope this helps!

Thanks, but it doesn't help. I don't wanna specify same schema twice. The whole purpose of this is to generate Zod schema from the actual table schema, which is defined in a single place and all changes later are done in a one place as well without duplicating them for validation.

It's basically impossible to infer a schema from the $type method since the method only makes changes to the column at the type level and not at runtime. However, I have thought about this and I propose a solution to this: #3565.


[WIP] Fix #463 - Part 1 - Model editor/split size in the WindowTree

There isn't a way to resize windows today, which is a blocker - #463
This is the beginning of implement sizing in the WindowTree.
TODO:

[x] Generalize distribution of height / width across the children
[ ] Implement actual measure function for the children
[ ] Add test case for setting split size
[ ] Add test case for setting parent size
[ ] Add test case that parent 'inherits' split's size when adding a split that changes direction

Next steps:

Add an id to Parent so it can be targeted by resize. Add logic that, given an id + a resize operation, we'll resize the correct entity (either a split or parent).
Wire up the Vim commands for resizing splits
Implement UX via the mouse for this as well (ie, add a mouse capture handler to <WindowHandle />, and dispatch appropriate resize commands in response)
Implement sizing for the pane
Implement hiding / showing the activity bar with the mouse

Obsoleted by #1646


Document limitations about our self-generated certs

Currently our root CA and the internal certs generated by it have a lifetime of 10 years. We are not doing rotation of these resources yet.
We should update our docs to:

make users aware of this temporary limitation
explain how to force the creation of the certs/root CA. We can use the instructions provided inside of the blog post of 1.14

Hi @flavio and/or @jvanz . Regarding this. The instructions in the blog post seem ok. They can be expanded with an example. My question though is where to put this information in the docs?
As a developer using Kubewarden, where would you expect to see this workaround documented?
In the Howtos? The Secure Supply Chain Section? Somewhere in the 'Configuring policy servers' Howto.
WDYT?

What about adding a new sidebar item: "Howtos/Limitations"?

As we have some sort of cert-manager integration - I guess we should add the info on how to use cert-manager for this purpose as well?

I like @flavio 's idea of a new section to keep stuff like this separate. I think I want to call it 'Howtos/Work-arounds' though. It's a minor point. It;s how to work round a current limitation. If we called it limitations I think it would fit better under Explanations, but as in it we are going to explain how to work around something ...... Hmmm? Anyway, for the moment I'm going with work-arounds.

@jhkrug is this complete with https://github.com/kubewarden/docs/pull/423?

I would say so. Closing as fixed


Generate new features by crossing features in a table?

Feature crossing is a very common technique to find the nonlinear relationships in the dataset.
Can I use featuretool to generate new features by crossing features in a table? And How?

Issues created here on Github are for bugs or feature requests. For usage questions and questions about errors, please ask on Stack Overflow with the featuretools tag. Check the documentation for further guidance on where to ask your question.

Hi @hibayesian,
Thanks for the interesting question! I’m closing this issue as it’s not a bug or feature request, but feel free to ask this on Stack Overflow for a detailed answer.


any bug in ndt_cuda?

Dear @koide3 , and all
I tried to utilize ndt_cuda on fast_gicp package.
However, there is no update transformation when I call "align" function.
(It just follows initial value as "align" function's second argument)
I tracked the code and found "linearize" fucntion just output "0" matrices(H & b).
("linearize" fucntion is called in "step_lm" function at lsq_registration_impl.hpp)
Can I resolve the problem or do you have any solution for ndt with cuda?
Thanks.

Honestly, ndt_cuda might be buggy and unstable because it was written in one day without comprehensive tests. I'm considering to implement a new one in small_gicp.


8749 Add ts to js sdk

Description of change
Ts added
Not tested in playground
Checklist

[ ] Tested in playground or other setup
[ ] Screenshot (Grafana) from playground added to PR for 15+ minute run
[ ] Documentation is changed or added
[ ] Tests and/or benchmarks are included
[ ] Breaking changes

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Katarzyna Ziomek-Zdanowicz seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


pombe S. cerevisiae ortholog table V23

I still make this manually and  the contents on the website has drifted  quite a bit from the download file.
I created a new version of the download file  (V23) in the orthologs directory. Could this be put into the downloads directory and the old file archived?
Thanks,

So replace the cerevisiae-orthologs.txt file here?:
ftp://ftp.pombase.org/pombe/orthologs/

yep.
I only noticed because I was trying to balance the numbers for my thesis... I haven't been updating it. Still need to automate this part...next time...

OK, thanks.  I've checked in the change and it should be on the FTP site in the morning.

it should be on the FTP site in the morning.

It's there now.


Old docker compose yml reference documentation link redirects to localhost

Problem description
I sometimes go to documentation by using my history. When I did that for the docker compose yml reference it suggested the https://docs.docker.com/v1.8/compose/yml/ URL. When I visited this I was redirected to http://localhost/compose/compose-file/
The most up to date URL is https://docs.docker.com/compose/compose-file/ so it looks like whatever service generates the redirect isn't resolving the hostname to use correctly.
Problem location

I saw a problem on the following URL: https://docs.docker.com/v1.8/compose/yml/

Suggestions for a fix
➜ curl https://docs.docker.com/v1.8/compose/yml/
<!DOCTYPE html><link rel="canonical" href="http://localhost/compose/compose-file/"/><meta http-equiv="content-type" content="text/html; charset=utf-8" /><meta http-equiv="refresh" content="0;url=http://localhost/compose/compose-file/" />

The redirect is being done using a meta refresh. I can't easily see what is generating that.
When I look at pages that have not been renamed (e.g. overview, gettingstarted) they work fine and link to the old documentation:
https://docs.docker.com/v1.8/compose/
https://docs.docker.com/v1.8/compose/gettingstarted/
The updated name even works:
https://docs.docker.com/v1.8/compose/compose-file/
I would suggest that this is a problem with whatever is handling renamed pages.
Check whatever generates this redirect page? It could be receiving proxied requests and taking the hostname from that.
Check your nginx configuration? It could generate a 301 redirect instead of using meta refresh.
Is this related to the version in the URL? The https://docs.docker.com/compose/yml/ URL without the version number goes to the "sorry 404" page so it may be something related to the specific /v1.8/ path.

@mstanleyjones @johndmulhausen  can we look at this together tomorrow?

@londoncalling I am fixing this in #2788. It is just a typo.

Closed via #2788


ELI5 no longer available, but referenced in example code

Here, an example code is given:
https://huggingface.co/docs/transformers/tasks/language_modeling
This code + article references the ELI5 dataset.
ELI5 is no longer available, as the ELI5 dataset page states: https://huggingface.co/datasets/eli5
"Defunct: Dataset "eli5" is defunct and no longer accessible due to unavailability of the source data.
Reddit recently changed the terms of access to its API, making the source data for this dataset unavailable.
"
Please change the example code to use a different dataset.

Addressed in https://github.com/huggingface/transformers/pull/28715.


Add Vagrant Box for testing USB Gadgets in loopback with dummy_hcd

Not everybody has a USB Gadget capable Linux computer on hand nor is it
always desirable to develop and test directly on "target" devices.
This Vagrant box provides a reproducible development environment with
USB Gadget Loopback support provided by dummy_hcd.
Unfortunately, dummy_hcd is not compiled by default in Ubuntu/Debian,
even in their "extra" package. We must compile and install it ourselves.
This Vagrant box tries to ease that process and make it easily
reproducible.
The vagrant box also contains Rust, so code in this repository can be
built, tested, and run.

Thanks for the PR!


Can you provide a span with class="notranslate" ? Because Google does not translate if you format a text using this class. This will be unique to SUNEDITOR.

Can you provide a span with class="notranslate" ? Because Google does not translate if you format a text using this class. This will be unique to SUNEDITOR.
see here--
https://stackoverflow.com/questions/9628507/how-can-i-tell-google-translate-to-not-translate-a-section-of-a-website#:~:text=164-,According,-to Google instructions
You can suggest some workaround till u provide this feature

The 2.43.0 version has been updated.
If this issue has not been resolved, please reopen this issue.
Thank you.

I misunderstood the issue.
This issue can be solved with a custom plugin.
http://suneditor.com/sample/html/customPlugins.html#command
action: function () {
        if (!this.util.hasClass(this.context.customCommand_2.targetButton, 'active')) {
            const newNode = this.util.createElement('span');
            newNode.className = 'notranslate';
            this.nodeChange(newNode, ['.notranslate'], null, null);
        } else {
            this.nodeChange(null, ['.notranslate'], ['span'], true);
        }
    }


Invalid analyzer error for forwarding generative constructor.

Example:
class Super{
  factory Super() = Super._;
  const Super._();
}
class Sub extends Super {
  const Sub.name() : this._();
  const Sub._() : super._();
}

The analyzer gives an error on the Sub.name() constructor (master branch in DartPad, found locally on tip-of-tree):

error
line 6 • A constant constructor can't call a non-constant super constructor of 'Super'.(view docs)
Try calling a constant constructor in the superclass, or removing the keyword 'const' from the constructor.

The CFE shows no issues.
If I comment out the factory constructor Super(), the problem goes away.
If I add const to the Super() constructor, the problem goes away.
If I remove const from Sub.name(), the problem goes away.
It makes no difference whether Sub.name is named or unnamed.
In none of the cases does the Sub.name() constructor call, or depend on, the Super() constructor, so the analyzer seems to be creating a spurious connection between a constant redirecting generative constructor the unnamed constructor of the superclass, if it has an unnamed constructor, and requires the superclass constructor to be constant. If there is no unnamed superclass constructor, that's not a problem.

@scheglov

https://dart-review.googlesource.com/c/sdk/+/324262


jQuery UI 'helper' option set to 'clone' still move the content to drop object, instead of copying

@brunomperes: Yes, helper option is only specific to jQueryUI. If you want to keep the copy of the dragged item where it was already, use placeholder: 'keep' option in the DOM as:


X or back after clicking into a route or contracting a timeline view is broken

It's just grey'd out.

I don't notice this. Which browser and is this still an issue?

Looks like it's working now.


first party caveats are not always checked by verifier

As far as I can tell, the following script should print:
 checked conditions: ['splendid', 'wonderful', 'top of the world']

but it actually prints:
checked conditions: ['top of the world', 'wonderful']

One first party caveat does not appear to be checked.
import macaroons
m1 = macaroons.create("", "root-key", "root-id")
m1 = m1.add_first_party_caveat("wonderful")
m1 = m1.add_third_party_caveat("bob", "bob-caveat-root-key", "bob-is-great")

m2 = macaroons.create("bob", "bob-caveat-root-key", "bob-is-great")
m2 = m2.add_first_party_caveat("splendid")

m3 = macaroons.create("bob", "bob-caveat-root-key", "bob-is-great")
m3 = m3.add_first_party_caveat("top of the world")

m2 = m1.prepare_for_request(m2)
m3 = m1.prepare_for_request(m3)
checked = []
def check(cond):
	checked.append(cond)
	return True
v = macaroons.Verifier()
v.satisfy_general(check)
v.verify(m1, "root-key", [m2, m3])
checked.sort()
print('checked conditions: {}'.format(checked))

Absent a sort issue ('w' after 't'), you're right.  Good catch!
I pushed a potential fix, and I'd appreciate your comments on whether I got the extent of the problem accurately characterized in the commit message.  I see potential false negative and timing channels.  Is there anything else I missed?

Oops, I hadn't caught the fact that there were two discharge macaroons with the same id (really, my test name ("single third party caveat with two discharges") should've tipped me off, but it was late in the day...)
On further reflection, I'm not sure that my expectations in the test were correct, although I'm not sure either that the verification should have succeeded.
My current thinking is before any caveat checking takes place, the macaroon signature should be verified and also that the verifier should check that each discharge macaroon is used exactly once.
Checking that each discharge is used exactly once serves two purposes: it makes it trivial to check for recursive discharge use (a use count array could replace the tree array used by macaroon_verify_inner, I think, which would make the code a little simpler, I think) and it means that the caller can be sure that all the first party caveats present in the macaroons have been checked (not true currently, even with that latest fix for this issue), which is useful intuitively when inspecting macaroons (it caught me out) and potentially for inferring information from caveat checks too.
I'm that first party caveat checking needs to be done when the signature is invalid, because first party caveat checking is potentially expensive (think online revocation checks), and we probably don't want attackers to be able to invoke arbitrary first party caveat checks with no valid macaroon at all. I guess the question there is: is there some way that an attacker could make use of the information that a macaroon is potentially valid even when its caveats fail?
So I'd suggest doing all the signature  and use-count checking and then checking all the first party caveats.
So with respect to this test, I'm not sure that the fix is quite right - your code was actually correct according to the specification in the paper (which only requires that there exists at least one discharge macaroon that can be used for discharge).
What do you think?

I think the code change I made is for the better, even if it's not the issue you were pointing out. It allows one to do more complex proof trees without having to do client-side interpretation of which macaroons to pass along.  It's totally valid for a discharge macaroon to be used multiple times, and we shouldn't exclude this behavior.
As for invoking caveat checks, an attacker who intercepts a macaroon can always add a caveat that passes the signature check.  So it's only totally bogus macaroons that would be at risk for servers to invoke caveat verifiers without a valid signature.
Can you elaborate on the inspection point?

BTW I'd misread your code - I'd skim read it and assumed it was checking that all discharges were valid, but it's actually checking that at least one discharge is valid.

It's totally valid for a discharge macaroon to be used multiple times, and we shouldn't exclude this behavior.

Can you elaborate on a situation where this might be appropriate?

As for invoking caveat checks, an attacker who intercepts a macaroon can always add a caveat that passes the signature check.

That depends on when they intercept it. If they intercept it as part of the request, that's not the case (all discharge macaroons are bound to the primary's signature at that point, so no new caveats can be added). If an attacker has stolen an undischarged macaroon along with its discharges, you've got a serious security problem - I don't think we can guard against that in the macaroon library.

So it's only totally bogus macaroons that would be at risk for servers to invoke caveat verifiers without a valid signature.

Everyone in the world can make a bogus macaroon. Only attackers that have stolen your bearer credentials can obtain a valid unbound macaroon with its discharges. There's a big difference in potential attacker count there.

Can you elaborate on the inspection point?

It's not uncommon to inspect first party caveats to infer some information about the security properties of the macaroon. A common one, for example, is to infer the expiration date of the macaroon from the first party caveat that specifies the earliest expiration time (we use that for macaroon garbage collection). It's nice if this inferred information is accurate.
Manual inspection is also not uncommon - it's a nice property to be able to see a set of macaroons that have been used to authorize a request  (for example in a server log) and be sure that all the listed caveats have succeeded.


[bundler] Implement top-level await bundling preset in project generator

https://babeljs.io/docs/en/babel-plugin-syntax-top-level-await

Top level await expressions would require bunder configs + linter configs + internal implementations, for now, it is not worth


Issue with alias for azurepolicy.json

For azurepolicy.json, I'm getting the following error when I try and build a custom policy:
The 'field' property 'Microsoft.Sql/publicNetworkAccess' of the policy rule does not exist as an alias under provider 'Microsoft.Sql'.

I modified the The 'field' property 'Microsoft.Sql/publicNetworkAccess' of the policy to the following and then I was able to save the policy
"existenceCondition": {
"field": "Microsoft.Sql/servers/publicNetworkAccess",
"equals": "Disabled"


[nrf toup] cmake: Align with renaming kernel_elf to zephyr_final

Upstream changed the name of 'kernel_elf' to 'zephyr_final', in this
commit we do the same renaming.
Signed-off-by: Sebastian Bøe<EMAIL_ADDRESS>

Must be applied at the same time as https://github.com/NordicPlayground/fw-nrfconnect-zephyr/pull/147