More metadata

When archiving with --include-meta and --include-episode-meta some of the metadata of the podcast and its episodes are saved. The set that is currently saved is only a subset of all the available metadata though, and I'd like to increase this.
It would be trivial to just include all metadata (probably excluding the items listing for the podcast metadata), and I'd totally be happy with that as a solution, but I wanted to try and make it a bit more flexible.
This draft adds two new flags, --include-meta-fields and --include-episode-meta-fields. As their names suggest these can be used to indicate which extra fields should be included. They can be used multiple times, have simple globbing support (foo*), and support negation (!foobar).
This does not handle filtering on nested keys yet. I didn't realize that properties like itunes:subtitle resulted in a nested structure when making my original design. I can fix this, but I wanted to get some feedback on this before investing more time into it.
A few questions from my side:

Would you be interested in functionality to include more metadata?
If so, are you interested in the approach I have chosen (flags to specify what to include), or would you want to go for a simpler include-all, or something else entirely?
If so, do you have any feelings regarding how to handle nested keys? I'm leaning towards the following:

When encountering an object, don't apply the filter to the object itself but instead process it's contents. If any of its contents are to be included the (subset) of the object will be included, and otherwise it will be left out entirely.
When checking the filter for nested keys combine the keys with those of their parent(s). For example, itunes: { subtitle: "foo" } would result in a key of itunes.subtitle which would then be checked against the filter.
Change * to match anything but ..
Add ** that doest match anything, including ..

This way one could easily include everything by passing **, or only non-object properties by passing *, or perhaps all itunes properties by passing itunes.**, etc.

I like the idea of putting the old behaviours into the defaults for this flag. This would even allow people to exclude the current defaults if they so desire (with a simple !*), which is pretty neat, and I'm always for more flexibility. There is one minor problem with this though: the descriptionText field in the current episode metadata comes from the contentSnippet field from the feed. All other fields in the metadata match the names from the feed itself, but that one does not.
We could fix this by adding some remapping functionality, so that a rule like contentSnippet as descriptionText or something similar would include the field under a different name. I wouldn't mind adding this, but I worry about the added complexity. Wouldn't want to turn this into something noone uses! Then again, being able to get exactly what you want in the structure you want it in does sound quite appealing. And it'd be an optional thing, so it wouldn't complicate the "normal" rules at all.
Aside from that, how do you envision the options working? Just adding some default rules wouldn't take away the need for the checks, since you could still add rules without enabling the core include-meta feature. Would you want to merge the options? Have specifying globs implicitly turn on the include-meta feature? Something else?

There is one minor problem with this though: the descriptionText field in the current episode metadata comes from the contentSnippet field from the feed. All other fields in the metadata match the names from the feed itself, but that one does not.

Oh! Good call. I'm totally up for switching it over to contentSnippet. I'll just make sure the mark the release correctly — I think it's worth it.

Aside from that, how do you envision the options working? Just adding some default rules wouldn't take away the need for the checks, since you could still add rules without enabling the core include-meta feature. Would you want to merge the options? Have specifying globs implicitly turn on the include-meta feature? Something else?

Similar to --archive, we can have --include-meta and --include-episode-meta optionally include arguments. If passed in without an argument, use the default selectors for the fields as before. And if passed in with field selectors, use those for grabbing the meta fields. What do you think? 😄

Oh! Good call. I'm totally up for switching it over to contentSnippet. I'll just make sure the mark the release correctly — I think it's worth it.

:+1:

Similar to --archive, we can have --include-meta and --include-episode-meta optionally include arguments. If passed in without an argument, use the default selectors for the fields as before. And if passed in with field selectors, use those for grabbing the meta fields. What do you think? smile

Sure, that works. If you pass a field selector, would you want to add to the defaults or override them? That is, should --include-episode-meta foo result in ['title', 'contentSnippet', 'pubDate', 'creator', 'foo'] or ['foo']? (Mind that if we go for the former you could still use --include-episode-meta '!*' --include-episode-meta foo to only get foo if that is what you want.)

I think option 2 makes the most sense to me: --include-episode-meta foo resulting in ['foo'].
Getting more and more excited to have this feature added. 💪

Should be functional now! No documentation yet, but I'll let you play around with it and see if you like it/manage to break it before we worry about that.

While preparing examples for the readme I noticed that the module used to parse the feed doesn't actually include all fields. Furthermore, for some of the fields that it does include it does so with a transformation of some kind (e.g. itunes:category results in itunes.categories and itunes.categoriesWithSubs).
This means that more work is needed to actually include all metadata. It also means that if we were to merge this as it currently is we're exposing these transformations the underlying module makes, which would make changing to another way of acquiring the full metadata a breaking change.
I have some ideas for potential solutions that I'll look into. I'll change this back to a draft for now until we have a solution of some sort.

I did some more work on this. I hooked into the parser to get access to the raw data from the feed while still allowing us to be mostly ignorant about the type of feed (Atom/RSS 0.9/RSS 1.0/RSS 2.0). This gets us access to the full data, but this is unfortunately not without issues.

The first problem is that the mapping from XML to JSON is... icky. It's an unfortunate but unavoidable artifact of mapping XML to JSON; XML allows a single tag to have attributes, child tags and contents, plus it allows repeating a tag (meaning anything is potentially an array), whereas in JSON each entry in an object can only be a single thing, and arrays are explicit even when they only have one entry. To capture all this complexity in JSON results in a rather verbose structure:

XML
<xml>
	<title>8-4 Play</title>
	<itunes:category text="Leisure">
		<itunes:category text="Video Games"/>
	</itunes:category>
	<itunes:category text="Technology"/>
   <podcast:locked owner="info@8-4.jp">no</podcast:locked>
</xml>

JSON
{
	"title": [
		"8-4 Play"
	],
	"itunes:category": [
		{
			"$": {
				"text": "Leisure"
			},
			"itunes:category": [
			{
				"$": {
					"text": "Video Games"
				}
			}
			]
		},
		{
			"$": {
				"text": "Technology"
			}
		}
	],
	"podcast:locked": [
		{
			"_": "no",
			"$": {
				"owner"<EMAIL_ADDRESS>			}
		}
	]
}

To aleviate this I've added an option to output to XML instead of JSON. This uses the same library that the RSS parsing library uses, so it round trips properly and it's not really a new dependency.

Another issue is that this exposes details of the underlying feed type to the metadata. This is unavoidable once you get into the full details, but it is a shame to lose out on the simple and uniform metadata we had previously.
The way I've handled this is by storing the raw data under the raw key in the feed/episode metadata. This way you can get access to it if you want to/need something that isn't in the normalized metadata without losing out on the benefits of a uniform format.

These changes add a bit more complexity when compared to the last version, but I've done my best to minimize the complexity while still offering a large degree of flexibility. Overall I'm relatively happy with the result. What do you think?

I think a lot of people are in the same camp as you and won't be interested in raw. It's not part of the default filters and it wouldn't even be included by a * rule, but we could certainly put it behind a flag.
We could even go a bit further and split this off into a separate metadata file. This could also somewhat alleviate the JSON mapping issue; we could stick to JSON for the normal metadata and use XML for the raw export. This would allow people like me who would like to have a dump of the raw metadata without burdening the JSON output. We could just keep this as a simple all-or-nothing flag without rules support.
Separately I think the customFields thing is worth exploring. I had seen this option but had disregarded it thus far since it didn't fit my use-case of wanting everything, but it would be good as an option for those that want specific extra bits of metadata. I'll create a basic implementation of this and then we can see how we like it and further refine it that way.
One concern I have which is worsened by the addition of customFields is that this is turning into a (potentially) unwieldy amount of CLI arguments. It might be worth considering an option to specify these rules/mappings in a separate file that can be referred to. This should probably be a separate PR, but I am curious what you think. Something similar to mocha.opts? A config file in JSON format?

Sorry for the long delay — I was AFK for quite a bit!
I think in an effort to not add too much complexity to the project, adding support for XML and additional parsing might best be supported as an additional script someone could run separately. A separate script that fetches the RSS feed and parses out the metadata one might want per episode would be much simpler and easier to adapt over time. I plan on adding a --include-feed param that will save the raw file into the output directly which then can be targeted by additional scripts.


Remove unused embeds from Prismic slice offer

Who is this for?
Maintenance
What is it doing for them?
We have a few legacy slices that we can get rid of (see analysis). This brings it down from a total 27 to 22!
This PR deals with vimeoVideoEmbed, instagramEmbed, twitterEmbed and soundcloudEmbed.
Danny has agreed to these four being removed as there are no instance of them anywhere on the website.
They have all replaced by Embed a while ago (even though Vimeo doesn't seem styled nicely, it works). Currently, only YouTube and SoundCloud items are being rendered by Embed.
Added later on
I've also removed youtubeVideoEmbed as it was labelled as Deprecated for a very long time. I've made sure all 21 instances now had an equivalent Embed. I can furnish the list if required.
Relates to #9917
Closes #9924
Next step
I'd like confirmation on this:
I think I'll need to run yarn deployType --id {vimeoVideoEmbed | instagramEmbed | twitterEmbed | soundcloudEmbed | youtubeVideoEmbed} locally, once this gets merged to main, and that's it?

Thanks for approving @alexwlchan !
Is my "Next step" theory correct? And should I run it after merging?

I think I'll need to run yarn deployType --id {vimeoVideoEmbed | instagramEmbed | twitterEmbed | soundcloudEmbed | youtubeVideoEmbed} locally, once this gets merged to main, and that's it?

Ah, no, I don't think that's quite correct.
The deployType command deploys entire types ("page", "article", "exhibition", etc.), whereas these are slices that get used by those types. So you need to run yarn deployType --id {page, article, exhibition, …}.
If you run yarn diffCustomType locally, it'll show you what types need deploying – this is the thing that runs in CI on main, and will fail if our model-in-code drifts from what's deployed in Prismic.

Ahh I see, it'll update the types because the slice offering will be different! That makes sense.
So is it better to run it only after it's merged to main?

it'll update the types because the slice offering will be different!

Exactly!

is it better to run it only after it's merged to main?

I don't have a strong opinion. The ideal time to run it is just before Buildkite runs the "check Prismic model" task on your merged commit – any other time, and there could be (1) builds to run that don't include your local changes or (2) your build will run but Prismic won't have the new types.
Personally I tend to deploy just before I merge to main, but I don't think it makes a big deal either way.


Caret movement hook on input.Handler doesn't call its hooks

Currently, all the hooks to update caret positions based on code changes are directly calling caret movement methods.  This means that the updated caret movement op (after having hooks bound to it) is not the op that is triggering off of edits.
This needs a little bit of a rethink.

Fixed with a bindable that looks up the op.


Establishing requirements for image selection from API to CMS

select image / image ID
select preferred view/crop
image licence and credit in caption
linking readers to source image

Evolved into #2382


Require latest phpstan to fix a couple of things

See https://github.com/phpstan/phpstan-src/pull/1016 where these things were fixed

Thank you!


Target melodic for master development

As per #24 there are a few missing connections that prevent the svenzva MoveIt config from launching in ROS melodic. This updates these missing pieces, so MoveIt can be run as expected.
kinetic development is still supported on the kinetic branch of this repository.

Updated rosdep entry for moveit is confirmed working. Merging.


feat(linter) improve span for no useless catch

closes #1719

Current dependencies on/for this PR:

main

PR #1729

PR #1730

PR #1731   👈

PR #1732

This stack of pull requests is managed by Graphite.

Merge activity

Dec 18, 8:20 AM: @@Boshen started a stack merge that includes this pull request via Graphite.


Panic when retaining tabs

Describe the bug
When retaining tabs in a dock state the program will panic if all tabs are removed from a node.
To Reproduce
Run this program and click the "filter tabs" button in the menu bar.
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")] // hide console window on Windows in release

use eframe::{egui, NativeOptions};

use egui_dock::{DockArea, DockState, NodeIndex, Style};

fn main() -> eframe::Result<()> {
    let options = NativeOptions::default();
    eframe::run_native(
        "My egui App",
        options,
        Box::new(|_cc| Box::<MyApp>::default()),
    )
}

#[derive(Clone)]
enum Tab {
    Stay,
    GoAway,
}

struct TabViewer {}

impl egui_dock::TabViewer for TabViewer {
    type Tab = Tab;

    fn title(&mut self, tab: &mut Self::Tab) -> egui::WidgetText {
        match tab {
            Tab::Stay => "Stay".into(),
            Tab::GoAway => "GoAway".into(),
        }
    }

    fn ui(&mut self, ui: &mut egui::Ui, tab: &mut Self::Tab) {
        match tab {
            Tab::Stay => ui.label("This tab will stay"),
            Tab::GoAway => ui.label("This hab will go away"),
        };
    }
}

struct MyApp {
    tree: DockState<Tab>,
}

impl Default for MyApp {
    fn default() -> Self {
        let mut tree = DockState::new(vec![Tab::Stay]);
        let [_left, _right] =
            tree.main_surface_mut()
                .split_left(NodeIndex::root(), 0.5, vec![Tab::GoAway]);
        Self { tree }
    }
}

impl eframe::App for MyApp {
    fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
        egui::TopBottomPanel::top("Top panel").show(ctx, |ui| {
            if ui.button("Filter tabs").clicked() {
                //self.tree = self.tree.filter_tabs(|tab| matches!(tab, Tab::Stay));
                self.tree.retain_tabs(|tab| matches!(tab, Tab::Stay));
            }
        });
        DockArea::new(&mut self.tree)
            .style(Style::from_egui(ctx.style().as_ref()))
            .show(ctx, &mut TabViewer {});
    }
}

This bug happens because in the retain method of a tree, all Node::Empty are removed from the tree. This breaks the binary tree.
A similar thing happens when filtering instead. There the binary tree is not destroyed but the Node remains in the empty state and is displayed as a black hole in the tree. See image:

Expected behavior
For starters, retaining tabs shouldnt break the binary tree. However, that still leaves empty nodes visible in the layout. It should be easy enought to properly remove empty nodes from the binary tree, but this only really works if you have access to the tree in the first place.
The retain_tabs method on Node does not have access to the tree and cannot properly remove itself once empty.
I see two ways to solve this:

Dont allow retain_tabs and filter_tabs on Nodes because it is not possible to properly restore the tree to a valid state.
Allow Node::Leaf to have no tabs. In this case we should display a dummy empty tab that is always closeable. Closing this tab will then correclty remove it from the tree. I think this is a really good solution actually because filtering would then no longer impact the layout of the tree. This allows you to first filter any unwanted tabs and then add new ones without changing the layout and invalidating any node indicies you might have.

Not related to this bug but probably a good time to think about it.
With #212 Node::Empty and possibly Surface::Empty will be removed. Depending on what solution we go with this would impact the api of filter_tabs, filter_map_tabs and retain_tabs for Node and Surface.


Moved all censor-related functions in a separate file.

As we talked about, I move what you made with go-away in a separate file. Once you merge this into main, I will do the same in the rustrict branch.

Looks good!


Make "Residual Power" Value configurable via UI

Problem
I would like to tune the residual power value on a daily basis depending on the charge state of my car and the current weather.
Solution
Please add residual power to the values which are configurable via the EVCC UI.
Alternatives
Currently I sometimes tune it via  the VS Code editor in my Home Assistant.
I also wrote a Home Assitant Automation once to configure the Resiudal Power value via a slider/text field on my Home Assistant dashboard.
Now that configurability is being improved, please also include this parameter.

Thats on the roadmap.


UNOMI-225 ElasticSearch 7 fix for changes in the total hits

Replaced total hits with count API requests when possible
For aggregations replaced with a manual sum of all buckets
Added in the PartialList the relation for the total hits so that users of the API can know if the total size is EQUAL or GREATER_THAN_OR_EQUAL_TO

Signed-off-by: Serge Huber<EMAIL_ADDRESS>

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/unomi-pr/83/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/unomi-pr/88/


Mobile order summary modal is extra tall

The container on the order summary below about 500px has a large gap when expanded.
To reproduce, proceed to checkout and open the order summary:

Hey @aAdams01 thanks for reporting this. Can you please provide more information on how to replicate this issue:

Is it an issue in embedded checkout or native checkout?
Does this happen on a particular mobile phone?

Hi @animesh1987,
We noticed this bug on native checkout. It is viewable on Android devices like the Pixel 6 Pro using the Chrome browser.

Hey @aAdams01 forgot to follow this up, we have rolled out some improvements to modal summary. Can you please confirm if this is still an issue for you? Thanks.

@animesh1987 looks like it is fixed! Thank you

Closing as resolved 🙇


NaN years ago

This app appears to be abandoned. Retracting.

@rex4539 this is not abandoned but upgraded to v2: https://github.com/esteemapp/esteem-mobile
We will soon archive this repo after officially depreciation of v1 from app stores.


x/build: investigate possibility of supporting Go tests that require use of Docker in trybots/builders

We would like the trybots to be able to run a docker container.
The discovery site needs a postgres database to run tests, and we've been starting it in our CI with docker run.
An alternative would be to install postgres in the trybot image, but that's probably more difficult and definitely less general.

/cc @cagedmantis @toothrot
IIRC it may have been @findleyr that had the same feature requests for x/tools trybots.

@jba Docker does not support every platform that Go supports and gets tested on. Is the scope of this feature request limited to a subset of GOOS/GOARCH pairs? For example, just linux/amd64 and potentially others?

If the target for the discovery site is always Docker, an alternative would be to configure a Cloud Build run to be able to publish Trybot results, rather than using the normal Trybots for this specific scenario.

Yep, I discussed this with Jonathan (thanks @jba for posting this issue).  I think this might not be possible with the current Trybot implementation. For example, exposing Docker probably means exposing sudoless docker, which comes with a bunch of security concerns.
Another option might be to integrate TryBot functionality with other CI tooling, for example Cloud Build. TryBots have many nice features (e.g. gating on Run-Trybots +1) that could perhaps be separated from the actual CI.

If you're using Cloud Build, it might not be necessary to gate Run-Trybots. Out of curiosity, what other features are you thinking of?

Perhaps, though I'd prefer still gating on Run-Trybots
Another feature is hosting artifacts in a public GCS bucket, and posting them back to the the CL (not something GCB does out of the box).

Could the trybots execute a gcloud command? Then we could use the trybot to trigger the GCB run.
That would give us gating, but not public artifacts.
It would imply that the trybots have some sort of GCP auth on them.


UI Preview does not work inside Android Studio

Describe the bug
UI Preview does not work inside Android Studio after adding a PainterResource inside commonMain/composeResources/drawable despite the project is being built successfully
Affected platforms

Android Studio on Mac

Versions

Compose Multiplatform Mobile Version : 0.8.2(233)-8
OS : Mac OS 14.5
JDK : 21

To Reproduce
Steps to reproduce the behavior:

Add a image or icon into a component
For e.g,

Icon(painterResource(Res.drawable.baseline_info_24), null)

Load Preview by going to AndroidMain's MainActivity

Expected behavior
Preview displaying normally
Screenshots
It should display like this inside preview (this is IOS Simulator)

But it is displaying like this inside Android Studio Preview

Additional context
None

Duplicate of #4932 (and #4476)

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Ubuntu 16.04 Makefile build

I was attempting to use the Makefile to test build the library on my Ubuntu system (bazel builds to completion).
uname -a -m
Linux gking-ml-vm 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Environment info
Operating System:
lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04 LTS
Release:	16.04
Codename:	xenial

Installed version of CUDA and cuDNN:
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
ls -l /path/to/cuda/lib/libcud*
ls: cannot access '/path/to/cuda/lib/libcud*': No such file or directory

If installed from sources, provide the commit hash:
git show
commit 6431560b7ec3565154cb9cdc9c827db78ccfebe7
Merge: a0085c8 b7c4169
Author: Vijay Vasudevan<EMAIL_ADDRESS>Date:   Tue Jun 7 11:32:10 2016 -0700

    Merge pull request #2710 from vrv/branch_124251558

    Branch 124251558

Steps to reproduce
1.)  bash tensorflow/contrib/makefile/download_dependencies.sh
2.) make -f tensorflow/contrib/makefile/Makefile all
Fails here: because protoc installed for Ubuntu 16.04 is 2.6.1;
make -f tensorflow/contrib/makefile/Makefile all
protoc  tensorflow/core/util/test_log.proto --cpp_out /home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/proto/
tensorflow/core/util/test_log.proto:2:10: Unrecognized syntax identifier "proto3".  This parser only recognizes "proto2".
tensorflow/contrib/makefile/Makefile:325: recipe for target '/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/proto/tensorflow/core/util/test_log.pb.cc' failed
make: *** [/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/proto/tensorflow/core/util/test_log.pb.cc] Error 1

3.) Even with an updated protoc build fails again:
gcc --std=c++11 -I/usr/local/include -I. -I/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/downloads/ -I/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/downloads/eigen-eigen-d02e6a705c30 -I/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/host_obj/ -c tensorflow/core/lib/strings/strcat.cc -o /home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/host_obj/tensorflow/core/lib/strings/strcat.o
In file included from tensorflow/core/lib/strings/strcat.cc:23:0:
./third_party/eigen3/Eigen/Core:1:47: fatal error: eigen-eigen-0c0b79ecd74c/Eigen/Core: No such file or directory
compilation terminated.
tensorflow/contrib/makefile/Makefile:350: recipe for target '/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/host_obj/tensorflow/core/lib/strings/strcat.o' failed
make: *** [/home/gking/Programming/tensorflow/tensorflow/contrib/makefile/gen/host_obj/tensorflow/core/lib/strings/strcat.o] Error 1

What have you tried?

Built a new version of protoc:

What I did (note the dependencies given to fpm aren't correct);:
wget https://github.com/google/protobuf/archive/v3.0.0-beta-3.tar.gz
tar xvzf v3.0.0-beta-3.tar.gz
cd protobuf-3.0.0-beta-3
./autogen.sh
./configure --prefix=/usr
make all
make ctags
make check
make install DESTDIR=/tmp/installdir
fpm -s dir -t deb -p protobufc_3.0.0-beta3_amd64.deb -n protobufc -v 3.0.0-beta3 -d "libgcc1 >= 1:4.1.1" -d "libstdc++6 >= 5.2" -C /tmp/installdir usr/bin usr/lib usr/include

After purging protobuf-compiler and other related packages I installed the new fpm built package (sudo dpkg --install protobufc_3.0.0-beta3_amd64.deb)
Logs or other output that would be helpful
(If logs are large, please upload as attachment).
EDIT: Added some additional details.

It looks like Eigen doesn't exist.  Might that be the problem?

I have libeigen3-dev installed through apt:
dpkg -s libeigen3-dev
Package: libeigen3-dev
Status: install ok installed
Priority: extra
Section: libdevel
Installed-Size: 5130
Maintainer: Ubuntu Developers<EMAIL_ADDRESS>Architecture: all
Source: eigen3
Version: 3.3~beta1-2
Depends: pkg-config
Suggests: libeigen3-doc, libmrpt-dev
Description: lightweight C++ template library for linear algebra
 Eigen 3 is a lightweight C++ template library for vector and matrix math,
 a.k.a. linear algebra.
 .
 Unlike most other linear algebra libraries, Eigen 3 focuses on the simple
 mathematical needs of applications: games and other OpenGL apps, spreadsheets
 and other office apps, etc. Eigen 3 is dedicated to providing optimal speed
 with GCC. A lot of improvements since 2-nd version of Eigen.
Original-Maintainer: Debian Science Maintainers<EMAIL_ADDRESS>Homepage: http://eigen.tuxfamily.org

However it appears that the download dependencies uses a different eigen hash. Below is from:
tensorflow/contrib/makefile/download_dependencies.sh (truncated output):
EIGEN_HASH=d02e6a705c30
curl "https://bitbucket.org/eigen/eigen/get/${EIGEN_HASH}.tar.gz" \
-o /tmp/eigen-${EIGEN_HASH}.tar.gz
tar xzf /tmp/eigen-${EIGEN_HASH}.tar.gz -C ${DOWNLOADS_DIR}

That hash looks different than from your message above, which says 0c0b79ecd74c.

Yup. So it looks like the Makefile build rules are finding the wrong header file to include while building.

@martinwicke Do we support the Makefile build actively, or is this contributions welcome?

FYI @petewarden
It's contributions welcome. Definitely since we cannot guarantee that a
different version of eigen will work at all. In fact it's quite likely it
will not (or work slowly).
On Wed, Jun 8, 2016 at 16:36 Geoffrey Irving<EMAIL_ADDRESS>wrote:

@martinwicke https://github.com/martinwicke Do we support the Makefile
build actively, or is this contributions welcome?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/2742#issuecomment-224762880,
or mute the thread
https://github.com/notifications/unsubscribe/AAjO_bBDHVepl5QBpiSamg8hinQtjQnuks5qJ1HxgaJpZM4IxdOc
.

Sorry about the problem! I have a pending PR at https://github.com/tensorflow/tensorflow/pull/2743 that fixes this particular issue. Longer-term, I want to automatically grab the checked-in Eigen version, maybe just by grepping the Bazel workspace file that holds the hash.

@petewarden I created a quick pull request that should fix this issue by grabbing the information from eigen.BUILD;

Closing the issue; should work properly now (provided you have a more recent version of protoc.


Grave Robbers not ending even after both relics are recovered

savegame:
game1.zip
I'm using the latest build 👍

Did you answer the distress call?

distress call? there is no cinematic or objective for it

Looks like a part of the code doesn't trigger unless you use the tug you start with.


Unavailable after upgrading Home Assistant to 2022.7

after updating Home Assistant, integration shows as unavailable.   I have deleted and readded the integration.
Firmware: 2.0.17
Hardware: WERT
Logger: homeassistant.components.sensor
Source: helpers/update_coordinator.py:331
Integration: Sensor (documentation, issues)
First occurred: 10:44:46 AM (2 occurrences)
Last logged: 10:44:47 AM
Error adding entities for domain sensor with platform victorsmartkill
Error while setting up victorsmartkill platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 397, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 641, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 775, in add_to_platform_finish
await self.async_added_to_hass()
File "/config/custom_components/victorsmartkill/entity.py", line 124, in async_added_to_hass
await super().async_added_to_hass()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 331, in async_added_to_hass
self.coordinator.async_add_listener(
TypeError: VictorSmartKillDataUpdateCoordinator.async_add_listener() takes 2 positional arguments but 3 were given
Logger: homeassistant.components.binary_sensor
Source: helpers/update_coordinator.py:331
Integration: Binary sensor (documentation, issues)
First occurred: 10:44:46 AM (2 occurrences)
Last logged: 10:44:47 AM
Error adding entities for domain binary_sensor with platform victorsmartkill
Error while setting up victorsmartkill platform for binary_sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 397, in async_add_entities
await asyncio.gather(*tasks)
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 641, in _async_add_entity
await entity.add_to_platform_finish()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 775, in add_to_platform_finish
await self.async_added_to_hass()
File "/config/custom_components/victorsmartkill/entity.py", line 124, in async_added_to_hass
await super().async_added_to_hass()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 331, in async_added_to_hass
self.coordinator.async_add_listener(
TypeError: VictorSmartKillDataUpdateCoordinator.async_add_listener() takes 2 positional arguments but 3 were given
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2022.7.1",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.10.5",
"docker": true,
"arch": "aarch64",
"timezone": "America/Chicago",
"os_name": "Linux",
"os_version": "5.15.32-v8",
"supervisor": "2022.07.0",
"host_os": "Home Assistant OS 8.2",
"docker_version": "20.10.14",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {
"victorsmartkill": {
"version": "2022.2.3",
"requirements": [
"victor-smart-kill==1.1.0"
]
},
"localtuya": {
"version": "4.0.1",
"requirements": []
},
"scheduler": {
"version": "v0.0.0",
"requirements": []
},
"watchman": {
"version": "0.5.1",
"requirements": [
"prettytable==3.0.0"
]
},
"netdaemon": {
"version": "22.05.0",
"requirements": [
"awesomeversion>=21.1.0"
]
},
"thermal_comfort": {
"version": "1.4.3",
"requirements": []
},
"weatheralerts": {
"version": "0.1.5",
"requirements": []
},
"garbage_collection": {
"version": "4.7.8",
"requirements": [
"python-dateutil>=2.8.2"
]
},
"weatherapi": {
"version": "0.8",
"requirements": []
},
"iphonedetect": {
"version": "1.4.0",
"requirements": []
},
"openweathermaphistory": {
"version": "1.0.5",
"requirements": []
},
"tuya_local": {
"version": "0.17.1",
"requirements": [
"pycryptodome~=3.14.1",
"tinytuya~=1.6.0"
]
},
"mass": {
"version": "2022.7.0b1",
"requirements": [
"music-assistant==1.6.0"
]
},
"hacs": {
"version": "1.25.5",
"requirements": [
"aiogithubapi>=22.2.4"
]
},
"nodered": {
"version": "1.0.8",
"requirements": []
}
},
"integration_manifest": {
"domain": "victorsmartkill",
"name": "Victor Smart-Kill",
"version": "2022.2.3",
"documentation": "https://github.com/toreamun/victorsmartkill-homeassistant",
"issue_tracker": "https://github.com/toreamun/victorsmartkill-homeassistant/issues",
"dependencies": [],
"config_flow": true,
"codeowners": [
"@toreamun"
],
"requirements": [
"victor-smart-kill==1.1.0"
],
"iot_class": "cloud_polling",
"is_built_in": false
},
"data": {
"config_entry": {
"entry_id": "860bfbf0b48ceae36f4b23128f34a24c",
"version": 1,
"domain": "victorsmartkill",
"title": "REDACTED",
"data": {
"username": "REDACTED",
"password": "REDACTED"
},
"options": {},
"pref_disable_new_entities": false,
"pref_disable_polling": false,
"source": "user",
"unique_id": "REDACTED",
"disabled_by": null
},
"data": {
"146708": {
"id": 146708,
"url": "https://www.victorsmartkill.com/traps/146708/",
"corruption_status": 0,
"corruption_status_options": null,
"operator": null,
"operator_name": null,
"name": "Garage1",
"ssid": "REDACTED",
"serial_number": "REDACTED",
"auto_upgrade": false,
"status": 0,
"location": "https://www.victorsmartkill.com/locations/108067/",
"lat": "REDACTED",
"long": "REDACTED",
"upgrade_firmware": null,
"commercial_gateway": null,
"commercial_monitor_mode_enabled": false,
"lorawan_app_key": "REDACTED",
"site_name": null,
"floor_plan_x": 0,
"floor_plan_y": 0,
"building_name": null,
"floor_name": null,
"room": null,
"room_name": null,
"trap_type": 1,
"trap_type_verbose": "Rat Trap",
"alerts": 256561,
"trapstatistics": {
"id": 146708,
"url": "https://www.victorsmartkill.com/trapstatistics/146708/",
"trap": "https://www.victorsmartkill.com/traps/146708/",
"trap_name": "Garage1",
"kills_present": 0,
"install_date": "2022-03-24T16:12:59.198428+00:00",
"owner_name": "REDACTED",
"owner_email": "REDACTED",
"last_report_date": "2022-07-08T14:37:32.876301+00:00",
"last_kill_date": "2022-04-30T11:17:53.842342+00:00",
"temperature": 0,
"battery_level": 31,
"total_kills": 3,
"total_escapes": 2,
"rx_power_level": -60,
"firmware_version": "2.0.17",
"trap_provisioned": true,
"last_sequence_number": null,
"total_retreats": null,
"wireless_network_rssi": -60,
"error_code": 0,
"send_conn_lost_nt": true,
"send_empty_trap_nt": true,
"board_type": "WERT",
"last_maintenance_date": "No maintenance records exist."
}
}
},
"last_exception": null
}
}

Same here...

I also have the same issue.

https://github.com/toreamun/victorsmartkill-homeassistant/releases/tag/2022.7.0

Awesome, thanks for fixing it so quickly!


vscode-ng-i18n-editor.openEditor not found

roman-lo.vscode-ng-i18n-editor: v0.2.2
Version: 1.50.0-insider
Commit: f943318042a3b9229049aea86cea04d0ff9c8210
Date: 2020-09-23T05:28:07.760Z
Electron: 9.3.0
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0
Command 'Angular I18n Editor: Open' resulted in an error (command 'vscode-ng-i18n-editor.openEditor' not found)

Can you show your workspace directory structure, and double check and see if your current workspace meets with the following activation conditions:
 "activationEvents": [
    "workspaceContains:/.ngI18nconfig",
    "workspaceContains:.ngI18nExt"
  ]

Only if your workspace has the .ngi18nconfig file.

Same problem here...

I disabled and re-enabled the extension and the message disappeared.

I have the same problem,  I think README lacks some information, under Requirements  there is "Make sure you place the .ngI18nconfig file correctly." I don't see instructions how to generate this file, which sims to be vital for this extension.

I have the same problem,  I think README lacks some information, under Requirements  there is "Make sure you place the .ngI18nconfig file correctly." I don't see instructions how to generate this file, which sims to be vital for this extension.

Not really sure what my problem is either.
I am getting the same error message
Command 'Angular I18n Editor: Open' resulted in an error (command 'vscode-ng-i18n-editor.openEditor' not found)

after having created my .ngI18nconfig file as this:
{
    "locales": ["en-US", "es-ES"],
     "editor": {
         "messageLocations": ["src/locale/messages.es.xlf"]
  }
}


Is ember-cli-moment-shim still required for ember-moment?

Hi! Thanks for taking care of this addon!
I wonder whether the https://github.com/jasonmit/ember-cli-moment-shim is still required for ember-moment?
In case it DOES NOT, should we remove the blueprint?
In case it DOES, should we update ember-cli-moment-shim to the latest v3.8.0 in the blueprint?
ember-cli-moment-shim v3.4.0 is a blocker for upgrading to the latest ember versions since it relies on<EMAIL_ADDRESS>ATM I upgraded to the latest ember-moment v9.0.1, removed ember-cli-moment-shim, and don't see any downsides so far.

I'm seeing the same and trying to figure out if I need to put time into updating and maybe maintaining moment-shim. It doesn't seem to be necessary possibly due to auto-import or something else?

You both are correct, shim is no longer needed.

It looks like v10 now provides the tools/documentation needed to provide timezones and locales which were the last parts I was having trouble removing.


flexbex_core failing with routing congestion too high

Hi,
I'm trying run your setup locally, but its throwing routing congestion too high always.
set ::env(SYNTH_STRATEGY) "DELAY 2" If I remove this lines everything works fine.
https://github.com/phthinh/soric_project/blob/a15b32788eab5c1f386d8eb8a76979bba4fdb973/openlane/flexbex_core/config.tcl#L34
Do you have any suggestion to proceed further?
Thanks in advance...

Hi @vijayank88,
I didn't face this issue. I think it is probably due to the difference in the version of the tools we used.
set ::env(SYNTH_STRATEGY) configs the strategies for abc logic synthesis and technology mapping.
I am not 100% sure if somehow it affects the routing process. I set this config because I want to prioritize the timing over the area. By default, the config is AREA 0.
Anyway, if your config set is working so that GDS file can be generated, that should be fine :).


Bug - Copyright string - com.google.fonts/check/font_copyright

(NOTE: If your issue is related to a specific check, please consider mentioning its check-id on the issue title.)
I think this is a bug
Observed behaviour

Check:   com.google.fonts/check/font_copyright
Desc:    Copyright notices match canonical pattern in fonts
Files:   PinyonScript-Regular.ttf

 FAIL Name Table entry: Copyright notices should match a
      pattern similar to: "Copyright 2019 The Familyname Project Authors
      (git url)" But instead we have got: "Copyright 2019 **Pinyon Script**
      Project Authors (https://github.com/SorkinType/Pinyon)" [code:
      bad-notice-format]
Result: FAIL

Expected behaviour
I expected the above to be OK but instead, I had to change it to this
PinyonScript
Note that now there is no space between Pinyon and Script
I don't think it should require the removal of the space - ideally speaking - because we are referring to the name of the project not a file that can't have spaces in this string. Probably parsing something that has spaces is harder though and I get that has to be true.
Alternatively, if this MUST stay this way ( no spaces in names permitted ) what about including a note that spaces are not OK if that's the reason for the fail? Is there a note in the template instructions saying to remove the space? In my case I was lucky and I guessed correctly and got rid of the fail but... I was just guessing.
Resources and exact process needed to replicate
If you clone (https://github.com/SorkinType/Pinyon/) and you take the space out of the copyright string in the Glyphs file and push and run the push you should see the fail.

@EbenSorkin The check is just rising an inconsistency between the OFL file and the font metadata, check that the copyright string is written the same everywhere.
Right now I see this in your OFL.txt:
Copyright 2022 The Pinyon Script Project Authors (https://github.com/SorkinType/Pinyon)
And this in your font file:
Copyright 2022 The PinyonScript Project Authors (https://github.com/SorkinType/Pinyon)
The fail should be resolved once you add a space in the copyright string of your source file and re-build the font


automatic generation of inbreeding coeff. file

When all the samples analyzed have similar inbreeding coefficient, autogenerate a specific value of inbreeding coefficient repeated by the number of samples (bam files input)

ngsF has been added into angsd-wrapper as a separate method.


[deps] Upgrade dependencies that have already dropped Node 8 support

Some dependencies of ours dropped support for Node 8 quicker than we did. We should update the dependencies to keep up-to-date.
The dependencies that are known right now are:

~decamelize~
~cross-env~
~mkdirp  (and types)~
~raw-loader~

Fixed with the help of dependabot!


make md occupancy cut in different eta modules

The timing results are here.

The efficiency plots comparisons are here
http://uaf-10.t2.ucsd.edu/~yonsi/SDL_GPU_plots/md_occupancy_9999_by_region/eff_comparison_plots__76c15c6_explicit_9afc360_explicit_PU200/

and timing results before this is shown below.

The timing results are here

closed by mistake...

There are 2 Frees missing in explicit (and x cache) version. The Unified version breaks at runtime. Please fix


Update Globals “nav”

Automatically generated by Netlify CMS

👷 Deploy Preview for shimmering-marigold-4f5b4a processing.

Name
Link

🔨 Latest commit
244f717864f50215dc2414908b0c24269cde878f

🔍 Latest deploy log
https://app.netlify.com/sites/shimmering-marigold-4f5b4a/deploys/6338163621076e00093fb976


Add support for rotation data while creating an asset using ION API

Feature
It would be useful to be able to set the orientation offset of a 3D Capture model upon it's upload/creation using the API instead of doing it manually via the ION settings panel.
The position can already be added here https://cesium.com/learn/ion/rest-api/#operation/postAssets

Adding rotation as well would be very helpful.
Thanks!

Hi @oussamabonnor1, this repo is for tracking CesiumJS issues and requests only. Since your request has to do with the Cesium ion REST API, I would suggest adding the request to https://community.cesium.com/c/cesium-ion/9 instead. It will get better visibility from the Cesium ion devs there.
Thanks!


SelectAll/DeselectAll (Fix #721, Fix #901)

Fixes performance issues with select/deselect all

@t0xicCode Any reason this shouldn't go through?

Nothing jumps out.
:ship:


Update README.md with proper grammar

Past tense of "run" is "ran", not "runned".

Thanks @EvanLovely! :)


Fix: webvtt cues with identifiers

This PR fixes the spacing between WebVTT cues when cues have identifiers. Currently if cues have an identifier that is not None or Some("".to_string()), the WebVTT file will be Displayed with no spacing between cues, which is against the spec and stops e.g. the current versions of FFmpeg and QuickTime from using the file.

input.vtt
WEBVTT

1
00:00:00.650 --> 00:00:01.200
foo

2
00:00:04.000 --> 00:00:06.000
bar

3
00:00:10.100 --> 00:00:18.999
baz

let vtt = TimedSubtitleFile::new("input.vtt")
  .map(WebVttSubtitle::from)?
  .export(file.with_extension("output.vtt"))
  .unwrap();

With the old broken behaviour output.vtt will be:
WEBVTT
1
00:00:00.650 --> 00:00:01.200
foo
2
00:00:04.000 --> 00:00:06.000
bar
3
00:00:10.100 --> 00:00:18.999
baz

With the new fixed behaviour output.vtt will be:
WEBVTT

1
00:00:00.650 --> 00:00:01.200
foo

2
00:00:04.000 --> 00:00:06.000
bar

3
00:00:10.100 --> 00:00:18.999
baz

Hi @ylysyym, thanks for the response and the great library! Your suggestions make sense; admittedly I spent more time figuring out why the output wasn't working with other programs than I spent thinking about what the most correct solution was 😅 But thanks for the pointers, I'll implement the changes when I have a moment.


Unit test TestFormatter_FailureErrors

PR for #264
TestFormatter FailureErrors cases

[x] nil Errors slice
[x] non-nil empty Errors slice
[x] Errors slice with nil error
[x] Errors slice with typed nil error
[x] Errors slice with one error
[x] Errors slice with multiple errors

Coverage: 95.181%. Remained the same when pulling 74511238aff7130c2a733a3f803bac903f6e9df6 on Darrellbor:264-test_formatter_unit_test into 9e6c89d0652998d2535a1614b26d7ffde823fa53 on gavv:master.

@gavv ready for review

Minor fix: https://github.com/gavv/httpexpect/pull/317/commits/fdbca5563f05a4e4f4d3d754da4a590d85e2f75c


Update evidence page to group datasources into sections per datatype

Done in https://github.com/opentargets/platform-app/pull/104


[0.9] Documentation issue (dom-repeat)

I can't find the right way of accessing the DOM generated by a dom-repeat.
Looking up the code it seems I can use the rows property in a dom-change event handler but I'm not sure it's really a public API...
Any hints ?

Can you help us understand what you mean by "accessing the DOM?", i.e. what are you trying to accomplish?
Once dom-change is fired, you can querySelect for the elements that it stamped.
rows are not the DOM, they are the "template instances", aka binding scope for the elements stamped.
In general, for DOM stamped using a data-based system like dom-repeat, you are generally better off interacting with the dom via the data rather than selecting and modifying DOM managed by the dom-repeat directly.

My bad :)
First of all, I'm in the process of porting a component I wrote using 0.5.
This component is not "classic" because it layouts elements : it takes a collections of variable heights "cards" and shuffle them in dynamically generated columns :
Here is a gist of the 0.5 component :
https://gist.github.com/cedric-marcone/bee589a81bcc9e7ee93b#file-card-layout-html
It was invoked this way :
<card-layout data="{{myCollection}}">
  <template>
    <my-element item="{{}}"></my-element>
  </template>
</card-layout>

As you can see in the gist, card-layout used to configure the provided template in order to generate the content for the collection bound to the data attribute and stamp it in the light DOM.
this.template = this.querySelector('template');
this.template.setAttribute('repeat', '');
this.template.model = this.data;

While trying to port my code, I discovered two things :

"Upgrading" a raw template by adding is="dom-repeat" at runtime doesn't work
-> Whats's the recommended way to dynamically force a native element to extend a type-extension custom element ?

I understood that dom-change is fired once the DOM was updated and I could reproduce this behavior in simple test cases, but, trying to do it while porting this element I stumbled on something strange : my domChanged event handler was called but the was nothing to see until I added an async call with a 100ms delay.
-> There must be an edge case where the dom-change is fired before modifications are propagated to the DOM.
-> I'll try to extract a piece of code to reproduce this behavior today

@kevinpschaaf : You can close the bug.
The problem I was facing was related to my "unreasonable" use of dynamically stamped elements.
@ebidel said at IO that migration to 1.0 was an "implementation detail", but sometimes it's not ;)

you really have to make up your mind on the right way to do things
it's really for the best because everything is MUCH cleaner now

Ok, glad you got unblocked.  Thanks for the follow-up.

@cedric-marcone
Hi, I understand this issue is closed. However, regarding (1),

"Upgrading" a raw template by adding is="dom-repeat" at runtime doesn't work
-> Whats's the recommended way to dynamically force a native element to extend a type-extension
custom element ?

I am wondering if you found out how to imperatively invoke dom-repeat? I too am wondering what's the best practice for this.
Thanks,
J


Calicoctl changes, getting started update

Removed calicoctl reset
Removed profile member add
Changed title of column in ip_pool_show from ip-ip to Options
Updated getting started documentation to use new endpoint command

lgtm


New Clevo kext for keyboard backlighting & fan

I wrote a new kext for changing the keyboard backlighting direct from the key pad (as in Windows) with boot & sleep/wake automatic restoring.
Take a look at https://github.com/FreeJHack/ClevoService
Maybe could be interesting for someone...
Cheers

Thanks for the kext! I've added link to your project in the README. (Actually I'm not using Clevo laptops as Hackintosh any more so I took this as an awesome replacement 😂)

Ok.
Thanks.


[New game]: NOEGNUD 👾

🎮 Game Request
Game logic and basic description

Noegnud is a tiny dungeon crawler in which you started with a randomly skilled hero on the bottom most floor. After every second finished round you'll have to remove one of your skills and make it all the BACK to the top of the dungeon.

Point down the features
Game points
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

/assign

Hey @0xabdulkhalid !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hey @0xabdulkhalid ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


DWD not working as expected on some infrastructures where traffic to LB stays in-cluster (gets rerouted internally)

Reminder for a finding recently. Details missing here.
cc @unmarshall @ashwani2k
If memory serves, @ScheererJ and colleagues observed/noted that DWD will not actually reach out to/through the LB on all other infrastructures but AWS, which would make the test (API server reachable externally) not work as expected (reduced to an internal case, which cuts out problems like those for which we implemented the feature in the first place, e.g. a broken Istio ingress-gateway).

MOM
Attendees: @ashwani2k, @ScheererJ, @unmarshall and @rishabh-11
We discussed the issue of kube-proxy path optimization in context of DWD and @ScheererJ  has already left a comment above describing the problem that we see today. It seems that this issue has been there for a while now since kube-proxy path optimization is not a new feature.
Possible solutions that we discussed:

NOTE: These are only brain-storming ideas and its possible that some ideas are just not practical or do not make sense. Purpose is to only capture what was discussed.

Option-1
We already have blackbox-exporter pod running in the kube-system namespace in the shoot cluster. Thanks to @istvanballok I got a better understanding on how it communicates to the Kube-ApiServer running in the control plane of the shoot cluster. Istvan was kind enough to explain it with the following diagram (it might not be complete but gives an overall picture quite nicely):

There are essentially two ways a pod running in the shoot can reach its KAPI:

Use the default kubernetes service which runs in the default namespace. You can also get more info about this service here.
Use the external DNS name for the KAPI.

blackbox-exporter currently makes use of (1). As shown in the diagram Prometheus running in the control plane namespace of the shoot (in the seed) makes a call to the KAPI, which then redirects the call via a VPN tunnel to eventually reach the blackbox-exporter pods which make calls to the KAPI via the default k8s service (via PROXY).

NOTE: On the same lines we also have another component network-problem-detector which also runs in kube-system namespace of the shoot.

Pros:

We already have a component which is running in the shoot cluster which can be leveraged to know if KAPI is reachable from the shoot.

Cons:

There are several points of failure - VPN (which today is not HA), since default k8s service uses a different port it is possible that customers can block that port and of-course the blackbox-exporter can also be down (which would happen in non-HA cluster setup). It is also possible that there are network issues at the node level (local to a node) but that will result in no response from blackbox-exporter.
The impact of depending on blackbox-exporter needs to be well understood - even in case of false positives DWD will scale down KCM, MCM and CA. Today no such impact is seen because the findings from blackbox-exporter are only consumed by Prometheus.
If VPN pod is healthy but the network is broken then there is no automated replacement/restart of the VPN pod. This would lead to a longer connectivity downtime leading to DWD thinking that KAPI is now longer reachable and it will trigger a scale down.

Option-2
@ScheererJ suggested as an alternative to do something similar to what a BTP availability service does. Essentially try and have a probe running in another seed instead of a shoot. The issue is that this would not check the network path from the shoot to its control plane KAPI. However, even today (prior to knowing that the external probe does not work) - DWD was only checking the route from DWD -> LB -> Istio Ingress Gateway -> KAPI which is also not an accurate representation of the network path from the shoot. Since I do not have much information on what BTP availability service does exactly i will not mention the pros and cons. More details are sought.
Option-3
Have a brand new component that is setup in a HA manner and runs possible in the kube-system namespace in the shoot cluster. It will periodically update a lease but with much more frequency than the kubelet does (refer nodeLeaseDurationSeconds in https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/ ). DWD watches the leases and if it finds that many leases (defined via a threshold) have expired and no renewal is happening for a timeout time then it will start to scale down KCM, CA and MCM.
This option was only mentioned briefly but not completely thought through.

Overall it is clear that we currently do not have a fool proof way to know if the connectivity to KAPI from the shoot cluster is broken. Therefore we need to discuss and evaluate the next best thing considering what we have had till now was also far from perfect.

MOM
Attendees: @ashwani2k, @elankath, @rishabh-11, @unmarshall
All were briefed about the problem and pros and cons were discussed for all the options discussed and documented above.
Conclusion:

None of the above solutions (which involve depending on an agent/component deployed on the shoot) are affected by variety of failures that can happen in the data plane (shoots) e.g. failure of VPN, node-local network failures, zonal network failures etcd. It is therefore hard for DWD to distinguish the reasons for non-reachability of KAPI from shoot components - be it network-problem-detector or black-box-exporter.
Evaluated the option to do the external DNS lookup from another DWD from a buddy seed. So essentially internal probe continues to be done locally and if that is successful then external query status is retrieved/pushed/updated from/by another DWD running in another seed. This ensures that external probe always hits the LB. However we also discussed the cons:

Needs at least 2 seeds for this to work.
Complexity involved in selecting the buddy seed.
When shoot control planes are migrated from one seed to another using CPM then this would also impact the seed selection for the KAPI for the migrated shoot.
It is possible that buddy seed is in another region and therefore this will add latency and additional chances of failure to even reach it or hear from it.

Look at the networking stack and see if kube-proxy can be prevented from path optimisations selectively for DWD. This will take some research and also would be an issue when proxy-less routing is done via cilium where kube-proxy is not involved. When that happens this solution would not work any longer.

We concluded that we will look further into checking if kube-proxy path optimisations can be applied conditionally.

/assign @elankath

And if not, we can accept @ScheererJ summary:

Depending on what is desired, this might or might not be sufficient. Loadbalancer issues can only be found on infrastructures with domain names in the kubernetes service (AWS). Istio issues should be visible everywhere. Problems in the shoot network, e.g. firewall rules, or between shoot and seed are never detectable in this approach.

At least Istio issues are detected and that was a, if not the main motivation we had/have.

If there is no simple way to avoid path optimisations and we do not want to accept the above, I actually like option 3 the most (new component in shoot, leases checked by DWD) as it most closely mimics what also the kubelet does.

With respect to option 3 there was also an enhancement KEP for that purpose: https://github.com/kubernetes/enhancements/issues/589
With Kubernetes 1.17 node leases have been introduced (GA). Are they not sufficient for that purpose?

The kubelet creates and then updates its Lease object every 10 seconds
(the default update interval). Lease updates occur independently from the
NodeStatus updates.

Example:
k -n kube-node-lease get leases

With Kubernetes 1.17 node leases have been introduced (GA). Are they not sufficient for that purpose?

As discussed during our meeting, we considering using node leases but the actor (kubelet) how updates the node lease is not very reliable. Kubelet can go down with a lot of other reasons. We wanted a very light weight component which registers a lease. Semantically it is similar to having a node lease and is in-fact a duplicate object per node that we propose to create.

Is dependency watchdog's purpose not to prevent actions, e.g. node deletion, that are based on exactly this? Nodes are marked as NotReady based on the lease objects. Therefore, I find it quite logical for dependency watchdog to monitor this resource as well. It needs to act earlier than the other components, though.

We finalised on leveraging network-problem-detector as it already has functionality that probes using both pod and host network and we could enhance it by adding a Job (NWPD terminology, not a K8S Job) that periodically renews a lease. DWD listens for Node events and upon node registration it creates a dwd-node-lease. This is the same lease that will then be renewed by a specific go-routine (Job) inside NWPD using the host network of the node. Thanks to @MartinWeindel  for the help and for the discussions.
However we learnt today that NWPD is deployed as an extension and that extensions can be disabled. Live issue#3891 suggests that one customer already did that. This is makes it very hard to use NWPD as a component as for any cluster if this extension is disabled then renewals will never happen. This will be a false positive for DWD which will then scale down MCM, CA and KCM deployments to 0.
I checked with @timuthy and he confirmed that today there is no way to enforce an extension.

As discussed with @unmarshall and @ScheererJ, even if there was an option to enforce NWPD to be enabled for all shoots, we'd had a unwanted dependency from a Gardener core feature (DWD) and an extension (NWPD) that is not guaranteed to be installed in a landscape and theoretically exchangeable.
We mainly see two options at the moment:

Make NWPD a main feature of gardener/gardener, so that DWD can piggy-back on the probes. There will probably never be an alternative implementation of NWPD and one can argue it's reasonable to offer this as an opt-out core feature for all shoots. If opted out, DWD proper will be disabled as well.
DWD deploys its own DaemonSet which executes the probes and thus is independent from NWPD.

I personally prefer the second option, even though with a certain overhead but a clear segregation. Maybe the NWPD can even piggy-back in the DWD probes, once implemented?! (cc @MartinWeindel, @vlerenc)

MOM
Attendees: @MartinWeindel, @timuthy, @ScheererJ, @elankath, @unmarshall, @rishabh-11
Summary:

Reason to consider using another lease (other than node lease) was to delink the discovery of network connectivity issue with a frequency lesser than that of node lease expiry period and also to not depend upon kubelet which can fail to update the lease for different reasons. One case pointed was if the Node is heavily loaded and kubelet is as a consequence overloaded. There have also been cases of kubelet crashes which have been reported upstream as well.
It was suggested that in the first iteration we can keep it simple and only look at node leases. Node leases do get renewed much before their expiry period. So DWD could set a threshold and watch if majority of the nodes are unable to renew their lease beyond the threshold but before the node lease expiry. If that is the case then it scales down KCM, MCM and CA. This will prevent multiple nodes going to Unknown state. For MCM and CA to react DWD has sufficient time health-timeout which is today set to 10mins by default.

Conclusion:
For the first iteration we go with watching node lease in DWD and bring down KCM, MCM and CA if majority of the nodes are delayed beyond a threshold to renew their lease. The caveat is that there is still a chance that majority of the nodes still cross the threshold but eventually do update their lease before their expiry. This case we will perhaps not be able to handle. But eventually it is expected that the delay beyond a threshold would not last and eventually DWD will be able to scale up KCM, MCM and CA.
We will have to use a configurable threshold as we do not know what would be a good value for it. Based on experience we will have to make adjustments.

With https://github.com/gardener/gardener/issues/8023, there is also the option to add a new controller to gardener-node-agent which can perform some network connectivity checks and report them somehow.

/remove-lifecycle stale


Can't choose which wallet to connect to

// Create a connector             final connector = WalletConnect(               bridge: 'https://bridge.walletconnect.org',               clientMeta: PeerMeta(                 name: 'WalletConnect',                 description: 'WalletConnect Developer App',                 url: 'https://walletconnect.org',                 icons: [                   'https://gblobscdn.gitbook.com/spaces%2F-LJJeCjcLrr53DcT1Ml7%2Favatar.png?alt=media'                 ],               ),             );
final session = await connector.createSession(                 chainId: 3,                 onDisplayUri: (uri) async {                   //url_launcher                   await launch(uri);                 },               );
There are many wallet apps (Rainbow, MetaMask, Trust, imToken) on my phone. When "connector.createSession()" is executed and opened with url_launcher, Rainbow is always opened, and the next wallet app can only be invoked by uninstalling Rainbow.
But I just want to open MetaMask

@peyton-v5 Are you using iOS by any chance? That's a known behavior.
You'll have to write your own modal for ios which parses the WalletConnect Registry in order to select a wallet to be launched, or use this package:
https://pub.dev/packages/walletconnect_qrcode_modal_dart


Segmentation fault when executing vespa

I'm running a VMware image on WIndows 11. The image has 8GB ram, 4 cores, and 300GB allocated to it. It's running CentOS Stream release 8, and I have installed the community edition of Docker version 20.10.22, OpenJDK 17.0.5, Maven 3.5.4, and Homebrew 3.6.15 on it. When I try to execute 'vespa' from the command line, it generates a segmentation fault and exits, like so:
[jprantza@localhost x]$ strace -ff -o strace-vespa.log vespa
Segmentation fault (core dumped)

[jprantza@localhost x]$ ls -la
total 8
drwxrwxr-x.  2 jprantza jprantza   35 Dec 20 06:46 .
drwx------. 17 jprantza jprantza 4096 Dec 20 06:45 ..
-rw-rw-r--.  1 jprantza jprantza  140 Dec 20 06:46 strace-vespa.log.5956

[jprantza@localhost x]$ cat strace-vespa.log.5956
execve("/home/linuxbrew/.linuxbrew/bin/vespa", ["vespa"], 0x7ffd1bc7d248 /* 54 vars */) = -1 EEXIST (File exists)
+++ killed by SIGSEGV +++

If I install vespa from homebrew within WSL on my host machine, then everything works fine. Also, if I download the latest version of the CLI from Github and extract that into my VMware image and run 'vespa', then that works fine as well.
@aressem had helped me through this in the following slack thread.

Another observation, when I download the 8.98.34 version of the vespa-cli and extract/try to run the vespa executable, I get a segmentation fault as well. The 8.98.34 version is the same version that was installed on my VM using brew. This segmentation fault does not occur with the 8.101.28 version of the cli. Looks like simply updating the version of the cli for brew will address this issue.

The issue appears to be related to homebrew. I noticed that the version of vespa installed by homebrew was 8.98.34, so I re-installed and got the 8.101.28 version this time. Both versions give a segmentation fault when installed using homebrew, but if I download the cli from https://github.com/vespa-engine/vespa/releases then both versions work fine.
I noticed that there is a file size difference between the homebrew version of vespa and the tarred up version.
From vespa-cli_8.101.28_linux_amd64.tar.gz:
[jprantza@localhost bin]$ ./vespa version
Vespa CLI version 8.101.28 compiled with go1.19.4 on linux/amd64

[jprantza@localhost bin]$ ls -la
total 20752
drwxr-xr-x. 2 jprantza jprantza       39 Dec 20 03:02 .
drwxr-xr-x. 4 jprantza jprantza       45 Dec 20 03:02 ..
-rwxr-xr-x. 1 jprantza jprantza  8512509 Dec 20 03:02 script-utils
-rwxr-xr-x. 1 jprantza jprantza 12732815 Dec 20 03:02 vespa

From homebrew installation:
[jprantza@localhost bin]$ pwd
/home/linuxbrew/.linuxbrew/Cellar/vespa-cli/8.101.28/bin

[jprantza@localhost bin]$ ./vespa version
Segmentation fault

[jprantza@localhost bin]$ ls -la
total 12504
drwxr-xr-x. 2 jprantza jprantza       19 Dec 18 10:03 .
drwxr-xr-x. 6 jprantza jprantza      129 Dec 20 14:12 ..
-r-xr-xr-x. 1 jprantza jprantza 12800334 Dec 20 14:12 vespa

Note that the file size in the tarball version is 12732815, but the file size in the homebrew version is 12800334.

A little more info in case it helps.
Tarball version:
[jprantza@localhost bin]$ file vespa
vespa: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped

[jprantza@localhost bin]$ readelf -h vespa
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x467560
  Start of program headers:          64 (bytes into file)
  Start of section headers:          456 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         7
  Size of section headers:           64 (bytes)
  Number of section headers:         23
  Section header string table index: 3

Homebrew version:
[jprantza@localhost bin]$ file vespa
vespa: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/linuxbrew/.linuxbrew/lib/ld.so, with debug_info, not stripped

[jprantza@localhost bin]$ readelf -h vespa
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4691e0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          12797406 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         11
  Size of section headers:           64 (bytes)
  Number of section headers:         36
  Section header string table index: 12

It appears the tarball version is statically linked vs the homebrew version which is dynamically linked.

Not sure if this is relevant, but I uninstalled brew and did a fresh install of vespa-cli again and noticed the following:
==> Pouring gcc--12.2.0.x86_64_linux.bottle.2.tar.gz
Warning: The post-install step did not complete successfully
You can try again using:
  brew postinstall gcc

As an FYI, I can confirm that this issue does not occur with CentOS Stream 9, and that the homebrew version of vespa executable works fine with that version of CentOS.

Thanks for reporting this issue!
The difference between Homebrew binaries and tarball releases is that Homebrew builds their own binaries from source, while we build the binaries published on https://github.com/vespa-engine/vespa/releases ourselves. As you've discovered, binaries built by Homebrew infra are dynamically linked while ours are statically linked.

If I install vespa from homebrew within WSL on my host machine, then everything works fine

I can confirm that this issue does not occur with CentOS Stream 9

I assume this is because the binaries by built by Homebrew are compatible with both the Linux distribution used within WSL (Ubuntu I believe?) and CentOS Stream 9.
This should probably be reported as an issue to Homebrew as it sounds like they're building a faulty binary for CentOS Stream 8. What happens if you install vespa from source on CentOS Stream 8, with brew install --build-from-source vespa?
In general I would recommend using our tarball releases on Linux.

[jprantza@localhost local]$ brew reinstall --build-from-source vespa-cli

==> Fetching dependencies for vespa-cli<EMAIL_ADDRESS>mpfr and xz
==> Fetching<EMAIL_ADDRESS>==> Downloading https://ghcr.io/v2/homebrew/core/linux-headers/5.15/manifests/5.15.86
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/linux-headers/5.15/blobs/sha256:65ac34deace6ddf03c403acd31f5ae72736450c67abfb77e9bbe2941e3785428
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:65ac34deace6ddf03c403acd31f5ae72736450c67abfb77e9bbe2941e3785428?se=2023-0
######################################################################## 100.0%
==> Fetching mpfr
==> Downloading https://ghcr.io/v2/homebrew/core/mpfr/manifests/4.2.0
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/mpfr/blobs/sha256:3e62ca94c057c73dfb08c6b7be42b3aaf0e338c9a422dbdd74695e1106c302a5
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:3e62ca94c057c73dfb08c6b7be42b3aaf0e338c9a422dbdd74695e1106c302a5?se=2023-0
######################################################################## 100.0%
==> Fetching xz
==> Downloading https://ghcr.io/v2/homebrew/core/xz/manifests/5.4.0
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/xz/blobs/sha256:ce4daa84cc24f38a0e1c76646b83374ac210f094aefbf4db4d627c4c324e9c60
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:ce4daa84cc24f38a0e1c76646b83374ac210f094aefbf4db4d627c4c324e9c60?se=2023-0
######################################################################## 100.0%
==> Fetching vespa-cli
==> Downloading https://github.com/vespa-engine/vespa/archive/v8.101.28.tar.gz
==> Downloading from https://codeload.github.com/vespa-engine/vespa/tar.gz/refs/tags/v8.101.28
                                            -=O=-                     #  # # #
==> Reinstalling vespa-cli
==> Installing dependencies for vespa-cli<EMAIL_ADDRESS>mpfr and xz
==> Installing vespa-cli dependency<EMAIL_ADDRESS>==> Pouring<EMAIL_ADDRESS>🍺<EMAIL_ADDRESS>963 files, 5.6MB
==> Installing vespa-cli dependency: mpfr
==> Pouring mpfr--4.2.0.x86_64_linux.bottle.tar.gz
🍺  /home/linuxbrew/.linuxbrew/Cellar/mpfr/4.2.0: 31 files, 3.9MB
==> Installing vespa-cli dependency: xz
==> Pouring xz--5.4.0.x86_64_linux.bottle.tar.gz
🍺  /home/linuxbrew/.linuxbrew/Cellar/xz/5.4.0: 179 files, 2.5MB
==> Installing vespa-cli
==> make all manpages
Last 15 lines from /home/jprantza/.cache/Homebrew/Logs/vespa-cli/01.make:
2023-01-07 20:07:00 +0000

make
all
manpages

fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
mkdir -p mytmp
env GOBIN=/tmp/vespa-cli-20230107-145047-1hjqoac/vespa-8.101.28/client/go/bin go install -ldflags "-X github.com/vespa-engine/vespa/client/go/build.Version=8.101.28" ./...
TMPDIR=`/bin/pwd`/mytmp go test ./...
make: *** [Makefile:122: install] Segmentation fault
make: *** Waiting for unfinished jobs....
make: *** [Makefile:135: test] Segmentation fault

READ THIS: https://docs.brew.sh/Troubleshooting

Hi Martin,
Thanks for looking into this. I've been able to move past this issue by using the statically linked binaries or using CentOS 9 instead. I have a solution, so technically, I guess you can close this issue, however, if you allow me, I'd like to explain why I don't necessarily think you should yet.
I'm new to Vespa. I, like most others, started by going to your product documentation for the install procedure. I recall reading somewhere that CentOS 8 is the only platform supported for doing vespa builds, so I figured I'd stick to the same even though CentOS 9 was available. I then proceeded to install everything using HomeBrew, as outlined in the documentation and immediately encountered this issue.
I think you have a great product, great documentation, and great support, but if I ran into this issue then it's likely that others will too. Maybe if they search they will find this bug and figure out a way to resolve it, or maybe someone will help them in the Slack community as they did for me, but why not just make a simple documentation modification to help others who might run into a similar issue. Just add a simple comment to use the statically linked binaries if you run into any issues when using HomeBrew. That way they know what to do if they run into an issue. That would be my recommendation.
I will also try to file an issue with HomeBrew as well, because I agree with you that this is probably more of an issue with their product than yours.
Thank you again for looking into this.

FYI, I started a thread on this topic under HomeBrew discussions here. If they agree that it's a bug I'll create a ticket for it.

This is a Homebrew/Linuxbrew issue, and not specific to Vespa CLI. Even GCC segfaults for me when installed through Homebrew on CentOS Stream 8.
See https://github.com/Homebrew/homebrew-core/issues/116841 for more details.


man-pages: 5.13 -> 6.05, update build process

Description of changes
The man-pages project has made many changes to its build system since
man-pages-5.13.  This is a first pass at updating the nixpkgs man-pages
derivation to build it.

Description of the release in the release commit:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tag/?h=man-pages-6.05
Changes from 6.04 to 6.05:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/Changes?h=man-pages-6.05
Change history, in particular from 5.13 to 6.04
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/Changes.old?h=man-pages-6.05

Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] 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

[x] Fits CONTRIBUTING.md.

Questions/Comments

No applicable tests that I found
No binary files to test
Should I update release notes?

@cafkafk thanks for getting back and the review!  I lost track of this, have been doing a lot at work lately.  I'll hopefully submit changes in the next couple of days.

Thanks @amarshall for getting this up!


added filename input

looks goo, could you do the same thing in audio.ipynb file? I'll merge the request once you do it.

Sorry for answering late, I forgot to check github, I'll change the code today!

Yes, you can create one, if jupyter notebook is too confusing for you, I'll take care of it and will merge your pull request tomorrow.

yes you do it i am too dumb


Roll engine dc7b5eb89da3..a047fd20f6f0 (1 commits)

https://github.com/flutter/engine/compare/dc7b5eb89da3...a047fd20f6f0
git log dc7b5eb89da3..a047fd20f6f0 --no-merges --oneline
a047fd20f Roll src/third_party/skia 7ed0eae0cd13..8e318fda76df (17 commits) (flutter/engine#6123)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

@rmistry @liyuqian : New roll has been created by https://autoroll.skia.org/r/flutter-engine-flutter-autoroll

Trybots failed. These were the failed builds: https://flutter-dashboard.appspot.com/build.html

Commit queue failed; closing this roll.


Unable to build from the master branch

Hey, bastimeyer. I'm trying to build from the master branch. I followed your instructions in the readme exactly and no go. I cloned the repository using GitHub's app. I ran the command prompt as administrator when trying to build.
I get this when doing the command "npm install"
C:\TWITCH\livestreamer-twitch-gui>npm install

<EMAIL_ADDRESS>postinstall C:\TWITCH\livestreamer-twitch-gui
bower --config.interactive=false install

bower ENOGIT        git is not installed or not in the PATH
npm ERR<EMAIL_ADDRESS>postinstall: bower --config.interactive= false install
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script.
npm ERR! This is most likely a problem with the livestreamer-twitch-gui package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     bower --config.interactive=false install
npm ERR! You can get their info via:
npm ERR!     npm owner ls livestreamer-twitch-gui
npm ERR! There is likely additional logging output above.
npm ERR! System Windows_NT 6.1.7601
npm ERR! command "C:\Program Files\nodejs\\node.exe" "C:\Program Files\nod
ejs\node_modules\npm\bin\npm-cli.js" "install"
npm ERR! cwd C:\TWITCH\livestreamer-twitch-gui
npm ERR! node -v v0.10.35
npm ERR! npm -v 1.4.28
npm ERR! code ELIFECYCLE
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     C:\TWITCH\livestreamer-twitch-gui\npm-debug.log
npm ERR! not ok code 0

Nevermind. I got it working, though I didn't use the Node.js command prompt this time.
I right clicked on the repo in the GitHub app and selected Open in Git Shell, then ran the commands. I don't know if it matters or not, but before doing that I selected Git Bash as the default shell in the GitHub app's options.

Hi, thanks for helping to test the master branch!

bower ENOGIT git is not installed or not in the PATH

Git is a requirement for building the application (because of some dependencies of the npm + bower packages and because of the metadata build task).
Please make sure that the path of your git installation is properly set in your system's PATH variable. From the default windows shell and also from the "node.js command prompt" you can do this by typing where git or echo %PATH%...
I don't know the github app and also if it comes with a local git installation, but you should install the official "git for windows" from www.git-scm.com... The installer then adds git to the PATH variable, so you're able to use it from the default windows shell as well.

I'm glad you quickly managed to find a solution. :wink:


Data stored in web app backend

While investigating an issue with long connection times in the extension I stumbled over this issue:
https://github.com/cschleiden/azure-boards-estimate/issues/129
The log fragment included has a reference to an extension backend at https://estimate-backend.azurewebsites.net .
My questions are GDPR-related:

What purpose has this backend?
What data flows to it?
Is any data stored somewhere in the backend - and if yes, which types of data?

Thank you :-)

You can inspect the code for the backend here: https://github.com/cschleiden/azure-boards-estimate-backend
It acts as a relay host for the session participants and doesn't seem to store any data.


Use pym.js for responsive embeds

Pym.js allows for awesome responsive embeds so we should use it here instead of iframe.

@DavidLemayian Looking into integrating this. Thank you


Updating embeddings Notebook - doesnt work

Hallo, have recently looked into this cool library, and wanted to do some embedding.
But have trouble running the updating embeddings notebook.
https://github.com/cvxgrp/pymde/blob/main/examples/updating_an_existing_embedding.ipynb
When I do this step:
incremental_mde = pymde.preserve_neighbors(
mnist.data,
constraint=anchor_constraint,
init='random',
verbose=False)
I get the  this error:

Am running on a clean environment.
Reproduced the error in this 10 lines colab file: https://colab.research.google.com/drive/1Fq4u8Z85Xmpz1Z3YKem7jA2ONfGouAiA?usp=sharing
Hope you can help.
Kind regards

Thanks for reporting! working on a fix

I've pushed a fix, and a new version should be uploaded to PyPI & conda forge soon (0.1.15) that contains this fix. I'll close this issue when the new version lands.

The fix is available on PyPI now, and will be on conda forge soon, as version 0.1.15.
Thank you for reporting this issue!


Embed link for images?

Hi, is there an option to get the embed link to images easily?
Also, is it possible to make only uploading of files private, but the files be shared publicly?

Hi. You can embed images by hitting the share button and unchecking "Is DL". The resulting link can be embedded:

For the second question, I think it's also solved by the share button. All shared links are available publicly.

Awesome! Thanks a lot <3


Migrate to null safety

@maRci002  Hi, do you have any plan to migrate? Will you accept PR if I do?

I think it will be done this week. On weekdays I'm a little busy.

@maRci002 Thank you.

It is about 90%, I will finish tomorrow

ahh, I need this too :-) I was almost doing my own migration

Hi,
because I need this library in a null safe version I migrated it today ignoring the currently not migrated packages:

package:proj4dart
package:mgrs_dart
package:wkt_parser
package:unicode
package:lists

This is a migration to unsound null safety. So far I couldn't see problems, so I expect as soon as the missing packages are available that should be fine.
At some places I wasn't sure if previous nullable values should still be nullable, I left the null checks despite having changed the types to nonnullables and added a TODO comment.
I hope this is in your sense and you can use it, it was a whole day work :-)

It is done. Today (Tuesday) I'm going to speak with @fegyi001 about mgrs_dart / wkt_parser pub release.

@maRci002 Thank you! I hope @fegyi001 merge soon.


TooManyExtensionProviders

Related command
az vm create -g <Resource_Group_Name> -n <VM_Name> --attach-os-disk <Os_Disk_ID> --os-type "windows" --  --patch-mode "Manual"
Describe the bug
{
    "status": "Failed",
    "error": {
        "code": "TooManyExtensionProviders",
        "message": "The number of extension providers in the request URI exceeds limit. ARM supports up to 3 extension providers."
    }
}

To Reproduce
I'm trying to spin up a VM from an existing managed OsDisk via Az CLI. the original VM where OsDisk previously tied up has 12 VM extensions. now the error is giving me the impression that once you spin this, any extension from the previous VM via Az CLI script will automatically be included in the VM creation. but on portal, this is not a problem because it will automatically set to "none"

Expected behavior
create a vm image using existing OsDisk
azure cli link https://docs.microsoft.com/en-us/cli/azure/vm?view=azure-cli-latest#az-vm-create
also there is no flag to set vm extension to "none"
was there any solution to this??

originally i posted it here https://github.com/MicrosoftDocs/azure-docs/issues/23934

@zhoxing-ms for awareness

I'm trying to spin up a VM from an existing managed OsDisk via Az CLI. the original VM where OsDisk previously tied up has 12 VM extensions. now the error is giving me the impression that once you spin this, any extension from the previous VM via Az CLI script will automatically be included in the VM creation.

Since CLI uses the ARM template deployment to create VM, so there is no such logic on client side
This should be a REST service issue, and the Compute team needs to investigate it

I'm trying to spin up a VM from an existing managed OsDisk via Az CLI. the original VM where OsDisk previously tied up has 12 VM extensions. now the error is giving me the impression that once you spin this, any extension from the previous VM via Az CLI script will automatically be included in the VM creation.

Since CLI uses the ARM template deployment to create VM, so there is no such logic on client side This should be a REST service issue, and the Compute team needs to investigate it

do we need to create separate ticket for this or can someone from you guys reroute this to the right channel? all i know is im using azure cli and i dont know as well the exact translation from cli to rest service behind so i dont know how to explain it to the channel you're mentioning.

do we need to create separate ticket for this or can someone from you guys reroute this to the right channel? all i know is im using azure cli and i dont know as well the exact translation from cli to rest service behind so i dont know how to explain it to the channel you're mentioning.

Sorry, I just explained this is a server related issue, and we will route it to the appropriate service team
@nkuchta Could you please take a look at the VM extension related issue? Or do you know who is the right person to investigate this issue?

This has nothing to do with VM extensions. From what I can tell it is
related to the ARM request itself.
On Thu, Sep 8, 2022, 7:46 PM Xing Zhou @.***> wrote:

do we need to create separate ticket for this or can someone from you guys
reroute this to the right channel? all i know is im using azure cli and i
dont know as well the exact translation from cli to rest service behind so
i dont know how to explain it to the channel you're mentioning.
Sorry, I just explained this is a server related issue, and we will route
it to the appropriate service team
@nkuchta https://github.com/nkuchta Could you please take a look at the
VM extension related issue? Or do you know who is the right person to
investigate this issue?
—
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-cli/issues/23796#issuecomment-1241436135,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGEU3DVCOCIHQK7RNHB2TUDV5KQJFANCNFSM6AAAAAAQGJV7DE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@auwi987 Could you please send the debug log to me by email? My email address is<EMAIL_ADDRESS>thanks!

@zhoxing-ms sent!

@auwi987 Could you please add --debug parameter to the executed commands, and then send the printed information to me? Thanks


Incomplete sanitization of text strings

LGTM reports the following line does incomplete sanitization, introduced in 61cfe58.
https://github.com/amio/badgen-service/blob/8f703af7367d58670de39c2170a4e2949c382555/libs/serve-badge.js#L15
This line only replaces the first instance of <, which i'm guessing is not what you intended to do?
Would it not be better to handle this for both subject and status, and in the same way, making sure that any potential character which may mess up the SVG is escaped? (I forsee users wanting to e.g. use < or > characters to talk about version compatibility) This would probably be better handled in badgen than badgen-service right, so any other users of the library will also benefit.

Since this text only occurs in <text /> in svg, so replace < is good enough for fixing the problem.
I wish to keep these sanitization as simple as possible, to minimize the impact on performance. That's why I do this on subject but not status, in badgen-service (user land) other than badgen library.

I made a test, sanitization on subject & status would cause ~20% perf drop for badgen =. =

It turns out this should be handled in badgen, or the width would be calculated as < other than <.
Fixed in badgen v2.4.4.

Woah 20% drop is quite a bit... Did you use a benchmarking tool for this or was it just some simple tests?

It turns out this should be handled in badgen, or the width would be calculated as < other than <.

Ah yeah that would definitely be a problem, hmm.

There's a benchmark suite in badgen library

Fixed in 550a136


Make multiple advisors configurable in an advisor run.

Due to now having two advisor implementations, i.e., NexusIq and VulnerableCode(and possibly others to come), it would be nice to use multiple advisors during a run. Currently, only one at a time can be used.
The advisors above use different sources and databases for their vulnerabilities, thus leading to different results.
A user might want to compare those results or combine both to have a richer pool of vulnerabilities.
It is probably best to implement this after #3628 is merged, since there is a restructuring of the AdvisorConfiguration.

After a discussion with @oheger-bosch, we already have an idea how to implement this:
Right now, NexusIq and VulnerableCode are children of the Advsior class and only one instance
of this class is created in AdvisorCommand. If you look at AnalyzerCommand, it creates only one instance of
Analyzer which in turn creates and handles multiple Packagemanager.
In our opinion, it would make sense to have a similar logic for the Advisor. In particular, create an interface called, e.g., VulnerabilityProvider, that is implemented by NexusIq and VulnerableCode. Then, the Advisor class is responsible for creating and calling those providers and writing the respective results into the final advisor result.

A user might want to compare those results or combine both to have a richer pool of vulnerabilities.

@KorSin  Are you thinking of also offering a de-duplication function in the Advisor? e.g. merge advisories for multiple providers for the same CVE?

Interesting question. Here are my thoughts:

I could imagine the user wants to know whether one or multiple advisors found the same vulnerability. Could be solved by just appending a List of advisors after the merge.
Even if multiple advisors found a vulnerability with the same CVE, is it really the same? Maybe they come to a different conclusion w.r.t. the score and URL.

See also the somewhat related discussion at https://github.com/nexB/vulnerablecode/issues/284#issuecomment-781869360.


Error: Cannot find module 'memdown'

Hello @mhart ,
I'm on Ubuntu 14.04 and following these steps:
curl -sL https://deb.nodesource.com/setup | sudo bash -
sudo apt-get -y install nodejs
sudo apt-get -y install build-essential
sudo npm install -g dynalite
sudo /usr/bin/dynalite --port 8080

And getting:
sarxos@sarxos-comp:~/workspace$ sudo /usr/bin/dynalite --port 8080

module.js:340
    throw err;
          ^
Error: Cannot find module 'memdown'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/usr/lib/node_modules/dynalite/db/index.js:4:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

I've executed  sudo npm install -g memdown as well, but it didn't help.
The npm version:
sarxos@sarxos-comp:~/workspace$ sudo npm -v
3.7.5

And node version:
sarxos@sarxos-comp:~/workspace$ node --version
v0.10.42

It would be great if you have some ideas of how this could be resolved.

Did you install it first with an old version of npm? There are some bugs with npm v1.x – which, given your very old version of Node, may have been installed initially before you upgraded to npm v3.x
Try npm cache clean and then install again and see how you go.

Hi @mhart,
Thank you for your support! I confirm that everything is working well after removing and installing again nodejs and all node modules.
For the users who experience the same issue - below is full procedure I followed:
I removed nodejs by:
sudo apt-get remove nodejs

And then removed global node_modules by:
sudo rm -rf /usr/local/lib/node_modules/

Then I re-installed nodejs:
sarxos@sarxos-comp:~/workspace$ sudo apt-get install nodejs
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  nodejs
0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded.
Need to get 0 B/4376 kB of archives.
After this operation, 22,2 MB of additional disk space will be used.
Selecting previously unselected package nodejs.
(Reading database ... 539663 files and directories currently installed.)
Preparing to unpack .../nodejs_0.10.42-1nodesource1~trusty1_amd64.deb ...
Unpacking nodejs (0.10.42-1nodesource1~trusty1) ...
Processing triggers for man-db (<IP_ADDRESS>-1ubuntu1) ...
Setting up nodejs (0.10.42-1nodesource1~trusty1) ...

The npm:
sarxos@sarxos-comp:~/workspace$ sudo npm install -g npm@lates

And dynalite:
sarxos@sarxos-comp:~/workspace$ sudo npm install -g dynalite

Start it:
sarxos@sarxos-comp:~/workspace$ sudo dynalite --port 8080
Listening at http://<IP_ADDRESS>:8080

Everything is working after this is done :)

I'd also consider using a newer version of Node.js to be honest – the v0.10 line is 3 years old now and will become increasingly rarer. v4.x is the LTS release and can be installed on Ubuntu like so:
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs

Instructions for various distros here: https://github.com/nodesource/distributions


Update hotspot antenna and elevation

When I go to update hotspot I select "Custom Antenna" enter 8.5 dbi and 10 meters. I then click Update Antenna, but the confermation screen shows "1 dbi" not 8.5 dbi.
Also if I don't press enter on the keyboard before clicking update antenna the height field is not recorded.
Given this was not working I selected the RAK antenna as it is the closest at 5.8 dbi. After submitting I used the API to  check what the setting was and it shows 58 for gain. Is this correct. Not representing as a float? See below.
{"data":{"lng":-104.82144351015835,"lat":39.7211750174995,"timestamp_added":"2020-09-09T23:52:17.000000Z","status":{"online":"online","listen_addrs":["/ip4/<IP_ADDRESS>/tcp/49016"],"height":822138},"reward_scale":0.4310302734375,"owner":"13gJqE2X4mjA1VjJ3UvNgSoebMogCiQhBPyQWrGKSXm8ZH6Bnzp","nonce":2,"name":"muscular-mocha-jellyfish","location":"8c268cd0b2621ff","last_poc_challenge":820768,"last_change_block":822834,"geocode":{"short_street":"Sable Blvd","short_state":"CO","short_country":"US","short_city":"Aurora","long_street":"Sable Boulevard","long_state":"Colorado","long_country":"United States","long_city":"Aurora","city_id":"YXVyb3JhY29sb3JhZG91bml0ZWQgc3RhdGVz"},"gain":58,"elevation":30,"block_added":490492,"block":822856,"address":"116GfBi3trAuVxkd3wJmR5Rn2GUnPysYU31v79HvoCwCYscp9x2"}}

it shows 58 for gain

Yes, that is expected.
The bug fix for entering antenna and height is in 3.1.1 which is in app review. it'll be out in the next few days.

Great. Thanks.