test: Just a test pull request

This is just a test pull request, to check if the my modified CI is used, and works.
This will NOT be merged

Codecov Report

Merging #63 (d302bd2) into master (ff3b34a) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##           master      #63   +/-   ##
=======================================
  Coverage   43.83%   43.83%
=======================================
  Files          20       20
  Lines         924      924
=======================================
  Hits          405      405
  Misses        519      519

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


SfProductCard is not clickable with link provided

on category's product listing when the link property is provided the product tile is not clickable at all. only clickable part of this is an "add to wishlist hearted link" on the top.

@leomp12 apart from the fact it's not working what was the intuition behind adding this prop? Shouldn't it be handled just by wrapping component in router-link ?

@mkucmus I'll check it, I think it was working but probably I've tested only without wishlist icon, maybe we have a bug with both together...
@filrak wraping it you would overlap wishlist icon click event, and price would also be linked, I think it's not good.
With the prop we're linking only image and title.
And I don't think it should render a router-link by default, it's context specific, by doing that we're setting sfui dependent of vue-router unnecessarily..

@leomp12 default config should work for most of the users and router-link is what most of the users will use. I agree that it shouldn't be hardcoded though so as we discussed on Discord lets have linkTag property defaulting to router-link

I'll also accept Object on link, maybe we can just use router-link if link is an object (such as { name: 'cart' } or { path: '/cart' }), wdyt?
Then we don't need linkTag prop, renders <a> when link is string and router-link when it's an object.

I usually use vue router like that, but honestly I don't know if it's the most common too..

i think it's easier to get it with explicit props. Regarding most common approach I often use Vue Router with just strings but same as you i'm not sure if it's most common way. If we don't know that we should aim for the simplest solution which is probably to have bare props.
@mkucmus @patzick wdyt? :)

On PR I'm adding linkTag prop, but I'm also checking for this.$router, if not present (Vue Router not used on instance) and this.link is a string I'm rendering <a>, otherwise I'm rendering <router-link> by default.


merge Release 2.13 branch into master

@bwplotka , @simonpasquier @brancz @brian-brazil @juliusv @SuperQ @codesome @csmarchbanks

superseded by https://github.com/prometheus/prometheus/pull/6117


Add mdformat plugins

Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.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

[ ] Fits CONTRIBUTING.md.

Previous related PRs:

https://github.com/NixOS/nixpkgs/pull/234916
https://github.com/NixOS/nixpkgs/pull/198094
https://github.com/NixOS/nixpkgs/pull/198095
https://github.com/NixOS/nixpkgs/pull/198096
https://github.com/NixOS/nixpkgs/pull/198098

I'm fixing this mess in https://github.com/NixOS/nixpkgs/pull/287103.

Any reason you use buildInputs rather than propagatedBuildInputs? See #287074.

At the time, I was learning how to package Python apps properly. So basically mistakes on my part.

Why are the commit messages not prefixed with python311Packages.?

I was not aware, again, at that time.


[BUG] Tables alignment mismatch present across all tables in the explorer

Columns in all the tables like UserOp, Paymasters, Bundlers are not properly aligned

can i work on this issue

can i work on this issue

Yes go for it!

okay i will get back to you once its done

Done, I have raised a pull request #174. Please review it


also can not use it

hi, i still can not to use it ,i have already uninstall again or create a new environment,but they just write about
Collecting package metadata (current_repodata.json): failed
UnavailableInvalidChannel: The channel is not accessible or is invalid.
channel name: f
channel url: https://conda.anaconda.org/f
error code: 404
You will need to adjust your conda configuration to proceed.
Use conda config --show channels to view your configuration's current state,
and use conda config --show-sources to view config file locations.

Hey @yuancc12, please follow the instructions posted bu our bot in the other issues you have opened today. Thanks.


Display disk usage bar chart for multiple disks

Changes:

create chart labels from valid 'datum' object. It's now passed as a
nested object.
use constant offsetX=0 for bar chart. Before it was calculated based
on longest  disk 'path' which caused the chart to be moved out of
the view for long paths.
add disk 'path' to tooltip. It's too long to be displayed on X axis.
display used or available disk inside tooltip depending on mouse
pointer location. Before, if usage was 100% the tooltip was missing.

Problem re-created

Effect of long path (chart is out of view)

Fixed

@sjd78 I was able to put the tooltip at the top of the bar. However it's still placed at the end of the bar. I've found no way to change this position (other the hard-coded offsets)

Note: There is a problem with disk's thresholds colors - they are incorrect and colored in red for 23% usage.
It seems that the following lines still use old percentage values (e.g. 140%) instead of the correct ones:
https://github.com/oVirt/ovirt-web-ui/blob/5d059762b8f55ef1a7a9db6b0e113286ba9aaed6/src/components/VmDetails/cards/UtilizationCard/UtilizationCharts/BarChart.js#L35-L39

This is a fix outside the scope of this PR.  I opened #1556 to cover the bar chart colors.

But this can be easily fix

Sure. We can do it together with other tasks that require adjusting translations i.e. https://bugzilla.redhat.com/show_bug.cgi?id=2024202

But this can be easily fix

Sure. We can do it together with other tasks that require adjusting translations i.e. https://bugzilla.redhat.com/show_bug.cgi?id=2024202

So once the translation files are ready, we can merged this and only then push to Zanata the new translated strings.

All tests passed

LGTM


What is the purpose of this repo?

Hey,
I was trying to get autoprefixer working with jspm 0.17
I was getting along decently well until I hit an error with<EMAIL_ADDRESS>It's throwing an error fs.existsSync because it's working on the assumption its running in node. It checks for the existence of readFileSync before attempting to use fs.existsSync... but that just happens to pass due to the existence of this library.
It looks like if existsSync and statSync(..).isFile() were implemented then it'd happily call readFileSync, but it's not clear to me whether that's even desired or if it should just exit.
EDIT: It looks like if I simply return false always from existsSync then we're in business.

Yes this library is an incomplete browser fs implementation designed to support old cases of brfs via sync XHR. I'm open to a PR on existsSync or statSync that returns false or throws.

I ended up submitting a PR to browserslist to get them to check for the existence of existsSync and statSync before calling them. If this file isn't proving problematic for others than I don't see a need to build upon it for now. It was just a little surprising to have require('fs') return something, but not have that something be a full implementation.

Sure, yes this file is certainly hanging on a thread here, PRs always welcome.


Provisioning fails on Fedora 26 with vagrant-cachier installed

Issue Type

Documentation Report

Your Environment

Vagrant 1.9.1
VirtualBox 5.1.26r117224
ansible <IP_ADDRESS>
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/cristiroma/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.13 (default, Sep  5 2017, 08:53:59) [GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]

Your OS

Linux (version)

Full console output

https://gist.github.com/cristiroma/5d362ef2d12c2d4393689c1ed478fbec
Stderr from the command:

mesg: ttyname failed: Inappropriate ioctl for device
mount.nfs: requested NFS version or transport protocol is not supported

Summary

When vagrant-cachier plugin in installed on the host, Vagrant is trying to mount the folder inside the system but the mount parameters to the mount (defaults to vers=3,udp which do not work on Fedora 26).
I think there should be a documentation to mention this incompatibility or a global option to disable nfs_udp option at the global level, not per mount.

I confirm a similar failure if you are using Ubuntu as guest and OSX as host. I did not find a solution yet, a part from disabling vagrant-cachier plugin.

It should be noted that the project is marked as unmaintained.

https://github.com/fgrehm/vagrant-cachier

I suspect the problems are coming from more recent MacOS updates.


Add support for temporary IAM credentials

Adding support for temporary IAM credentials. Attaching the Security Token (provided by AWS) to the credentials in either COPY or UNLOAD will allow these temporary credentials to work.
More information about temporary credentials.
R=@traviscrawford

Current coverage is 84.24%

Merging #43 into master will decrease coverage by -0.45% as of 624ee5b

@@            master     #43   diff @@
======================================
  Files           10      10
  Stmts          307     311     +4
  Branches        67      69     +2
  Methods          0       0
======================================
+ Hit            260     262     +2
  Partial          0       0
- Missed          47      49     +2

Review entire Coverage Diff as of 624ee5b

Powered by Codecov. Updated on successful CI builds.

This sounds reasonable to me; I'm working on some automated end-to-end tests so we'll be able to test this sort of thing in the future.

@JoshRosen Fixed style-nit. And awesome, sounds great!

Hey, so it looks like there are now two unrelated bugfixes in this PR: a fix for overwriting non-existent tables and a fix for temp. IAM credentials.  Do you mind splitting the first fix into a separate PR and adding a test case?

@JoshRosen Removed it. Seems like #26 patches it. :+1:

Cool, thanks.  I'm going to try to clear out the queue of open PRs today while writing regression tests as I go.

Alright, I've run this against the end-to-end integration tests and those still work, so I'm going to merge this now. I don't think that it's going to be trivial to write automated tests for this (it's not impossible, though), so I'm going to let that slide for now and will just trust that code review will catch breaking changes to this code.  Thanks!


weird behaviour when switching between buffers

With non-global statusline, when switching between buffers, my vimode component gets updated wrongly in both buffers.
https://user-images.githubusercontent.com/95099980/167689039-c3cfc3c9-3f83-4fb0-970c-4b3d8af8eb15.mp4

This happens because the return value of vim.fn.mode() is "global" i.e. it's not possible to have multiple modes in different buffers. I'd suggest removing the ViMode component from inactive statuslines (see the cookbook) and guard the terminal vi mode like this
    local TerminalStatusline = {
        condition = function()
            return conditions.buffer_matches({ buftype = { "terminal" } })
        end,
        { condition = conditions.is_active, ViMode, Space },
        ...
    }

If you followed my advice, regarding the mode_color function, here's a safer example. I'll soon put this in the cookbook.
        static = {
            mode_color = function()
                local mode_colors = {
                    n = colors.red,
                    i = colors.green,
                    v = colors.cyan,
                    V = colors.cyan,
                    ["\22"] = colors.cyan, -- this is an actual ^V, type <C-v><C-v> in insert mode
                    c = colors.orange,
                    s = colors.purple,
                    S = colors.purple,
                    ["\19"] = colors.purple, -- this is an actual ^S, type <C-v><C-s> in insert mode
                    R = colors.orange,
                    r = colors.orange,
                    ["!"] = colors.red,
                    t = colors.red,
                }
                local mode = conditions.is_active() and vim.fn.mode() or 'n' -- if not current window, use colors from normal mode
                return mode_colors[mode]
            end,

Yeah I used a similar method to the one you recommended.
https://github.com/MurdeRM3L0DY/dotfiles/blob/207d185b7fc8d0eed843c930693dbeed4b019434/roles/nvim/files/lua/plugins/heirline/config.lua#L41
I use global statusline but I thought this was a bug on heirline that's why I reported it.


Hashed host names/addresses in known_hosts are not supported

I recently ran into an issue using SSH key-based authentication and strict host key checking. I was getting tracebacks with scrapli.exceptions.ScrapliAuthenticationFailed: <IP_ADDRESS> not in known_hosts! despite knowing for sure that I had connected to that host before.
This was apparently due to having HashKnownHosts yes set in my ssh_config file, which applies hashing to the host identifier field of new entries in a known_hosts file:
# An unhashed entry
<IP_ADDRESS> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...

# The same entry, but the host address is hashed
|1|7bElFvrtgI2+a1RXLTrM6WsAnfw=|bbO+1Ns+K5Uw+swY0xs0aQkzJfI= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...

While parsing a known_hosts file and creating a SSHKnownHosts().hosts dict, scrapli doesn't do anything special with the hashed host, and the key for the dict entry ends up being "|1|7bElFvrtgI2+a1RXLTrM6WsAnfw=|bbO+1Ns+K5Uw+swY0xs0aQkzJfI=".
Here's where it was falling over for me, in transport/ssh2/transport.py:Ssh2Transport._verify_key(), lines 96-101:
        known_hosts = SSHKnownHosts(self.plugin_transport_args.ssh_known_hosts_file)

        if self._base_transport_args.host not in known_hosts.hosts.keys():
            raise ScrapliAuthenticationFailed(
                f"{self._base_transport_args.host} not in known_hosts!"
            )

Fortunately, computing the hash can be easily done with Python builtins. The hash algorithm is standard HMAC-SHA1 and its format in the known_hosts file is as follows:

|1|: A magic number. HASH_MAGIC in the OpenSSH sources.
A Base64-encoded representation of a random salt (i.e. the secret key mentioned in RFC 2104).
|: A pipe character as a separator.
A Base64-encoded representation of the result after hashing the host identifier using the salt (i.e. after running HMAC-SHA1 using the salt as the key and the host name/address as the message).

I have a PR more or less ready to go, but before that, your thoughts? Comments? Questions?

Hey @kangtastic thanks for opening this, and for the great explanation!
Absolutely open to a PR for this, sounds like it would be a great addition, and love that it can be done all with standard library. Looking forward to checking it out!
Carl

Awesome PR merged, closing this 🚀 !


Teradata support

I am looking for Teradata support, currently I don't find any library which can parse the teradata ddls and give information. My main task is to convert Teradata DDL to oracle equivalent. I tried creating the script on my own but then realised it is way more complex then I thought.

@Rahulb7, hi! thanks for opening the issue, I have a lot of personal staff to work with, but now I'm back. Can you provide some Teradata DDLs samples that are not parsed by parser yet? I will add the support for them


Feature/gclient fetcher

Summary:

add gn.bbclass/gn.py, which is the bitbake fetcher for gcleint. By using this bbclass, flutter-engine can store its source codes in DL_DIR. This is more suitable with Yocto style and will make the result of builds more reusable.

Change SRC_URI of flutter-sdk from the git repo to the tarball.

When major updating, flutter-sdk will overwrite its history. Due to this, the build may be unstable.
By using the release tarball, this issue can be avoided.

add .gitignore

this is created to ignore *.pyc of gn.py

@WAKazuyoshiAkiyama
Can you rebase against main?  CI should be ready to run in a few hours.

@jwinarske I rebased this branch.

This engine build is past thirty minutes.  Any idea why?  How long should it take with an empty cache?
https://github.com/meta-flutter/meta-flutter/runs/5402080716?check_suite_focus=true

A clean build of the engine currently takes ~6 minutes.  One example:
https://github.com/meta-flutter/meta-flutter/runs/5400935106?check_suite_focus=true

@WAKazuyoshiAkiyama The machine backing up the CI jobs on meta-flutter is a 48 core + 128GB RAM machine with 1GB internet bandwidth.  Your proposed solution is very slow.  It took 1 hour and 8 minutes to build one instance of the engine.  Currently in meta-flutter using gclient it complete engine step in ~6 minutes, which includes a cleansstate, fetch, and build each time.
My initial thought on flutter/gclient LTS was to parse out the DEPS file in base repo, then generate a recipe similar to how Rust bitbake cargo works.  It would be slightly slower than gclient implementation, but it should be much faster than your proposed scheme.  So a pre-processing script that creates an inc file.  The outer recipes using this could be named something like:
flutter-engine-lts-debug_2.10.2.bb
flutter-engine-lts-release_2.10.2.bb
flutter-engine-lts-profile_2.10.2.bb
If there was a minimal difference in build time I would drop depot_tools/gclient usage altogether.

@WAKazuyoshiAkiyama This tool in theory can convert DEPS to a parsable list:
https://chromium.googlesource.com/chromium/tools/deps2git

@WAKazuyoshiAkiyama Actually something better.  gclient leaves behind a json file of all the paths/repos called .gclient_entries.  It's written in the same folder as .gclient and .cipd.

Yocto defaults branch as master.  A number of the repos do not have a master branch, rather only main; most likely renamed.  I'm finding there is trial and error to find which repos default to main, then updating python output for some repos with branch=main.  It might be good to have the script validate each repo and determine which requires branch=main.

Working branch for experiment.  Target CI job is linux-dummy.
https://github.com/meta-flutter/meta-flutter/blob/jw/lts/recipes-graphics/flutter-engine/flutter-engine-debug_2.11.0-0.1.pre.bb

Currently in meta-flutter using gclient it complete engine step in ~6 minutes, which includes a cleansstate, fetch, and build each time.

At least, in my environment, even if gn.bbclass is not used, engine step spends 1+ hour, so I'm not sure why the case without gn.bbclass is so faster.
The way to use gclinet.py should not be so much different between gclinet,py in do_patch and gn.bbclass....

similar to how Rust bitbake cargo works

I like this idea.
From my understanding, since cipd's SRCREV is specific, so CIPD fetcher class needs to be created. Is it correct?

From my understanding, since cipd's SRCREV is specific, so CIPD fetcher class needs to be created. Is it correct?

Correct

@jwinarske
I tried to create cipd fetcher class.
But, the error of git fetching happened.
ERROR: flutter-engine-debug-git-r0 do_fetch: Fetcher failure: Unable to find revision fa166c29f0407be21acebb394d194a38c00593cb in branch main even from upstream
ERROR: flutter-engine-debug-git-r0 do_fetch: Fetcher failure for URL: 'git://dart.googlesource.com/sdk.git;protocol=https;destsuffix=src/third_party/dart;branch=main;name=dart_googlesource_com_sdk_git'. Unable to fetch URL from any source.

The git revisions of flutter-engine dependencies might be unstable, so this idea might be difficult to use.
I created flutter-engine-src.inc based on https://github.com/meta-flutter/meta-flutter/blob/jw/lts/recipes-graphics/flutter-engine/flutter-engine-debug_2.11.0-0.1.pre.bb.
But, the entries of cipd:// has the extra _ and / in SRC_URI and SRC_REV, so I removed them.
cipd:/// -> cipd://
name=_XXX -> name=XXX

SRCREV__XXX -> SRCREV_XXX

@WAKazuyoshiAkiyama
I have output pulling files now.  The issue is that Yocto wants explicit branch of commit, and it defaults to master.  I had to implement logic in the script to query repo.  In the case of the freetype2 repo, the commit doesn't exist on the server, so I drop it.  In the case of libwebp the tags changed to have a 'v' prefix.  So I added some logic to get first right justified match.
Removing the cipd:// entries + freetype2 entry, the CI job completes file sync in ~5 minutes.  So this is good.
Process to generate inc file
Navigate to engine folder with .gclient
gclient revinfo --output-json=gclient_entries.json
move gclient_entries.json to same folder as gclient_bitbake.py
python gclient_bitbake.py > ${FLUTTER_SDK_TAG}.inc
In the version I tried 2.11.0-0.1.pre it has an invalid reference to freetype2.  Commit cannot be found in any branch.  My suspicion is that this path isn't used in the build, and it's been this way for a while.
    "src/third_party/freetype2": {
        "url": "https://flutter.googlesource.com/third_party/freetype2",
        "rev": "1f03c1b2d7f2ae832a4fbe9d12bd96c3c15bbece"
    },

For the CIPD implementation I was thinking it should model after file fetcher, and use same properties.
Example
cipd://flutter/web/canvaskit_bundle;destsuffix=src/third_party/web_dependenciesflutter_web_canvaskit_bundle

the first section is the CIPD path
destsuffix is location under ${S} where CIPD package gets extracted to
it should have an md5 property as well similar to downloading a file

It's just like a https file download that uses CIPD transport on top of curl.  Generic CIPD download support.

@WAKazuyoshiAkiyama
I have the script working well, and it runs on machine with many cores.  Execution time to validate all the SRC_URI is around 7 minutes using 20 cores.
Looking at cipd in depot tools, it's a bash script.  It attempts to pull an updated client before each runs.  It pulls cipd executable from google storage.   It should be using cipd client that was built via yocto build, without an update shim.
The source for luci infra is located here:  https://github.com/luci/luci-go
To build cipd tool
export PATH=/home/dev/depot_tools:$PATH
export STAGING=`pwd`/.tmp
fetch infra
cd infra/go
eval `./env.py`
cd src/go.chromium.org/luci
mkdir $STAGING/bin
go build -v -o "$STAGING/bin/cipd" go.chromium.org/luci/cipd/client/cmd/cipd
$STAGING/bin/cipd help -advanced

I added a recipe that builds cipd here: https://github.com/meta-flutter/meta-flutter/blob/jw/lts/recipes-devtools/luci-go/luci-go-native_git.bb
The runtime path for flutter-engine is ${STAGING_DIR_NATIVE}/usr/bin/cipd

@WAKazuyoshiAkiyama
My branch has a working cipd fetcher that uses the luci-go-native cipd binary.  Fetching for gclient-entries.inc appears to be 100% functional.  Performance fetching CIPD packages is very good.  Less than a minute on my system to pull all the packages.
I'm now hitting what looks like an incorrect repo commit, or overlay ordering issue.  I'm done for the weekend, and will look at it tomorrow (US).
| ERROR at //third_party/dart/runtime/bin/BUILD.gn:5:1: Can't load input file.
[250](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:250)
| import("../../build/config/gclient_args.gni")
[251](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:251)
| ^-------------------------------------------
[252](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:252)
| Unable to load:
[253](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:253)
|   /__w/meta-flutter/yocto-dunfell/poky/build/tmp/work/core2-64-poky-linux/flutter-engine-debug/2.11.0-0.1.pre-r0/git/third_party/dart/build/config/gclient_args.gni
[254](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:254)
| I also checked in the secondary tree for:
[255](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:255)
|   /__w/meta-flutter/yocto-dunfell/poky/build/tmp/work/core2-64-poky-linux/flutter-engine-debug/2.11.0-0.1.pre-r0/git/build/secondary/third_party/dart/build/config/gclient_args.gni
[256](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:256)
| See //flutter/shell/testing/BUILD.gn:35:5: which caused the file to be included.
[257](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:257)
|     "//third_party/dart/runtime/bin:dart_io_api",
[258](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:258)
|     ^-------------------------------------------
[259](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:259)
| Generating GN files in: out/linux_debug_x64
[250](https://github.com/meta-flutter/meta-flutter/runs/5440886778?check_suite_focus=true#step:9:250)

Something we need to look at is adding md5 support to the CIPD fetcher.
I added md5 entries for each cipd package to gclient-entries.inc.

@jwinarske
I don't understand how to use this script.
This script is not executed in the Yocto and executed before Yocto build to generate *.inc file?
If so, how should cipd;// entries be handled?
I'm not sure what your current point is and what you want to do.

@jwinarske
Could you share the branch of luci-go? I would like to check your work about luci-go.

@WAKazuyoshiAkiyama
This script  is run from folder with .gclient file, which creates snapshot for Yocto.  The output - gclient-entries.inc is used by a flutter-engine recipe.
What I have in my branch, it pulls all the cipd:// entries and extracts then.
Regarding luci-go you can Google for the source repo and documents.  It's very light on documentation.  There's a lot that can be done with that (infra/luci-go) source tree.  Cipd client is just one of many luci tools.  I used my script to create the luci-go-native recipe.  The version I grabbed snapshot of was main.  You run gclient sync after checking out repo that holds the root DEPS.  This will enforce all dependent deps.
Next is to pull in asset download using the save from google storage python script (depot tools), wrapping it with a Google storage fetcher gs://.
This is needed for SDK download, as well as some actions in root DEPS "hooks".
You can start on that.
The other item is md5 on cipd fetcher is needed.

For cipd fetcher class I implemented, this cannot handle multiple cipd:// entries, so I need to fix this...

I tried to use gclient_bitbake.py in flutter 2.10.3, but, somewhy, SRCREV of engine cannot be generated.
SRC_URI += "\
    git://github.com/flutter/buildroot.git;protocol=https;destsuffix=git/;name=github_com_flutter_buildroot_git;name=g
ithub_com_flutter_buildroot_git \
    cipd://fuchsia/third_party/clang/linux-amd64;destsuffix=git/buildtools/linux-x64/clang/;name=fuchsia_third_party_c
lang_linux_amd64 \
    git://github.com/flutter/engine.git;protocol=https;destsuffix=git/flutter/;name=github_com_flutter_engine_git \
    cipd://gn/gn/linux-amd64;destsuffix=git/flutter/third_party/gn/;name=gn_gn_linux_amd64 \
[...]
SRCREV_github_com_flutter_buildroot_git = "4660f4a166979c64ff56f6b856b44ccc1dba5c63"
SRCREV_fuchsia_third_party_clang_linux_amd64 = "Fn7lDYhKDAwbGQ2SOL_Anwt8fzO1Yho7UjpoS9Hv8N8C"
SRCREV_github_com_flutter_engine_git = ""
SRCREV_gn_gn_linux_amd64 = "git_revision:b79031308cc878488202beb99883ec1f2efd9a6d"
SRCREV_fuchsia_sdk_core_linux_amd64 = "DS-3oCidC7xGrdGByHplsRyY8Err4sguVaV0CfHsn6sC"
[...]

How can I get a correct gclient-entris.inc?

@WAKazuyoshiAkiyama That indicates the json file has value null for the revision.  Either update json with value, or add revision after the fact.  I could check this state and cd into src/flutter to return the commit hash.  Will look into that.
Also there is something odd happening with libwebp in the script.  I had it working before.  The gist is that the 1.2.0 revision should be v1.2.0.  Just modify it after the fact until I get it working again.

@WAKazuyoshiAkiyama The cipd fetcher appears to handle multiple entries.  Check my branch for the changes.

@jwinarske I have already fixed my cipd fetcher in my local. (self.basecmd -> ud.basecmd)
But, you have already implemented some fetchers, so can I rebase this branch according to your branch?

@jwinarske

That indicates the json file has value null for the revision. Either update json with value, or add revision after the fact. I could check this state and cd into src/flutter to return the commit hash. Will look into that.

I have already  added the srcrev of engine manually, but the following error happened.
ERROR: flutter-engine-debug-2.10.3-r0 do_fetch: Fetcher failure: Unable to find revision bd539267b42051b0da3d16ffa8f48949dce8aa8f in branch main even from upstream
ERROR: flutter-engine-debug-2.10.3-r0 do_fetch: Fetcher failure for URL: 'git://github.com/flutter/engine.git;protocol=https;destsuffix=git/flutter/;branch=main;name=github_com_flutter_engine_git'. Unable to fetch URL from any source.

But, the revision bd539267b42051b0da3d16ffa8f48949dce8aa8f appears in the engine repo.
$ cd src/flutter
$ git show
commit bd539267b42051b0da3d16ffa8f48949dce8aa8f (grafted, HEAD, origin/flutter-2.8-candidate.16)
Author: Kevin Chisholm<EMAIL_ADDRESS>Date:   Mon Feb 28 16:09:52 2022 -0600

    [flutter_releases] Flutter stable 2.10.3 Engine Cherrypicks (#31721)

    * Conditionally call FlutterViewDestroyOverlaySurfaces (#31464)

    * Fix PhysicalShapeLayer paint bounds with clipping disabled (#31656)

    * Fix PhysicalShapeLayer paint bounds with clipping disabled

    * Add missing SkRect initialization

    * 'add branch flutter-2.8-candidate.16 to enabled_branches in .ci.yaml'

    * remove branch ref

    Co-authored-by: Emmanuel Garcia<EMAIL_ADDRESS>    Co-authored-by: Matej Knopp<EMAIL_ADDRESS>

I could check the fetch failure of freetype2 you said.
And, in this PR, I will try to accelerate gn.bbclass fetching.
You are working on the idea like cargo.bbclass in that PR, so I will try another option.

I don't understand why the error happens...
@WAKazuyoshiAkiyama This happens as the rev version for the root project in the json file is null.

I updated the script.  Changes:

correctly identifies when requested commit is not found
using path from DEPS fills in source revision in case where  json root project "rev" == null.
https://github.com/meta-flutter/meta-flutter/blob/jw/lts/scripts/gclient_bitbake.py

In case for freetype2 it would expect it would fail to fetch, but it doesn't break the build.  I haven't examined the log yet.

@jwinarske

And, in this PR, I will try to accelerate gn.bbclass fetching.

You are working on the idea like cargo.bbclass in that PR, so I will try another option.

Is it OK?
The idea like cargo.bbckass might have the issue revisions of dependecies may be unstable(this issue might be resolved by the improvement of the script), so if gn.bbclass becomes much faster, gn.bbclass is better, I think.
I think it is better that I try to make gn.bbclass faster while you try the idea like cargo.bbckass.

The procedure to create tarball with "tar -cJf" may take long, so I will try to change the procedure to create tarlball with multi thread.

@WAKazuyoshiAkiyama
If we need LTS today then your gclient snapshot approach would work.  I think the client pre-process script approach will be used by the Yocto community for general gclient support.  It's simple and effective, and is easy to update to a new release.  I'll notify the mailing list tomorrow.
The time to beat for your gclient snapshot approach is ten minutes when running on my machine.
Cloud time is very expensive for high core count vCPU.  So I would use the most effecient solution.

@jwinarske
Yes, I agree your approach will have a better performance.
But, I'm worry that flutter-engine upstream fluency changes the revisions of dependencies in a same version e.g. due to overwrite histroeis.
If such overwriting happens, the maintenance of flutter-engine LTS will become more difficult.
If such overwriting fluency happens, the approach of gclient snapshot will be more suitable even if that performance is lower.

@jwinarske
I updated gn.bbclass (lib/gn.py) to make do_fetch faster.
After building flutter-engine 2.10.2, it takes about 6m to build flutter-engine 2.10.1.
$ time bitbake flutter-engine-debug -c fetch
real    5m56.239s
user    0m0.500s
sys     0m0.104s

Withtout a previous result in DL_DIR, do_fetch may take 40+m in my environment(12 core).

After updaing gn.bbclass (lib/gn.py), the directory to execute gclient sync are shared if the version of engine is changed.
But, the tarball generated by do_fetch is different between the versions of engine.
$ ls /workdir/download/gn
https__github.com_flutter_engine.git
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2.done
https__github.com_flutter_engine.git-ab46186b246f5a36bd1f3f295d14a43abb1e2f38.tar.bz2
https__github.com_flutter_engine.git-ab46186b246f5a36bd1f3f295d14a43abb1e2f38.tar.bz2.done

Overloading the unpack method and using pbzip2, do_unpack will be made faster, but, other bitbake fetcher doesn't do that, so I hesitate to overload the unpack method.

I added the specific unpack method for the gclient fetcher.
Due to this, do_unpack becomes made much faster.
$ time bitbake flutter-engine-debug -c unpack
real    1m54.932s
user    0m0.983s
sys     0m0.156s

Before adding this unpack method, do_unpack took 15+m.

@jwinarske Could you check the new implementation of gn.py in this repo's CI?
After second or later build, the time to build will become shorter enough.

@jwinarske
Could you run CI?

@jwinarske
Come to think of it, I think that when gclient sync was run, gclient did not simply fetch the dependent sources, but also executed a hook and fetched the Dart SDK, etc.
Is this kind of processing supported by your PR?
If it is not supported, then you may need to run gclient runhook after getting a series of sources.

@WAKazuyoshiAkiyama Yes.  I have a new task getting added to the inc file.  I'm working through the details on that right now.  In order to handle the conditionals in hooks and deps it requires come on the fly code compiling.  I am running the script on a number of other gclient projects (v8, Skia, etc).  Each uses the conditionals a little different.  When I am at a breaking point I will run your jobs.

@WAKazuyoshiAkiyama This error is due to having desktop linux enabled.  I explicitly turn this off in dunfell branch.
https://github.com/meta-flutter/meta-flutter/actions/runs/1954631184

@jwinarske

This error is due to having desktop linux enabled. I explicitly turn this off in dunfell branch.
https://github.com/meta-flutter/meta-flutter/actions/runs/1954631184

From my understanding, linux-desktop is disabled in do_compile of flutter-sdk in even also this branch.
So, this is the issue of CI?

Mismatch of VM between SDK and Engine:
https://github.com/meta-flutter/meta-flutter/runs/5474458756?check_suite_focus=true

I'm not sure why this error happens in this target only.
The revision of upstrean might be updated.
I'll check this error, and I may set a default value to FLUTTER_SDK_TAG if required.

From my understanding, linux-desktop is disabled in do_compile of flutter-sdk in even also this branch.
So, this is the issue of CI?

in do_compile_class-native and do_compile_class-nativesdk, linux-desktop is not disabled, so I will make do_compie common in class-taget. class-native and class-nativesdk.

@WAKazuyoshiAkiyama
To rule out the build I would need to wipe the sstate and build.  Each build runs a cleansstate for each flutter build, to avoid anything strange.  Unclear what the sstate does when versions change.  There test would be to run the full set on clean everything.  I do this before a release, make sure everything is still working; cold boot smoke test...
The tag mismatch, not sure.  It shouldn't happen as it's explicitly defined for both.  The same variable is used for both SDK and engine.
I do have concerns about disk space getting eaten up per build.  I rarely clear the dl dir, and it's common to all the build.  I would need to manage that somehow.  What are the options there?

@jwinarske

I do have concerns about disk space getting eaten up per build. I rarely clear the dl dir, and it's common to all the build. I would need to manage that somehow. What are the options there?

Can I remove all of tarball generated when cleanall is executed?
Or, just executing rm -rf ${DL_DIR}/gn/*flutter_engine* will work.
And also, I can fix the version of flutter to e.g. 2.10.3.

@WAKazuyoshiAkiyama
distclean should also delete the dl cache file.
As long as you filter what you're deleting it should be good.

@jwinarske
Currently, the gclient fetcher remove the tarball of current revision, i.e. the gclient fetcher doesn't remove the tarball already generated.

Ex)

If there are the following tarbal in DL_DIR

DL_DIR/gn/https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f.tar.bz2
DL_DIR/gn/https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2

the current engine revision is bd539267b42051b0da3d16ffa8f48949dce8aa8f.
In this case, even if cleanall/cleandist is executed, DL_DIR/gn/https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2 will not be executed.

I feel it is not good to remove the different version's tarball, but I can change the impl to remove all of generated tarballs.

The error of nativesdk-flutter-sdk didn't happen in my local environment.
For the error that flutter-sdk hash is different between flutter-app and flutter-engine, in order to avoid that error, I added the inc file to set a default value of FLUTTER_SDK_TAG.
This is suitable for LTS support.

I found the root cause of https://github.com/meta-flutter/meta-flutter/runs/5474458756?check_suite_focus=true.
The logic to get the revision if AUTOREV is set is different between flutter-sdk and flutter-engine, so sometimes, this error will happen.
So, I made the logic common between them.

@WAKazuyoshiAkiyama
Regarding not removing prior versions, I agree.  We don't want that to happen.
Looks like remaining item is disabling Linux desktop to make SDK build happy.
Build times look good 👍

@WAKazuyoshiAkiyama Update on my LTS solution:

freetype2 issue is still outstanding
I found something odd with gclient and freetype2.  I submitted issue hoping someone can answer my question.
https://github.com/flutter/flutter/issues/99841
gclient is doing this somehow.  It's not clear there is a git hook implementation doing this, or what.

Replacing freetyp2 with revision of head (for now) CI jobs are passing.  do_run_hooks gets dynamically generated in the latest script.  I observed one engine debug build (cleansstate + build) which was 2 min 43 seconds.  That is by far the record for a clean engine build on my machine.

Once behavior with freetype2 is understand and accommodated, then I will look into running a batch job to convert all stable tags in flutter repo and add to meta-flutter.  Then use of FLUTTER_SDK_TAG would directly select the engine inc file.  Engine inc files will be located in conf/include.

@WAKazuyoshiAkiyama
I have changed hook script python3 src/flutter/tools/download_dart_sdk.py --fail-loudly to be a https SRC_URI entry.
Unless the build itself pulls artifacts during the build, I believe my PR is LTS compatible.

@jwinarske
I fixed the error of invalid deps for linux-desktop.
flutter-sdk stored in storage.googleapis.com has some artifacts in bin/cache/artifacts, and they cause the error.
Maybe, those artifacts may be generated through something like release tests of Google, but, since they are unnecessary, I removed them in do_install.
Could you run CI?

@WAKazuyoshiAkiyama
My PR is passing all CI now.
The minimum change for your last change is:
https://github.com/meta-flutter/meta-flutter/pull/80/files#diff-78e6ed211e5f49ec21d6edd9971d3b7cfc89625c801896beae1d388dbcec979dR74
Deleting the whole cache would not prevent build, but will most likely re-trigger download during build.
We still need to solve problem of the Dart pub package manager.  Packages referenced in project yml are dynamically pulled at build, if they are not present in the pub package manager.  I'm thinking the solution here is to parse the application yml and manually add cache entries via a custom fetcher.  If we don't then these get added dynamically at build time (not LTS).
When I build flutter SDK I specify PUB_CACHE to be under ${S}.  I added this as the default pub cache gets created under user directory; host contamination.  In the case of the engine build it updates pub cache offline using:
src/third_party/dart/tools/sdks/dart-sdk/bin/pub get --offline

It's not clear if all the items the engine build consumes, are actually present in the cache to start.  We should be able to isolate that easily with desktop build environment.  I'm think they are not.
Note in the current scheme for meta-flutter when application is built PUB_CACHE is not set, so it's defaulting to user directory; host contamination and not LTS.  The host contamination can be resolved with export PUB_CACHE in do_compile of flutter app class.
When an app is built, it will install all the packages referenced in pubspec.yml, and install them into the pub package manager; location is determined via environmental variable PUB_CACHE.  To work around this we are going to need to add a fetcher to add flutter packages to the pub package manager.  In addition we will need to be careful how/when PUB_CACHE is set.
Once pub package manager is resolved we should run Wireshark on the subnet of a build machine and monitor the traffic.  If no pulls are seen, then we are LTS.

@WAKazuyoshiAkiyama
Dart can be run from any directory to get offline packages using the following pattern:
PUB_CACHE="my/path" dart pub get --directory=./flutter/examples/hello_world
PUB_CACHE="my/path" dart pub get --directory=./flutter/examples/hello_world   --offline

If --offline is used in first pass I see dependency errors on some projects.
I believe the default behavior is --no-offline.
Usage: dart pub get <subcommand> [arguments...]
-h, --help               Print this usage information.
    --[no-]offline       Use cached packages instead of accessing the network.
-n, --dry-run            Report what dependencies would change but don't change any.
    --[no-]precompile    Build executables in immediate dependencies.
-C, --directory=<dir>    Run this in the directory<dir>.

So for LTS we need to include this in some format for a given app.

@WAKazuyoshiAkiyama I just merged support for PUB_CACHE cache archive/restore for Flutter App support.  This doesn't include any pub caching for the engine recipe.

@jwinarske
I understand the issue of PUB_CACHE for LTS.
From my understanding, flutter-engine has a similar issue.
When executing the hooks of gclient, some dart deps(pub cache) will be fetched in flutter-engine build.
And, the version of dart deps are not fixed in pubspec.yaml of flutter-engine.
At least, I failed to build the engine because the dart deps were updated at remote and the miss dependencies happened.
Then, I resolved the issue by adding pubspec.lock before executing gclient runhooks.

gclient sync --nohooks --noprehooks
add pubspec.lock to fetched source codes
gclient runhooks

Shall I add some scripts to generate pubspec.lock for the engine and support pubspec.lock for the engine recipe?
If the version of flutter supported by meta-flutter is fixed on each revisions, the way to use pubspec.lock will work.

Shall I add some scripts to generate pubspec.lock for the engine and support pubspec.lock for the engine recipe?
If the version of flutter supported by meta-flutter is fixed on each revisions, the way to use pubspec.lock will work.

I still don't think this is a good idea. In the way of gclient fetcher, it is better to get just dart deps and take its snapshot.
I will try to change PUB_CACHE dir in the engine recipe.

I tried to set PUB_CACHE env in lib/gn.py and classes/gn.bbclass, but, it seems to make no sense.
The hooks of flutter-engine might not be related to pub get...

@WAKazuyoshiAkiyama
I ran a config with --ide=json.  It provides a JSON project suitable for parsing.  I haven't had a chance to review it completely yet, but it does reference package lists explicitly for Dart projects.

By the way, do your PR use vpython? vpython generates some directories on $HOME e.g. ~/.vpython-root, so to avoid the contamination of the user's envrionment, we need to consider how to handle vpython,

@jwinarske
https://github.com/meta-flutter/meta-flutter/pull/80 is ready to be merged?
To improve do_fetch and make it more stable to build flutter-engine, this PR or https://github.com/meta-flutter/meta-flutter/pull/80 should be merged, and if https://github.com/meta-flutter/meta-flutter/pull/80 can be merged, I will close this PR.
However, if https://github.com/meta-flutter/meta-flutter/pull/80 is difficult to be merged now, I need to ready to merge this PR ASAP, I think.
So, I would like to know your plan.

@WAKazuyoshiAkiyama
80 is ready although I'm still on the fence.  I am leaning towards your PR at the moment.  It would involve less maintenance, which I like, and build times are optimal.  Every stable release for 80 would require intervention.
For this PR there are a couple of minor changes needed:
The sync should happen in ${WORKDIR}, then extraction could be skipped, and it wouldn't need to be deleted in DL_DIR.
I'm interested in the font recipe addition.  I grep'd the engine and SDK, without a reference to the font referenced as default.

@jwinarske

The sync should happen in ${WORKDIR}, then extraction could be skipped, and it wouldn't need to be deleted in DL_DIR.

I'm sorry, could you tell me how to improve concretely?
Do you mean do_unpack should be skipped?

I'm interested in the font recipe addition. I grep'd the engine and SDK, without a reference to the font referenced as default.

Previously, when I ran the app not specified any fonts, if liberation-fonts package is not installed, the app cannot run.
Can I change the dependencies to liberation-fonts to RRECOMMENDS?

Even if PUB_CACHE and VPYTHON_VIRTUALENV_ROOT are specified in lib/gn.py like the following, any directories will not be generated in DL_DIR.
diff --git a/classes/gn.bbclass b/classes/gn.bbclass
index fd09fcf..ea67253 100644
--- a/classes/gn.bbclass
+++ b/classes/gn.bbclass
@@ -37,6 +37,7 @@ do_configure_prepend() {
     export HTTP_PROXY=${HTTP_PROXY}
     export HTTPS_PROXY=${HTTPS_PROXY}
     export PATH=${DEPOT_TOOLS}:${DEPOT_TOOLS}/${PYTHON2_PATH}:${PATH}
+    export PUB_CACHE=${S}/.pub-cache
     export DEPOT_TOOLS_UPDATE=0
     export GCLIENT_PY3=0
 }
@@ -47,6 +48,7 @@ do_compile_prepend() {
     export HTTP_PROXY=${HTTP_PROXY}
     export HTTPS_PROXY=${HTTPS_PROXY}
     export PATH=${DEPOT_TOOLS}:${DEPOT_TOOLS}/${PYTHON2_PATH}:${PATH}
+    export PUB_CACHE=${S}/.pub-cache
     export DEPOT_TOOLS_UPDATE=0
     export GCLIENT_PY3=0
 }
diff --git a/lib/gn.py b/lib/gn.py
index aac87ff..597bd02 100644
--- a/lib/gn.py
+++ b/lib/gn.py
@@ -64,10 +64,14 @@ class GN(FetchMethod):

         ud.basecmd = "export PATH=\"%s:%s:${PATH}\"; export DEPOT_TOOLS_UPDATE=0; export GCLIENT_PY3=0; \
             export CURL_CA_BUNDLE=%s; \
+            export PUB_CACHE=%s; \
+            export VPYTHON_VIRTUALENV_ROOT=%s; \
             gclient.py config --spec '%s' && \
             gclient.py sync %s --revision %s %s -v" % (
                 depot_tools_path, os.path.join(depot_tools_path, python2_path),
                 d.getVar('CURL_CA_BUNDLE'),
+                os.path.join(ud.syncpath, '.pub-cache'),
+                os.path.join(ud.syncpath, '.vpython-root'),
                 gclient_config,
                 sync_opt, srcrev, d.getVar('PARALLEL_MAKE'))

Therefore, setting PUB_CACHE and VPYTHON_VIRTUALENV_ROOT make no sense.
And, when GIT_CACHE_PATH was specified, the error happened in do_fetch, so this environment is not available.
So, I have no addition for the current revision.

The sync should happen in ${WORKDIR}, then extraction could be skipped, and it wouldn't need to be deleted in DL_DIR.

In the current implementation, the sync directory for flutter-engine is reused when flutter-engine's version is changed.
This reusing help acceleration do_fetch much.
The following directory will be generated for any version.
/workdir/download/gn/https__github.com_flutter_engine.git

However, an artifact actually used in do_unpack is a generated tarball like the following.
$ ls /workdir/download/gn/*.tar.bz2
/workdir/download/gn/https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f.tar.bz2

Dividing the working directory for gclient sync and the artifacts for do_unpack, building an old version of flutter-engine will become easier.
For example, after flutter-engine 2.10.2 is built, there are the following artifacts under DL_DIR/gn.
$ ls /workdir/download/gn/
https__github.com_flutter_engine.git
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2.done

And then, after flutter-engine 2.10.3 is build, there are the following artifacts under DL_DIR/gn.
https__github.com_flutter_engine.git
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2.done
https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f.tar.bz2
https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f.tar.bz2.done

And then, when building flutter-engine 2.10.2 again, https__github.com_flutter_engine.git is the state of version 2.10.3, but, since there is the tarball of flutter-engine 2.10.2 (https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2), gclient sync will be skipped and https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2 will be used.
If gclient sync is directly executed in WORK_DIR, when changing the version of flutter-engine, gclient sync needs to be executed every time.
So, the build time will be increased.
I think the current way is better than executing directly gclient sync in WORK_DIR.

@WAKazuyoshiAkiyama i understand.  My point is that it should use ${WORKDIR} opposed to a potentially orphan folder that consumes space.  The argument that it does a Delta sync faster versus an absolute sync, yes it would.  However the preference would be to have source tree in a  guaranteed state.
The other concern is around depot_tools.  It will verify latest version prior to running, meaning a network connection is required, and the far end service needs to be functional.  My preference is to factor out the depot_tools dependency.  Why cipd wrapper script checks version everytime is a big question.  Does the backend interface change that often, or are they using it to gather use metrics similar to autoninja.  My preference is to factor out the depot tools dependency as PR 80 has done.  I believe this approach follows the spirit of the Yocto project more closely, as it quantifies the unknowns in an explicit way.

@jwinarske

My point is that it should use ${WORKDIR} opposed to a potentially orphan folder that consumes space.

There is a usecase to share DL_DIR between develpers, e,g, with using SOURCE_MIRROR_URL.
So, I believe the souce code of flutter-engine should be placed in DL_DIR.

The argument that it does a Delta sync faster versus an absolute sync, yes it would. However the preference would be to have source tree in a guaranteed state.

Actually, in the initial implementation of this PR, the sync dir is different between versions of flutter-engine like the following.
$ ls /workdir/download/gn
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2
https__github.com_flutter_engine.git-a83ed0e5e3b9cd2b5e2f07ef31c72f43c55e93b7.tar.bz2.done
https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f
https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f.tar.bz2
https__github.com_flutter_engine.git-bd539267b42051b0da3d16ffa8f48949dce8aa8f.tar.bz2.done

So, I can change the sync dir per versions of flutter-engine.
Shall I do so?

I believe this approach follows the spirit of the Yocto project more closely,

I agree, but, the gclient fetcher firmly depends on gclient in depot_tools, so I cannot remove the dependency to depot_tools.
So, I think, to avoid some unclear issues like the following, patching depot_tools and disabling unnecessary network accesses are the only way.

It will verify latest version prior to running, meaning a network connection is required, and the far end service needs to be functional.


Code sharing ability's

Is your feature request related to a problem? Please describe.
I think a code-sharing feature in DogeHouse would be very useful as a lot of us are talking about code and are trying to share code too.
Describe the solution you'd like
Some kind of code sending system with syntax.

#496

#496

Ben closed that issue because there is a difference between screen sharing (video), and audio sharing. There is already a chat built into the website so it shouldn't be hard to integrate a code send built into the current chat and it won't impact the program in cost.

It is in the same topic sharing something on DogeHouse,
And he has said in the contributors meeting till a long time there will no feature of sharing something even code

And he has said in the contributors meeting till a long time there will no feature of sharing something even code

From what I know, Ben doesn't wanna integrate video because of the cost of the servers etc. The application already has built-in chat so it won't hurt to add a feature to send code?

@MattLawz @Mudrank What I think would be a good compromise is the ability to write formatted codeblocks like so:
print("hello world!")

@MattLawz @Mudrank What I think would be a good compromise is the ability to write formatted codeblocks in chat like so:
print("hello world!")

Yes I also think this is a good idea!


Semantic model configs - enable/disable + groups

resolves #7968
docs dbt-labs/docs.getdbt.com/#
Problem
Semantic models cannot be enabled/disabled and also cannot belong to groups.
Solution
Enable configs to allow semantic models to be disabled and be in groups.
When a semantic model is disabled but the defined metric for the measure is not, it throws a ParsingError.
Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX

Opened a new issue in dbt-labs/docs.getdbt.com: https://github.com/dbt-labs/docs.getdbt.com/issues/3997


ensure the configuration gets loaded, esp if provider is down

maybe a configurable timeout for rechecking or similiar


feat(devtools): implement message communication flow for Chrome DevTools

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

22 of 45 (48.89%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-2.0%) to 98.021%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/rippling/src/debug/devtool-interceptor.ts
2
25
8.0%

Totals

Change from base Build<PHONE_NUMBER>4:
-2.0%

Covered Lines:
901

Relevant Lines:
924

💛  - Coveralls


Use the known-folders package to find install dir

This change makes zigup use known-folders for determining the install directory by default. A new build option default-dir has been added to control whether the default behaviour is to use the known-options package or the old behaviour. When default-dir is provided everything is the same as before, except that instead of the use of "zig" as the name of the install directory, the value of the default-dir build option is used (i.e. for the old behaviour use zig build -Ddefault-dir=zig).
When the default-dir build option is not provided the changes to behaviour are that when the --install-dir option is not provided:

a platform-specific standard directory is chosen, this will be the parent of the install directory for managing compilers

linux uses XDG_DATA_HOME, which defaults to ~/.local/share if the $XDG_DATA_HOME env var is not set
mac uses ~/Library/Application Support
windows uses the %APPDATA% env var

if the above platform-specific directory does not exist, zigup will report an error, rather than creating the directory
the zigup install (sub)directory underneath the above platform-specific directory is zigup, e.g. the default location on linux becomes ~/.local/share/zigup.

Note that I am not very familiar with Windows and macOS conventions here, but I assume known-folders is making a sensible choice; it is possible to have known-folders use the XDG spec on macOS rather than using ~/Library/Application Support.
In addition, the first commit in the PR updates use of some deprecated aliases in std that were made compile errors in the 0.13 release cycle. They were deprecated before Zig 0.12, so 0.12 still works, but with these Zig master can also build zigup. I can split this commit into a separate PR if that is preferable.
Compared to #66 (I had not noticed the apparent inactivity in that PR when I commented) I believe using known-folders is the right approach, and provides a build option as was suggested in comments on that PR to allow using original default behaviour.

A PR to update deprecated aliases (so long as it passes tests would merge this immediately)
A PR to add an option to change the install path (would also merge this with no fuss)

Will do.

A PR to change the default install directory (I'm not convinced yet that we should make this change)

Whether the default (i.e. when just running zig build) gets changed or not, how about at least a build option to support the XDG spec on Linux and macOS? Then the question could just be whether the build option is -Duse-xdg or Dno-xdg?

One thing I note is that you've provided good documentation on what directory zigup will choose in README.md, but then you use the known-folders package which abstracts these details away. Therefore, if known-folders ever changes then the zigup README.md will no longer be valid, and furthermore, I have to go and check the logic inside of known-folders to know if it's valid in its current state. If zigup has to know these details anyway (for it's README) then why use the abstraction? I'd probably go with something more like this:

Fair point. I think there is basically 0% chance known-folders would change the location for linux, but I can't be so sure about the other operating systems. There will be more logic required then that simple switch to support XDG, but it can likely be easier to understand if we just implement the bits we need.

As for all other systems, I find typing ~/zig/VERSION/... convenient in accessing the zig std library code/headers/etc and I don't think I've heard good reasons to change it. Feel free to enlighten me to convince me otherwise.

Most people don't expect a cli tool to create non-hidden folders in their home directory by default. Personally I'd go further and say I don't really think there is much of a reason to even make hidden ones these days over using the XDG spec, but I know not everyone agrees with me there.
If cli tools make the assumption that a non-standardised and not hidden directory under $HOME is the appropriate place to store data by default, not only would this lead to an unmanageable home directory, but a user could very well already be using the chosen directory for something. It doesn't make sense for zigup to tell a user that they shouldn't/can't put their local clone of the Zig repo at ~/zig because that's where zigup is going to store its data.

One more note, I think I'd be more amenable to adding a more convenient platform-agnostic mechanism to configuring the install path.  Or, maybe it updates something in the binary executable? (a resource on Windows, are there other mechanisms like this on linux/macos?)

I agree a config file is the most user-friendly way to go compared with build options (I'm not familiar with Windows resources), though I wouldn't personally care for my usage as long as there are build options. I'm not aware of a mechanism to update a binary like that on Linux/macOS, which would leave the question of where to put the config file. I would strongly recommend and prefer XDG_CONFIG_HOME/zigup over something like ~/.zigup on Linux and if we did use that it seems incoherent to me if XDG_DATA_HOME/zigup was not the default install directory, but once we have a config file there could easily be a use-xdg config option if you wanted to keep the default elsewhere.

A few notes about windows, I think %LOCALAPPDATA% would be a more appropriate location for windows than %APPDATA%. Also I'm not convinced we should be changing the current solution on windows. If you want your compilers to go into an app data directory, you can already put your zigup.exe in the appdata folder. Or you can also create a zigup.bat script and put that anywhere in your PATH and add the --install-dir option, although, I realize some people may find this overly cumbersome.

I'll rework this PR, probably to just add XDG support for macOS and Linux, and leave Windows for someone more familiar with the conventions and any possible use of resources if we go for runtime config options.


CAMEL-14027 Update to fix the NettyHttpStreamTest to release the buffer

https://issues.apache.org/jira/browse/CAMEL-14027

Is it only the unit test that has a problem? I assume if you use this in a production use-case then camel-netty-http wont have a leaking buffer problem?

From a first analysis this comes from the getcontent on the request set on the body

So, I think this will fix the test, but the problem seems to be at higher level in the component.

@davsclaus from DefaultNettyHttpBinding.toCamelMessge(FullHttpRequest), it retain the content. So it's the consumer's responsibility to release the body.

It looks like we need to release this body on the exchange completion ? Does it make sense ?
answer.setBody(request.content().retain());
exchange.addOnCompletion(new SynchronizationAdapter() {
                @Override
                public void onDone(Exchange exchange) {
                    ReferenceCountUtil.release(request.content());
                }
            });

please hold the PR and I'm testing locally to verify the above changes. Thanks !

Yes, @zhfeng, I think it would make sense to do this inside the component.

@oscerd OK, I made the changes to release the content inside the component.

+1 thanks for getting to the bottom of this

Ok. I'll merge tomorrow

thx merged.


orderBy() and with() eager loading

Hello,
I am trying to get to work orderBy() and eager loading together.
It works for me using your example, but currently my query looks like this
Item::whereIn('category_id', $categories_to_show)->with('defVariant')->paginate(16);

When I tried to order it, i was using this:
Item::join('item_translations as t', 't.item_id', '=', 'items.id')
            ->where('locale', \App::getLocale())
            ->whereIn('category_id', $categories_to_show)
            ->groupBy('items.id')
            ->orderBy('t.title')
            ->with('translations')
            ->with('defVariant')
            ->paginate(16);

Problam is that now the defVariant (which is a relationship in Item) is null.
I tried different places where is specified ->with('defVariant')but can't find a solution.
Can you please help me?

Hello mate, this is a question unrelated to the package. I would love to be able to answer to your question but my time is limited.
If somebody else wants to give it a further look that's fine by me. Otherwise I suggest you give a try to the laravel slack channel or to the forums.
Tip: convert your eloquent code to real mysql and see if this sql represents what you want to do.


New distributive rpm

Fixes #633, #717, #740, enables #793.
We will need to switch to CiscoCloud Bintray before merging.
Tested on Vagrant.

Successfully installed on:
Vagrant
AWS

Openstack installation:
The UI display says:
Checks: Unknown
No Health Checks loaded

With this version, I am seeing failing checks on all control nodes for the following two services:
distributive-marathon-checks
time="2016-01-22T01:25:13Z" level=info msg="Creating checklist(s)..." path="/etc/distributive.d/marathon.json" type=file
time="2016-01-22T01:25:13Z" level=fatal msg="Invalid check ID" id=

distributive-mantlui-checks
time="2016-01-22T01:18:35Z" level=info msg="Creating checklist(s)..." path="/etc/distributive.d/mantlui.json" type=file
time="2016-01-22T01:18:35Z" level=info msg="Running check File"
time="2016-01-22T01:18:35Z" level=info msg="Running check DockerImageRegexp"
time="2016-01-22T01:18:35Z" level=info msg="Running check PortTCP"
time="2016-01-22T01:18:35Z" level=info msg="Running check PortTCP"
time="2016-01-22T01:18:35Z" level=info msg="Running check File"
time="2016-01-22T01:18:35Z" level=info msg="Running check File"
time="2016-01-22T01:18:35Z" level=info msg="Running check File"
time="2016-01-22T01:18:35Z" level=info msg="Report from checklist" checklist="mantlui health checks" report="↴\nTotal: 7\nPassed: 6\nFailed: 1\nOther: 0\nNo such file or directory: /etc/mantlui.nginx"

(/etc/mantlui.nginx no longer exists as of #955)

also, once this is ready, should we just move it to the asteris bintray? A lot of our packages live there.

Thanks for testing @ryane, I'll update the package and this PR.

Rebased onto master, removed all marathon checks in preparation for adding them to the Marathon package. Works for me on Vagrant, needs further testing.

Rebased and squashed, ready for testing! Works for me on Vagrant.

I am getting this failure on all nodes (aws):
time="2016-02-01T21:34:22Z" level=info msg="Creating checklist(s)..." path="/etc/distributive.d/common.json" type=file
time="2016-02-01T21:34:22Z" level=info msg="Running check Symlink"
time="2016-02-01T21:34:22Z" level=info msg="Running check Installed"
time="2016-02-01T21:34:22Z" level=info msg="Running check Installed"
time="2016-02-01T21:34:22Z" level=info msg="Running check SystemctlUnitFileStatus"
time="2016-02-01T21:34:22Z" level=info msg="Running check Installed"
time="2016-02-01T21:34:22Z" level=info msg="Running check Installed"
time="2016-02-01T21:34:22Z" level=info msg="Running check Directory"
time="2016-02-01T21:34:22Z" level=info msg="Running check File"
time="2016-02-01T21:34:22Z" level=info msg="Running check CPUUsage"
time="2016-02-01T21:34:22Z" level=info msg="Running check MemoryUsage"
time="2016-02-01T21:34:22Z" level=info msg="Running check DiskUsage"
time="2016-02-01T21:34:25Z" level=info msg="Report from checklist" checklist="common health check" report="↴\nTotal: 11\nPassed: 10\nFailed: 1\nOther: 0\nUnit file could not be found: firewalld.service"

I think I see the problem. I'll try again. Thanks once again @ryane!

Successful installation on:
Vagrant

Tested, working on Openstack

+1 on aws


[REF] :recycle: Refactor exception controller

Signed-off-by: CChemin<EMAIL_ADDRESS>

should catch Method not supported 405 (maybe other forgotten spring exception)


fix: Message options doesn't appear in virtualized message list

🎯 Goal
🛠 Implementation details
Provide a description of the implementation
🎨 UI Changes
Add relevant screenshots

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix issue that prevents manipulation of overloaded Eloquent model JSON columns

Hello Laravel Team!
This is a follow up to my previous pull request, #25854. Some of the fine folks in the ShiftyCoders slack channel said not to get discouraged and to give it another shot, so here I am!
There was a valid concern about the memory usage in the library, which I have addressed. I have included those changes in this pull request and would like to reopen a discussion about solving this problem.
I wont copy/paste all the details of the former pull request as everything was pretty well documented there, but here is the gist of it:
Lets say you have this code:
$myModel = MyModel::find($n);
$myModel->json_column->some_key = 'some value';

Before this pull request you will get this result:
// PHP Notice:  Indirect modification of overloaded property App/MyModel::$json_column has no effect in...

With this pull request, that operation is perfectly valid and will modify that column as if it were a native PHP object or array.
I look forward to the discussion on this!

I can't find a test specifically about this new feature or did I miss it? (looked at the PRs, just looks like a copypasta about the same mechanism like the other casts).

Huh, well that's embarrassing. Thanks for pointing that out.
I added a test for that in that last commit.

There are no plans to add this to the core.


Handle non object body parameters

Fix for #66.

There can be at most one body parameter according to the Swagger spec (http://swagger.io/specification/). I think getting the value from the body parsed as dict is wrong.
There can be one "body" parameter at most.

Looks better :+1:


sddm: fix missing X server logs

Motivation for this change
After d84741a4bfb6ed2531ec7154479c147d2c9a737c xorg logs were silently discarded, as sddm doesn't support redirecting xserver logs (we'd need /dev/stderr here) or talking to journal yet.
So, until sddm/sddm#539 is done as a temporary workaround we can wrap xserver called by sddm in systemd-cat.
Things done

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

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Also maybe we should cherrypick this to 16.09 and nixos-unstable?

Tested locally -- it works nice for me. Thanks!


Field naming policy updated to use guava's case format

Fixes - https://github.com/Microsoft/thrifty/issues/163.
There are 2 paths:

If the thrift naming matches a CaseFormat, convert it to Lower_camel and handle acronyms.
Otherwise, just follow the existing code path.

The CaseFormat detection is taken from https://github.com/google/guava/issues/2212

Not sure if you want one commit for each comment or squashed ones. I can take care of it from the next time.

Codecov Report

Merging #165 into master will decrease coverage by 0.04%.
The diff coverage is 76%.

@@             Coverage Diff              @@
##             master     #165      +/-   ##
============================================
- Coverage     66.09%   66.05%   -0.05%
- Complexity     1011     1016       +5
============================================
  Files            90       90
  Lines          5271     5302      +31
  Branches        612      627      +15
============================================
+ Hits           3484     3502      +18
- Misses         1526     1530       +4
- Partials        261      270       +9

Impacted Files
Coverage Δ
Complexity Δ

...om/microsoft/thrifty/schema/FieldNamingPolicy.java
79.41% <76%> (-20.59%)
8 <7> (+6)

...in/java/com/microsoft/thrifty/schema/Location.java
73.17% <0%> (-2.44%)
14% <0%> (-1%)

...om/microsoft/thrifty/gen/ThriftyCodeGenerator.java
64.01% <0%> (-0.46%)
68% <0%> (ø)

Continue to review full report at Codecov.

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

Thanks for the fixes.  Github handles squashing on merge; no extra work for either of us!


Error in apply_image function?

In the apply_image function here  . , the expected input is HxWxC in order to use get_preprocess_shape to work.
However to_pil_image is called on this same input but it expects CxHxW. So it seems there is a permutation of axis missing in this function between the get_preprocess_shape and to_pil_image steps?

It's very odd code, but I think the assumption is that the input is from coming from opencv, which uses HxWxC ordering, and also BGR ordering on the channels which is accounted for when setting the image.
The to_pil_image seems to be used specifically to match the resize function requirements, which wants a shape ending in HxW and a data type of a tensor or a PIL image. Given that the function returns an np.array, it probably would've been simpler to use cv2.resize, but maybe they were trying to maintain consistency with some other implementation.

Thank you @heyoeyo, you answer made me realize I had an older version of torchvision (0.15.2) for which the to_pil_image function was not compatible...


CUDA device is too old??

I've been having this problem where when I try to check the cuDDN it would tell me that my CUDA device is too old, I'm running a GTX 650 Ti and it supposedly supports compute capability 3.0 and would run the program with my graphics card but it's not. and now in confused, I did try to change then cuDDN dll and installed NVIDIA Toolkit but to no avail.
help...

My graphics card is a GTX650 (GK107) and waifu2x-caffe (v<IP_ADDRESS>) crashes when I try to run the cunet model using cuda.


⚠ Bofrost.lu has degraded performance

In a6e90ae, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1102 ms

Resolved: Bofrost.lu performance has improved in c74286a.


API-13875 remove modify test

Address https://vajira.max.gov/browse/API-13875
Removes the modify test in the the regression test suite
Note that the removed test didn't exercised the ModifyAttack from saml-utils

Confirmed in debug runs

The modify test has been passing the last several regression test runs.  Recommend closing this PR for now.


DropShadowFilter does not blur properly

I want to create a nice dropdown shadow like this

But the shadow has what it seems a bounding box and does not blur out properly.
Is there a way to overcome this issue ?
https://jsfiddle.net/joerithegreat/3qoke6jn/

Try manually adding padding: https://jsfiddle.net/3m7tekqc/
I think the _updatePadding function in the filter isn't considering the quality which has an effect, but manually setting the padding should override.

@JoeriTheGreat for general support, please consider opening a discussion describing what you're trying to achieve. I'm going to close this issue since the initial query has been addressed.


Problems creating service fabric projects after installing Service Fabric SDK and Tools 3.1.269 and Service Fabric runtime 6.2.269

Creating new service fabric application projects in VS use the versions 3.1.269 and 6.2.269 for nuget dependencies, but the nuget server doesn't know them. It still somewhat works for the .net framework, but completely breaks it for .net core.

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

ID: 23e79576-36ff-8e39-9d21-adc897608b73
Version Independent ID: bb904115-2166-6871-6347-0941dbb32d2a
Content: Set up a Windows development environment for Azure microservices
Content Source: articles/service-fabric/service-fabric-get-started.md
Service: service-fabric
GitHub Login: @rwike77
Microsoft Alias: ryanwi, mikhegn

@bgiftge Thanks for the feedback! We are currently investigating and will update you shortly.

@bgiftge I am not seeing any issues in my local environment. Can you elaborate more for us? Possibly share some screenshots if possible.

It seems the issue was fixed: https://www.nuget.org/packages/Microsoft.ServiceFabric/6.2.269 was uploaded 3h ago

@bgiftge ah great! :) Let me know if you have any additional issues.


Stop responsive behaviour

Is there any way that you can add an option to stop the responsive behaviour?

Do you mean remove the code that runs on window.resize?

Yes, but I didn't remove it altogether. An option to disable it would be great.

Yeah - I shall add an option a.s.a.p.

Also, can we use this plugin commercially?

That's really cool!
Glad to see the script in use...
Regards,
Brian.
P.S. That's also a really, really nice theme.
On Thu, Jan 12, 2012 at 10:51 AM, Ant Eksiler <
<EMAIL_ADDRESS>
wrote:

Thanks alot, I used your plugin as a shortcode here:
http://www.turkhitbox.com/themes/?theme=ux
Click on Frontpage - No Slider
Users can enter their own slab text using a shortcode like this:
[slabtext]
[slab]For one night only[/slab]
[slab]Jackie Mittoo[/slab]
[slab]with special Studio One guests[/slab]
[slab]Dillinger [fancyamp] Lone Ranger[/slab]
[/slabtext]

Reply to this email directly or view it on GitHub:
https://github.com/freqdec/slabText/issues/1#issuecomment-3460636

Thanks Brian :)


compute: support BackendServices

For #1073
This implements Backend Services, known here as "services".
To Dos

[ ] Tests

[x] System
[ ] Unit

[ ] compute/index
[ ] compute/service

var service = compute.service('service-name');

service.getHealth(function(err, status) {
  status = [
    {
      ipAddress: '...',
      instance: '...',
      healthState: '...',
      port: '...'
    }
  ]
});

@callmehiphop I'm going to start on the unit tests, but let me know if you catch anything weird with the code.

don't merge lifted!

Is there a docs preview for this?

Docs preview up: http://stephenplusplus.github.io/gcloud-node/#/docs/master/compute/service
RE: the missing callback param docs, that was an intentional decision back when we introduced the famous "get or create" overhaul. While having multiple methods to get at the same data can be convenient, the consequence was having to write the exact same documentation in multiple places. That has some hazardous side effects if the code is updated with a docs change local to the source method, the branched methods that reference it would go out of date. The chosen path was simply to have a link back to the source method from the branched methods and let the example do a quick and dirty job of showing what will happen in your callback. If you have any ideas how we can improve on this, open an issue so we can :hash: it out!

Thanks for the preview! I think we need to add BackendServices to the site navigation via toc.json!

This might not be the place for it, but are there are any JSDoc tags (aside from link) that would allow us to inherit the documentation from one method to another?

Not that I know of. Possibly the callback can be a "type" that we can then reference? I'm not sure if that's real / a hack usage.


feat(tier4_perception_launch): add radar launcher

Signed-off-by: scepter914<EMAIL_ADDRESS>Description
Add radar fusion launcher.
Related links

Tests performed

Notes for reviewers

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

@scepter914 pls resolve conflict

Fix conflict


Allow entities to be automatically instantiated using optional controller annotations

I'm open to suggestions on names for the annotations.
@Form -> build entity from request parameters
@Body -> body entity from request body
@Param -> named request parameter
@ParamPattern -> currently used for handling deserialization of dates
Maybe those are good enough but perhaps...

@Param should be @Named ?
@ParamPattern should be @Pattern ?

I know that this feature is important for you and I will try to promote/integrate it. I reviewed javax.ws.rs (jersey) to see if I found something interested related to this PR (annotation names, ...). My opinion is that are many annotation (I speak about javax.ws.rs) to model a very trivial thing. Look at jersey api and you will see a lot of *Param annotations, DefaultValue just for a simple conversion.
My feeling is that with all these annotations I cannot resolve all my cases (maybe 80-90% but not all).
So, I am OK with your annotations. Maybe @Form is not that exactly (it's like BeanParam from javax.ws.rs) and pattern can be an option  parameter for @Param.
I think that @Named is not ok because I can have a conflict javax.inject.Named.


Get rid of all build warnings

Description

163 Build warnings
Add missing function documentations
fix // TODO (or create issues for it)
Import frameworks when needed (Xcode 15)
To Reproduce
Build
Expected behavior
Minimal warnings
Version information
Aurora Editor: 1.0 (1)
Commit: da21fa5372d5b51f9d5afe03534a4eef28d8ed59
MacOS: 14.0 (23A339)
Xcode: 15.0 (15A240d)
Additional context
No response

Closing this, as we have an ever higher amount of warning because we have deprecated some modules for a (complete) rewrite for version control and themes.


DuckDB v0.10.2: Error when creating DuckDB connection

I have deployed a Docker instance of Metabase alongside DuckDB driver. Have used the template given in the documentation and tweaked it to use the latest metabase.jar and the latest duckb.metabase-driver.jar file for creating the custom docker image. When I deploy the stack with DuckDB v 0.10.2, I get the following error related to MotherDuck token with error message: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null

When cross-checking from the change logs, it confirms the MotherDuck token is not a required field. Pasting any random value is also not working.
When I reproduce the same, but with the duckdb.metabase-driver.jar with DuckDB v0.10.0. I am able to successfully establish the connection and use Metabase along with DuckDB drivers.
metabase.jar: https://downloads.metabase.com/v0.49.13/metabase.jar
Dockerfile for building custom image
FROM openjdk:19-buster

ENV MB_PLUGINS_DIR=/home/plugins/

COPY ./metabase.jar /home/
COPY ./duckdb.metabase-driver.jar /home/plugins/

RUN chmod 744 /home/plugins/duckdb.metabase-driver.jar

CMD ["java", "-jar", "/home/metabase.jar"]

Edit: Replaced site redirect with direct download link for metabase.jar

duckdb.metabase-driver.jar (v0.10.0): https://github.com/AlexR2D2/metabase_duckdb_driver/releases/tag/0.2.6

is your use case to open an in-memory duckdb? If so can you try setting the Database File field to:memory:? I'll add some handling for the empty string case.

Yes, my use case is querying parquet files stored on server/S3 by using an in-memory duckdb on metabase.
Setting the field to :memory: works. Thanks.
Maybe just updating the placeholder for info /home/you/the.duckdb (or empty for 'in memory' mode) to /home/you/the.duckdb (or :memory: for 'in memory' ) should do it.


#21355 Adding license info to kotlin-dsl-plugin

Fixes #21355
Context
Check #21355
Contributor Checklist

[X] Review Contribution Guidelines
[X] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[X] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[X] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team

Gradle Core Team Checklist

[x] Verify design and implementation
[ ] Verify test coverage and CI build status
[x] Verify documentation

@bot-gradle test and merge

@bot-gradle test and merge

Error while scheduling pre-tested commit, please contact the administrator.

@bot-gradle test and merge

I've triggered a build for you.


Forwarding "Host" header breaks static-pages

I've just started forwarding the Host header through CloudFront because I want my pages to know their own domain when they are being rendered on the server. I've found that this causes pre-rendered pages behind static-pages/... to break because the request now has an invalid signature due to the host header being changed.
I was able to fix this by explicitly setting the header in the default-handler as seen in this AWS example:
    if (isHTMLPage) {
      request.uri = uri + ".html";
    }

is now
    if (isHTMLPage) {
      request.headers["host"] = [{ key: "host", value: s3Origin.domainName }];
      request.uri = uri + ".html";
    }

This will be fixable by the custom lambda handler when it is eventually implemented, or you might want to add this line. I'm not sure. I've just opened this to track the issue.

Good catch @stan-sack. I'm pretty sure is safe (probably best) to manually set the header when forwarding to S3. Feel free to PR 🙏 and I'll get it reviewed and merged ASAP.

Solved in https://github.com/danielcondemarin/serverless-next.js/pull/412


gorocksdb error

I receive the following error code. So how can I resolve about this
CGO_CFLAGS=" " CGO_LDFLAGS="-lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy" go build
github.com/hyperledger/fabric/vendor/github.com/tecbot/gorocksdb
../vendor/github.com/tecbot/gorocksdb/backup.go:4:24: fatal error: rocksdb/c.h: No such file or directory
// #include "rocksdb/c.h"

I had to install directly into the vagrant box the following packages (via apt-get install <package>):

librocksdb-dev
libsnappy-dev
libbz2-dev

I have then been able to run successfully the target membersrvc. Shouldn't these packages be installed as part of the make rule if they're needed?

If you've installed https://github.com/facebook/rocksdb by running make shared_lib and sudo make install, you don't have to set any flags when building your own project. The libs should be already on their places and Go will find them.

This can be closed as far as I can tell. Because the embed option has been removed.


Fails to create a mermaid diagram - mxMermaidToDrawio is not defined

Preflight Checklist

[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug
Trying to create a diagram in drawio using the mermaid syntax fails with the following error:
mxMermaidToDrawio is not defined
I have also attached a screenshot of the error message.
To Reproduce
Steps to reproduce the behavior:

Create a new blank drawio page
Click on "Arrange" -> "Insert" -> "Advanced" -> "Mermaid"
Use existing template for mermaid diagram
Click "Insert"
See error

Expected behavior
Expected to have a rendering of the mermaid diagram inside the drawio canvas
Screenshots
If applicable, add screenshots to help explain your problem.

draw.io version used: 11.1.2

Desktop

OS: [Ubuntu 20.04.6 LTS]
Browser [Mozilla Firefox for Ubuntu]
Version [111.0.1 (64-bit)]

Additional Information
Also trying to import some diagrams from this page:
https://www.diagrams.net/blog/mermaid-diagrams
fails with the same error.
For example trying to import the Sequence Diagram, Flow Chart, UML Class diagram gives the same error.
Importing the Gantt and the Pie chart seems to work however.

Can you please use the latest version, we've fixed this error in v21.0.4 (and it was introduced around 20.8.x)
To update, use https://app.diagrams.net/clear.html

@AndreeaRadoescu Is this draw.io online or confluence DC?

This is via confluence (I think DC). Basically creating a drawio diagram inside confluence.

What is your Confluence draw.io version?
Can you please update to the latest version?

Opening the draw.io via Confluence, going to Help -> About draw.io -> shows that the version is 11.1.2.
Unfortunately I cannot update the confluence draw.io version, I don't have access to do that.
But if we update the Confluence draw.io would the problem be gone?

Oh, 11.1.2 is the latest version. So, it maybe a caching issue.
Can you please try again in incognito/private window?

Hi there. I tried again in an incognito window but unfortunately it did not work. Basically went to Confluence -> login -> add a new "draw.io Diagram" -> redirected to draw.io app -> Insert -> Advanced -> Mermaid.

Hi,
Thanks for the detailed info. I managed to reproduce the issue.
We'll have a fix in the next release. Currently, as a workaround, please use the online version (http://app.diagrams.net) then copy the generated image (using keyboard Ctrl+C) and paste in Confluence (Ctrl+V)
Thanks

BTW, the fix is released in v11.1.3
Thanks


The test for IMERG Late_V06B is broken

The testcase contains files like 201905/3B-HHR-L.MS.MRG.3IMERG.20190530-S003000-E005959.0030.V06B.HDF5.
After  pull request #492,  LIS now tries to read files named 201905/3B-HHR-L.MS.MRG.3IMERG.20190530-S003000-E005959.0030.V06B.RT-H5.
Our project disk does not contain Late_V06B data for 201905.
@dpsarmie would you please retest and repackaged the IMERG Late_V06B testcase?
Thanks.

Yes, I'll take care of it.

Thanks!


[WIP] Adding missing UTs files for later fix

Will update the description later after discussing with @girishramnani

looks better now
$ make test-coverage
./scripts/generate-coverage.sh
?   	github.com/openshift/odo/cmd/cli-doc	[no test files]
?   	github.com/openshift/odo/cmd/odo	[no test files]
ok  	github.com/openshift/odo/pkg/application	1.084s	coverage: 18.4% of statements
ok  	github.com/openshift/odo/pkg/application/labels	1.012s	coverage: 100.0% of statements
ok  	github.com/openshift/odo/pkg/auth	1.256s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/catalog	1.087s	coverage: 60.8% of statements
ok  	github.com/openshift/odo/pkg/component	0.046s	coverage: 25.7% of statements
ok  	github.com/openshift/odo/pkg/component/labels	1.011s	coverage: 100.0% of statements
ok  	github.com/openshift/odo/pkg/config	1.046s	coverage: 51.9% of statements
ok  	github.com/openshift/odo/pkg/debug	1.076s	coverage: 51.9% of statements
ok  	github.com/openshift/odo/pkg/devfile	1.022s	coverage: 43.8% of statements
ok  	github.com/openshift/odo/pkg/devfile/adapters	1.035s	coverage: 15.4% of statements
ok  	github.com/openshift/odo/pkg/devfile/adapters/common	1.022s	coverage: 100.0% of statements
?   	github.com/openshift/odo/pkg/devfile/adapters/kubernetes	[no test files]
ok  	github.com/openshift/odo/pkg/devfile/adapters/kubernetes/component	1.046s	coverage: 37.8% of statements
ok  	github.com/openshift/odo/pkg/devfile/adapters/kubernetes/storage	1.040s	coverage: 66.7% of statements
ok  	github.com/openshift/odo/pkg/devfile/adapters/kubernetes/utils	1.034s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/devfile/parser	1.041s	coverage: 60.0% of statements
ok  	github.com/openshift/odo/pkg/devfile/versions	1.012s	coverage: 100.0% of statements
ok  	github.com/openshift/odo/pkg/devfile/versions/1.0.0	1.009s	coverage: 0.0% of statements [no tests to run]
?   	github.com/openshift/odo/pkg/devfile/versions/common	[no test files]
ok  	github.com/openshift/odo/pkg/envinfo	1.023s	coverage: 67.0% of statements
ok  	github.com/openshift/odo/pkg/kclient	1.047s	coverage: 45.7% of statements
ok  	github.com/openshift/odo/pkg/lclient	1.025s	coverage: 57.4% of statements
ok  	github.com/openshift/odo/pkg/log	1.011s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/log/fidget	1.010s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/machineoutput	1.016s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/notify	1.011s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/occlient	6.157s	coverage: 56.5% of statements
ok  	github.com/openshift/odo/pkg/odo/cli	1.271s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/application	1.077s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/catalog	1.072s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/catalog/describe	1.073s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/catalog/list	1.077s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/catalog/search	1.076s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/catalog/util	1.067s	coverage: 36.4% of statements
ok  	github.com/openshift/odo/pkg/odo/cli/component	1.078s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/component/ui	1.077s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/config	1.071s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/debug	1.078s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/login	1.268s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/logout	1.077s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/preference	1.080s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/project	1.075s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/service	1.088s	coverage: 15.0% of statements
ok  	github.com/openshift/odo/pkg/odo/cli/service/ui	1.078s	coverage: 41.7% of statements
ok  	github.com/openshift/odo/pkg/odo/cli/storage	1.075s	coverage: 3.9% of statements
ok  	github.com/openshift/odo/pkg/odo/cli/ui	1.017s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/url	1.080s	coverage: 0.0% of statements [no tests to run]
ok  	github.com/openshift/odo/pkg/odo/cli/utils	1.078s	coverage: 5.3% of statements
ok  	github.com/openshift/odo/pkg/odo/cli/version	1.072s	coverage: 0.0% of statements [no tests to run]
?   	github.com/openshift/odo/pkg/odo/genericclioptions	[no test files]
ok  	github.com/openshift/odo/pkg/odo/util	1.065s	coverage: 1.1% of statements
ok  	github.com/openshift/odo/pkg/odo/util/completion	1.094s	coverage: 38.3% of statements
ok  	github.com/openshift/odo/pkg/odo/util/experimental	1.021s	coverage: 88.9% of statements
ok  	github.com/openshift/odo/pkg/odo/util/pushtarget	1.026s	coverage: 83.3% of statements
ok  	github.com/openshift/odo/pkg/odo/util/validation	1.023s	coverage: 84.3% of statements
ok  	github.com/openshift/odo/pkg/preference	1.034s	coverage: 70.9% of statements
ok  	github.com/openshift/odo/pkg/project	1.070s	coverage: 59.5% of statements
ok  	github.com/openshift/odo/pkg/secret	1.069s	coverage: 94.4% of statements
ok  	github.com/openshift/odo/pkg/service	1.077s	coverage: 75.7% of statements
ok  	github.com/openshift/odo/pkg/storage	1.093s	coverage: 52.7% of statements
ok  	github.com/openshift/odo/pkg/storage/labels	1.011s	coverage: 100.0% of statements
?   	github.com/openshift/odo/pkg/sync	[no test files]
ok  	github.com/openshift/odo/pkg/testingutil	1.022s	coverage: 16.0% of statements
?   	github.com/openshift/odo/pkg/testingutil/filesystem	[no test files]
ok  	github.com/openshift/odo/pkg/url	1.071s	coverage: 40.5% of statements
ok  	github.com/openshift/odo/pkg/url/labels	1.010s	coverage: 100.0% of statements
ok  	github.com/openshift/odo/pkg/util	1.058s	coverage: 50.6% of statements
?   	github.com/openshift/odo/pkg/version	[no test files]
ok  	github.com/openshift/odo/pkg/watch	27.161s	coverage: 81.1% of statements
The command "make test-coverage" exited with 0.

/retest

/retest

Is this good to go @amitkrout or still WIP?

ping @amitkrout is this still WIP?

@amitkrout Are you actively working on this? It's been a long time in the pr pool, If its not that important ATM you can close this pr and later you can reopened with more content and work on it.

@amitkrout Are you actively working on this? It's been a long time in the pr pool, If its not that important ATM you can close this pr and later you can reopened with more content and work on it.

You are right, I ma closing this atm