Support IPv6 node addresses

Feature Request
Support IPv6 addresses for the Talos node, including dual-stack.
Description
Currently if a node has an IPv6 interface or is dual-stack the Talos CCM fails to contact the Talos node with the following error:
I1018 16:34:10.934872       1 node_controller.go:415] Initializing node talos-1bxuk8 with cloud provider
E1018 16:34:10.936189       1 node_controller.go:229] error syncing 'talos-1bxuk8': failed to get instance metadata for node omni-eu-1bxuk8: error getting metadata from the node talos-1bxuk8: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: address <IP_ADDRESS>,fd44:4f1d:3c85:4702:20d:3aff:fe21:da60:50000: too many colons in address", requeuing

Nice catch. It seem to me it trying to connect to <IP_ADDRESS>,fd44:4f1d:3c85:4702:20d:3aff:fe21:da60 (two IPs with comma)
Can you tell me the Talos/kube-api version. And what do you have here node.metadata.annotations.alpha.kubernetes.io/provided-node-ip

Talos: v1.5.4
kube-api-server: v1.28.2
Annotation alpha.kubernetes.io/provided-node-ip: <IP_ADDRESS>,fd44:4f1d:3c85:4702:20d:3aff:fe21:da60
Basically, Talos is detecting two interfaces and passing --node-ip "<IP_ADDRESS>,fd44:4f1d:3c85:4702:20d:3aff:fe21:da60" to the kubelet.

Talos: v1.5.4 kube-api-server: v1.28.2 Annotation alpha.kubernetes.io/provided-node-ip: <IP_ADDRESS>,fd44:4f1d:3c85:4702:20d:3aff:fe21:da60
Basically, Talos is detecting two interfaces and passing --node-ip "<IP_ADDRESS>,fd44:4f1d:3c85:4702:20d:3aff:fe21:da60" to the kubelet.

Nice, it was alpha feature a few releases ago ) ok, it is not to hard to fix...
Thank you.

I was more making a note to fix it myself in the morning, but feel free to implement it :D

kubelet v1.28.3, talos v1.5.4
{"ts":1698090833488.9023,"caller":"cli/run.go:74","msg":"command failed","err":"failed to run Kubelet: bad --node-ip \"<IP_ADDRESS>,2001::bdff:fef2:392f\": dual-stack not supported in this configuration"}

how did you configure the kubelet/kube-api ?


Corrugated

Please have a look at the picture.

Please open this issue in this address: https://github.com/CRAnimation/CRNumberFadedAnimation. ^_^


Hosted service item exists (Incidents), but hosted service does not exist

Hosted feature service portal item "Incidents" (id:a79e118ff51e493abed58823ea7f8be7) exists in nsec portal, but the actual service does not exist.
NOTE: if you delete this portal item, make sure to delete the associated service definition item id:d1a5948e01294466be95abf9eebea0ae.

I saw this as well when looking at incidents for use with Land Ops.  I created a subset (1,999 features) of the incidents and created a service including just the features and not the CIDNE database symbology.  Feel free to use instead.

@j-sullivan If this is not fixed by 1700 this will not work at UC. @nfeuerstein FYI in case you are needing this.

@j-sullivan You can delete your Incident feature service referenced above unless there is something about it that is unique to your needs.  We have a feature service from the incidents you moved to the new geography here: https://nsec.esri.com/arcgis/home/item.html?id=03d78feda64d4eaea74c4d6a37512329

@j-sullivan is this still an issue?

Based on the lack of activity on this item. I am going to delete the item at 1100 today. If you think this is in error please respond by then.

FYI: Looks like there are no resources that are referencing a service named "Incidents".

Service definition deleted @j-sullivan
This is a simple fix so no verification needed.


mode is deprecated, use subnet-mode instead

The gcloud output when using --mode was:
WARNING: mode is deprecated. Please use subnet-mode instead.
Then I went on and deleted the vpc and created it again using --subnet-mode option successfully.

Duplicate of #267, which is a duplicate of #259, which is a duplicate of #256 😄

This is fixed on master, tagged 1.9.0


typo: Microsoft.BotService

Diplay -> Display

Automation for azure-sdk-for-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-node

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-java

Automation for azure-sdk-for-go


when toggling a folder in the sidebar, don't select it

This makes it possible to navigate in the sidebar
without altering the main display

closes #99


SQL Validation: Add stricter checking for the TRIGGER statement

Description
Adding stricter SQL validation for the TRIGGER statement to avoid false positives.
Before, we were checking for:
TRIGGER (case sensitive)
This PR:
CREATE TRIGGER (case sensitive)
or
CREATE DEFINER=`root`@`host` TRIGGER`

(case sensitive)
Steps to Test

Check out PR.
Run npm run build
Run ./dist/bin/vip-import-validate-sql.js <sql file>
Should only catch instances stated above

Tried testing w/:
CREATE TRIGGER
CREATE DEFINER=`root`@`%` TRIGGER
CREATE DEFINER=`root`@`host` TRIGGER
CREATE<EMAIL_ADDRESS>TRIGGER
CREATE DEFINER=`youruser`@`host` TRIGGER

Please let me know if there's any instances I missed! Thank you!

This catches any TRIGGER SQL statements, but it doesn't catch any matching DB values if for some reason the statement was defined as a value (i.e:
INSERT INTO `table` VALUES (1, CREATE DEFINER=`root`@`host` TRIGGER`, 'exampleValue)


Add support for unique IDs for entity registry

Pull Request for self review / documentation:

Added support for unique IDs to support the Entity Regstry
Made the config optional to not break anything
Tested with switches, covers, light device types. In Home Assistant you can see if it is working when you click the info card for a light and see a gear icon to customize the entity. I found this does not actually change the entity ID, but this is a feature enabled by the Entity Registry.
If you want to change entity IDs, you need to edit entity_registry.yaml in the HA configuration directory.
Entity Registry keeps old entity IDs around so if you start with a device as light and change to switch, it keeps the old entity registry. For this reason, I put the domain (e.g. light) in the unique ID.

Addresses Issue #3

I've done some more testing and it looks ok. Going to merge this in.


Run nightly tests of the saltfs repo

We should run the full saltfs suite (from scratch) on Travis every night to catch changes in upstreams (e.g. #314).
@edunham I think you like to use nightli.es for this purpose? We should also have some form of alerting on failure, but I'm not sure of a good way to do that.

We can configure Travis to send email or IRC notifications of build status, https://docs.travis-ci.com/user/notifications/. I think emails will be the best communication channel for me. @larsbergstrom, would / where would you like notifications?

I agree that email is probably the best of the options. The awesomest would be automatically opening a GH issue in the case of failure, but I don't think that's an available option :-)

Ping on this, would have helped catch #483.

@edunham could we use an alias on servo.org? e.g<EMAIL_ADDRESS>

I opened #376 for this, but I see a few problems with this solution:

I am unaware of any way to filter notifications by branch. Because homu always uses the auto branch, even though Travis does not send notifications for PRs this will send extra emails when going through bors-servo, causing lots of spam.
Having an (internal?) email list adds more state, somewhere that is not 1) openly visible 2) likely not under version control of some kind. What does the process look like for changing that list?
If we add this to other repos, we'd start wanting one list per repo, which is a lot of lists to keep track of (e.g. which lists am I on? did we remember to enable notifications on [new repo] yet?)

I think it may be time to invoke Zawinski's Law and add email features to homu, where we can add a few more smarts and standardize this a bit, making it available to all repos easily.

Apparently Travis has a new feature called Crons which allows natively scheduling nightly builds. It looks like this is still in Beta but on the cusp of going GA - I believe it can be enabled through the Travis console, possibly after a support request.
I think IRC notifications would be fine to start with, although I suppose an email alias would work as well.

Nightly builds are now enabled and #598 adds notification in the bots channel on all builds.

@edunham Do you know if this is working? Just got hit by a new failure (see #601), but I'm not sure if Travis ran a nightly build yesterday.

@aneeshusa Travis is reporting that it kicked off a cron about 15 minutes ago, which corresponds to the start time of https://travis-ci.org/servo/saltfs/builds/201652835. One can see the cron "last run" time on https://travis-ci.org/servo/saltfs/settings. According to the conversation in https://github.com/travis-ci/beta-features/issues/1, one can tell that the afforementioned build was triggered by cron because its icon by the build number looks a bit like a lego with a clock, rather than the usual icon.


pypy3 support

The major challenge with py3 is to keep the code base clean.
The major challenge with pypy is that some c-module won't work and we'll either have to find a substitute or develop our own bindings.
For reference:
https://github.com/ethereum/pyethereum/issues/132
https://github.com/ethereum/pyethereum/issues/188
note: miniupnpc isn't used anymore.
for pypy3 we need gevent 1.1, currently it breaks neworking:
https://github.com/ethereum/pydevp2p/issues/2
sha3 replacement:
https://pycryptodome.readthedocs.org/en/latest/
own libraries: serpent, ethash

see also #37

Any progress on this?


Remove CpuFeatureLevel in favor of std_detect

This uses the trait based approach discussed in IRC. In order to be able to set the env var for testing, https://github.com/rust-lang/stdarch/commit/b8aecbfb8ea2ac028426da48b0f9ca6a730b9730 will need to be pulled into the Rust tree and released in a nightly, but unfortunately it is not released yet. In lieu of that, I would like to make a follow-up PR to this one to create automated tests for each version of each ASM function that doesn't already have tests.

Coverage increased (+0.07%) to 71.114% when pulling fe53444e58300f56ad2b15c10c71d5c016f650b3 on shssoichiro:std_detect_refactor into 8b19a94ee835571e559869d4f63e7e723adce0a2 on xiph:master.

We need to decide between this or #1740.

From IRC, it sounds like the very compelling argument to go with the other approach is that a lookup table should be faster than if/else statements. Closing this in favor of that one.

Thank you very much for spending your time & efforts trying this though!


Wave dumping broken on xcelium

PR #2128 (mine) merged the VCS and xcelium code for dumping waves. This was probably a bad idea, because the two tools have different syntax. We need to split the code out again, either into a file per tool or a "base" file with an xcelium "override".
To get things working locally in the meantime, manually prefix the calls to fsdb* in waves.tcl with "call ". The original report was inline in the PR that broke things.

My personal preference is to have a file per tool (as the PR had originally). @sriyerg, what do you think?

My preference is to actually move the $fsdvDump* system calls to a SV code instead so that we can get rid of the tcl files (we will retain the per-tool tcl file for other tool-specific sim controls). The benefit of that is allowing run-time control of how to dump stuff via plusargs (which is tool agnostic). I am researching a bit on this - will get back with a prototype.

Sounds sensible to me.

Hi @sriyerg! I'm assigning this issue to you because you said you want to work on it. Given the duplicate issue from last night, it looks like someone (you or someone else) should probably fix it soonish. De-assign yourself if you don't want to do it, and I'll try to do something at the start of next week.

@sriyerg

My preference is to actually move the $fsdvDump* system calls to a SV code instead

With due respect, I differ - doing $fsdb (or any other PLI/VPI) calls inside SV code requires us to recompile/re-elab for various scopes to be dumped (Common practice for large designs/runs - as full dump can be expensive).
I believe individual tool_name.tcl is perhaps the most time-tested approach (other Unit test frameworks do this already, VUNit is one example).
Can you please re-consider this?
Thanks
Srini

@sriyerg

My preference is to actually move the $fsdvDump* system calls to a SV code instead

With due respect, I differ - doing $fsdb (or any other PLI/VPI) calls inside SV code requires us to recompile/re-elab for various scopes to be dumped (Common practice for large designs/runs - as full dump can be expensive).
I believe individual tool_name.tcl is perhaps the most time-tested approach (other Unit test frameworks do this already, VUNit is one example).
Can you please re-consider this?
Thanks
Srini

It appears to have been fixed. Closing.


Added "All-Nighter" (37i9dQZF1DX692WcMwL2yW)

Hi! Can I ask why my PR was closed? I'd like to add this playlist to the archive. Thanks!

It looks like it was automatically closed when I changed "master" to "main". Sorry about that! Feel free to reopen a new PR, I'll happily accept.


Responsive maintainer?

Hello,
I just wanted to know whither or  not the maintainer of this repo is responding to PRs. I want to update this project to be compatible with tetra 0.7.0, so @tesselode can publish a new release of this crate.
If he isn't responding to the PR, I would upload the crate myself by forking it.

Hi,
I do see notifications, although admittedly I haven't been as responsive as I would like. @devmeat already made a PR to update tetra and egui, but they closed it before I merged it in. I could still merge it, but I'm not sure if there's some reason they don't want me to merge it.
If you do make a PR, just nag me here or in the rust gamedev discord until I merge it in.

@tesselode @TimerErTim The original PR fixes compatibility issues with Tetra 0.7. However, I found an issue with images looking corrupted. Sadly I haven't had time to look into it, and closed it just in case this is related to my changes.

I opened this issue as I thought there occurred more compatibility issues with tetra 0.7.0 compared to pre releases.
On my local environment it seemed your (@devmeat ) PR introduced an issue with tetra 0.7.0 (not alpha) regarding incompatible but equally identified structs. That however was caused by my local configuration and was not caused by your update. I have now fixed it.
If it is of any use for you, I have not observed image corruption with tetra 0.7.0. But I have not done any testing for that problem. I could however, if it benefits you.

@TimerErTim I've reopened the PR: https://github.com/tesselode/egui-tetra/pull/3

If it is of any use for you, I have not observed image corruption with tetra 0.7.0. However I have not done any testing for that problem. I could do that though, if it benefits you.

Yes, please. It could be just my setup, but just want to be sure.

I'll try to take a look soon, but @devmeat are you able to post an example project that demonstrates the image corruption?

@tesselode Unfortunately, I don't have anything to post as an example at this point in time. I had to port my game due to Tetra not being maintained anymore.


Refactor code

Code is heavily bugged and its a mess. Need to refactor the files

Code cleanup has been done + Big parts of the code is refactored now


feat(low-server): add response writable

For the issue: #13

Allows the router response object to be Writable Stream.
Minor tweaks to optimize performance

Hi @jesusvilla thanks for your followup with a PR here.
I have look and applied your implementation to the existing code base and your feature is now released at: https://github.com/jkyberneees/0http/releases/tag/v2.4.0
Unfortunately, I decided to not merge this PR because I have also found an issue while processing the request headers that causes creating a generic function such as forEachObj  unnecessary.
I also have to say, basic for loops vs foreach result more performant on my side, also confirmed by independent tests on the internet.
Anyway, thank you very much for pushing this feature. I properly mentioned you on the release notes.

Hi @jkyberneees thanks for taking it into consideration. For forEachObj
https://jsperf.com/foreach-object/1

function forObject (obj, cb) {
  const keys = Object.keys(obj)
  for (let i = 0, length = keys.length; i < length; i++) {
    cb(obj[keys[i]], keys[i])
  }
}

You're right, a classic for is faster for objects, but a forEach is faster for arrays, anyway it's always nice to have it in a function that does the work, you should also consider it, because when you want to iterate objects you're going to always have to copy and paste the same code.


Use go-mockdns package for testing DNS auto-configuration

https://github.com/foxcpp/go-mockdns

Done


SQL Instrumentation Improvements

not blocking bc it's a huge change and out of scope for this PR but, along with some broad http helpers that oughta be abstracted into a gem, to be DRY we should also probably move the mysql obfuscation regex into a db helper gem of some sort eventually/ideally as an early todo in 2022.
Originally posted by @ericmustin in https://github.com/open-telemetry/opentelemetry-ruby/pull/1063#r771863967

There is structural duplication in SQL instrumentation gems, e.g. obfuscation and semconv, as well as knowledge duplication between the mysql2 and triology instrumentations. To minimize maintenance burden of these libraries it will likely be best to extract reusable code and provides more focused test coverage.
In addition to that there is not any test coverage for UDS connections and should update semantic conventions to reflect these values.

@ahayworth @ericmustin I started to look at this and realized we have a little bit of re-inventing the wheel going on here.
It looks like the original code was based off the NewRelic agent, which has an all-in-one set of Database utilities that supports multiple dialects. It's unclear to me why we didn't migrate this code into this repo, which I imagine has quite a bit of production usage.
Instead of refactoring out common functionality from our classes I would like to propose we revisit this and import the code from the NewRelic agent and credit them with authorship.
https://github.com/newrelic/newrelic-ruby-agent/blob/dev/lib/new_relic/agent/database/obfuscation_helpers.rb
https://github.com/newrelic/newrelic-ruby-agent/tree/dev/test/fixtures/cross_agent_tests/sql_obfuscation
Apache 2 License https://github.com/newrelic/newrelic-ruby-agent/blob/dev/LICENSE

Happy to see this refactored into something reusable and more dry, i forget what the resolution was previously but my understanding is if we have concerns about OSS crediting we can just include a reference to the NR library in a license-3rdparty.csv file rather than adding a dependency, which id prefer to avoid. there were some New Relic folks who were involved in the SIG at the time this was contributed and didn’t raise any objections to our crediting approach (just a code comment iirc)
Example: https://github.com/DataDog/dd-trace-rb/blob/master/LICENSE-3rdparty.csv

I'll clarify what I meant by reusing the NewRelic agent code, it would be a copy/paste/modify of the existing package and we'd credit NewRelic as the source in the Readme and Yardoc.
I'll look into the 3rd party CSV suggestion.

The reasons we didn't do this before were:

We asked if NR would be willing to formally donate the code, but by "asked" I mean "we mentioned it on github somewhere and didn't really pursue it further".
We added database instrumentation in pieces (pg coming last, if I recall the ordering). I think each PR added what they needed rather than bringing in "unnecessary code". Whoops. 😆

But I think at this point, having a unified set of maintainable code would be an excellent win. We should do it! 😄

Related: https://github.com/open-telemetry/opentelemetry-specification/pull/3127

TIL: https://github.com/open-telemetry/opentelemetry-sqlcommenter

Related: https://github.com/open-telemetry/opentelemetry-specification/issues/3150

i'll try to pick this up this week

Hi @ericmustin! Could I collaborate with you on this issue? I work on New Relic's Ruby agent and am familiar with our SQL instrumentation.

Hey @kaylareopelle yea for sure. I had some wip branches here awhile back that I think are probably better to scrap and start from scratch. But I'll try to dig up any relevant branches/code here and link in this issue when I get a chance this wknd, I'm also happy to just assign to you and review any work you do here, either way I'll try to attend Tuesday's SIG mtg prepared to actually either provide guidance or feedback on anything here.
I think the goal was to sortve have a helper class or module that the individual mysql2/trilogy/pg/etc gems could simply inherit from, but iirc the implementation wasn't as clean as I'd have liked and we sortve dropped it and moved on. So it goes

During today's SIG, @kaylareopelle, @ericmustin, and I concluded that opentelemetry-instrumentation-base is a reasonable place to put shared logic for SQL instrumentation.

We acknowledged that the shared logic will not be used by all instrumentation gems, but think -base is a good place anyway.
The -base gem will be a bit bigger, but we think the trade of disk space for simpler dependency resolution is worth it.
Gives us an existing place to make progress on the shared logic now without the additional effort and dependency complexity of adding another gem to the contrib mono-repo.


Update version bounds?

Hello Frerich! Great library! Works just fine!
One small problem is that version bounds are a bit out of date. In particular, base of version 4.10 contains many useful updates, and 4.11 is out as well, but this package has 4.9 upper bound. Modern template-haskell is also out of range.
As far as I can see, the package actually works with more up to date base and template-haskell versions. In particular, I use base-<IP_ADDRESS> template-haskell-<IP_ADDRESS> and it seems to be alright.

Thanks for reminding me of this - it seems that by now, GHC 8.4.1 works, too!


[Feature Request] Actions after successful login

A way to setup actions after a user logins successfully, like run a command from console...
with perms compatibility (like if user has certain perm run this command)...
also if the command should run only on first-time login...

Hi, @joex92!
Interesting idea. I'll add in a future update of OpeNLogin.


Redesign: Neobrutalism

It seems to me that redesign info / issues are scattered on too many places with too much text, let's have one simple issue for tracking what's currently happening. I'll keep this updated.
Related discussion:

[ ] #3710

Landing:

[ ] #3844
[ ] #3944
[ ] #3945

[ ] #3947
[ ] #3928

Navbar and Footer (should be across whole app, not just landing):

[ ] #3946
[ ] #3948

Old redesign ideas are tracked here:

[ ] #3956

I see that the hover states for urls is missing in the design @petersopko @yangwao

I see that the hover states for urls is missing in the design @petersopko @yangwao

for design issues best ping @exezbcz

I see that the hover states for urls is missing in the design @petersopko @yangwao

Hi, sorry for the late reply, yes, for design it is better to ping me. There is no hover in figma as it comes from a system that repeats. Therefore hover on text will cause bold and socials will change bg color to accent-light.
Thanks for the ping @yangwao

hi @exezbcz do we have a disabled state UI? I think we need that for the arrow in the carousel when reaching the start/end carousel pages, similar to the current implementation in production

@exezbcz does the navbar UI final already? If I compare it with the current implementation missing some buttons, such as history, language, dark mode, and chain selection (is it moved to the landing page section?). and how does the search bar in the navbar work, because on the desktop seems missing in the navbar?

Hey @preschian, good questions, I didn't think specifically about the disabled state for arrows, we can resolve it quickly how it's done on multiple pages, and remove the element once you reach the end of the carousel. As for the search bar in the navbar, it's in Figma in the "components + prototypes" subpage. Maybe I did not make it clear enough, sorry for that. Missing elements in nav - yup, that's correct, we are currently missing language, dark mode, and network. History is built in search bar results, that's the state if you only click on the search bar - see search bar prototype in Figma file. We dropped language bcs we think it will be better in profile settings and just to make nav bar cleaner. The dark mode could be here - didn't put it there, I will think about it. The network button isn't necessary, we are doing landing with NFTs from all networks - as mentioned in #3710.  Thanks!


Add labels to every field so that screen readers can interact with them.

Description
For the most part, questions are rendered with their labels adjacent and content-ful - but for the handful where we don't, add the content.  for all of them, associate the labels with the inputs.  for the ones where the associated label would be duplicative, apply sr-only class.
Tested by adding an assert - browser tests all pass - removed the assert because a ton of unit tests would have needed to be updated to no real benefit.
Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Issue(s)
Addresses #1456.

Looks like name and address question are missing screen reader labels.

Looks like name and address question are missing screen reader labels.

Ahh I see. The name and address question fields use labels, so we don't need the screen reader label for them. It would be helpful to comment that in at least the PR description that the multi-field questions have labels attached to the fields, and the single-field questions don't.


React and Venn.js, hover labels not appearing

Hello, I'm using venn js for my React application and I cannot seem to get the hover tooltip to show like in this example:
http://benfred.github.io/venn.js/examples/intersection_tooltip.html
I use this as the method of initiating it:   var tooltip = d3.select("body").append("div")       .attr("class", "venntooltip");
However I've also tried replacing body with a 'div' I create and in that case it just places the tooltip at the bottom of the screen when hovering over regions.  Does anybody have experience with this in React that can point me in the right direction?

I don't have any experience with react here , but it sounds like you're missing the CSS in that example.
Do you have something like this in the CSS ?
.venntooltip {
  position: absolute;
  text-align: center;
  width: 128px;
  height: 16px;
  background: #333;
  color: #ddd;
  padding: 2px;
  border: 0px;
  border-radius: 8px;
  opacity: 0;
}

.Filter .venntooltip {
    /* position: fixed; */
    text-align: center;
    width: 150px;
    height: 16px;
    background: #333;
    color: #ddd;
    padding: 2px;
    border: 0px;
    border-radius: 8px;
    opacity: 0;
  }

position should be absolute, not fixed. If I comment that line out in the example, I get the tooltip placed at the bottom of the screen like this:

I will attempt to try this soon, I for some reason started getting this error and I'm unsure what it is from.
TypeError: nodes.exit(...).transition is not a function

@benfred My hover results in an off position tooltip.  Any ideas?


Revert "Add support for UDPv6 receive to NPM (#10628)"

What does this PR do?
Reverts #10628 and #10711.
Motivation
We do not want to introduce changes with potential memory impacts in 7.35 relative to 7.33.
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] The appropriate team/.. label has been applied, if known.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the config template has been updated.

CI is failing due to inability to contact CentOS vault and is unrelated to this change. The tests pass on the other OS/distro/versions, so I'm confident in merging this.


Opportunities keyword search

https://trello.com/c/qdNbRJ4e/331-supplier-can-search-for-buyer-on-dos
Added simple test for smoke tests, expanded into much more arduous tests for full suite which required me to fix up a few of the step definitions beforehand (who knew we were never able to uncheck a checkbox before?)

I think you are going to run into the fun skip-staging stuff needed as these will fail on non preview environments :(

@idavidmcdonald I wasn't particularly planning on merging this before the feature had made it to production - there seemed a lot of keenness to just get the damn feature out at the end of last week - not sure where that went.


Prevent app from reloading after android dynamic color changes

Can I prevent my flutter app from reloading after I the android dynamic colors change?
I'd like to keep the app state and only have the colors change. Like in native android apps like Gmail, Calendar, etc.
How to reproduce:

Open the flutter app with DynamicColorBuilder

Minimize the app without terminating it, long press the home screen and change the dynamic color scheme (on Pixel phone)

Go back to the flutter app and see it reloading.

tmaihoff

Did you able to solve the issue?

No, unfortunately not


How to build and run this mod locally ?

How to build and run this mod locally ?  trying with npm ci and hugo server doesn't work.
also, how does this search compare to https://github.com/hugomods/search ?
let's say we would like to use one of the search as mod, which one you recommend ?
can you give an simple example where

is display and some simple data for search
Thank you.

Duplicate to hugomods/search#203


n3iwf creates IPsec tunnel

When i use free5gc, the n3iwf module does not create ipsec tunnel. it creates xrfmi interface. but in free5gc compose, in the n3iwf container, i have two interfaces namely ipsec and xfrmi... do you know why does it happen in compose and not in the classical deployment of free5gc ?
and to add more info, the interfaces ipsec and xfrmi in the compose container, have the same IP address. i know that can change the IP address of the ipsec...but still.........

Hi @AravindkannanCT
Thanks for raising this issue.
@ianchen0119 I think we need to update the compose command for N3iwf to remove the startup script. I can do it, what do you think?

Hi, thanks for the reply. I did siable the command in docker-compose from my side. i was trying to connect the  NWu-Non3GPP-5GC UE (https://github.com/fasferraz/NWu-Non3GPP-5GC) to the N3IWF. but N3iWF container crashes immediately after a successful connection between UE and the core.
But when i have the same setup on the classical deployment, the N3IWF did not crash and i was able to access internet from the Non-3GPP UE.

Hi @abousselmi
I think your solution works.
thanks for your help.


⚠ Bofrost.lu has degraded performance

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

HTTP code: 200
Response time: 1414 ms

Resolved: Bofrost.lu performance has improved in 195539c after 6 minutes.


Proposal: Let the user choose whether to have the bar at the top or bottom

One of the first things I noticed about Insporation was that the bar was at the bottom and not at the top. I can live with that in an emergency, but I would prefer to have the bar at the top, as in the Diaspora web interface, or leave it up to the user to decide whether the bar is at the top or bottom. For me, a bar at the top is not only a habit, but also the fact that it is located directly above the Android bar when it is at the bottom and in the heat of the moment you can easily get the wrong button.

This design element is called a bottom navigation bar and the standard for new apps these days. It's likely something we will not change, sorry.
See https://material.io/components/bottom-navigation

read this for iOS design principles: https://developer.apple.com/design/human-interface-guidelines/ios/bars/tab-bars/
Its better to follow App design guidelines on its specific platform than to try to mimic web design.

OK that makes sense to me as far as pure navigation is concerned. But as soon as the notifications are running over it it is in my eyes that they are better visible at the top of the page than at the bottom. Apart from the problem I described that the Android bar is directly below. In the end it's up to you Jonne, I can live with it.


Invalid API Key

Get the error invalid API Key on  trying to install extensions.
I have enterned API Key in System > Settings before.

I have the same problem too.

Same here (version: 0.8.8)

I have the same error too!

all the folders are writable but i'm getting the same error yet !

That`s why i would never use y product off YOOtheme.
There is ZERO help and no communication between the devs and the community :(

The API Key is not active at the moment, can you tell me the steps how to recreate this issue.

@hostianer We have a [https://gitter.im/pagekit/pagekit](community chat) for Pagekit. Just step by :wink:

We released the Pagekit Beta today. I close this issue because the code base completely changed. Please open a new issue if it still exists.


fix(core): 18818 images on about page

migrate to react-cosmos 6
relative links for markdown
split document into sections for markdown
restructuring content into blocks for markdown
new design for Atlas About page
markdown for plans as translatable asset
prototype subscriptions config and ui with custom plan
fix keepalive component (application opens 2 screens for 2 tabs 19489)
refactor move global types to proper place
fix selectable panel headings
update various deps
remove unused abandoned code
fix failing build in CI

https://kontur.fibery.io/Tasks/Task/Add-images-on-Kontur-Atlas-About-page-18818
https://kontur.fibery.io/Tasks/Task/Implement-relative-links-in-Kontur-app-About-page-markdown-18893
https://kontur.fibery.io/Tasks/Task/Migrate-to-last-version-of-react-cosmos-17463
https://kontur.fibery.io/Tasks/Task/FE-Application-sometimes-opens-2-screens-for-2-tabs-19489
https://kontur.fibery.io/Tasks/Task/FE-Implement-subscription-config-and-localization-for-Atlas-in-markdown-19280
https://kontur.fibery.io/Tasks/Task/FE-CI-investigate-failing-workflow-19587

Summary by CodeRabbit
Summary by CodeRabbit

New Features

Introduced a dedicated React Cosmos development server for component testing.
Added mock configuration and fixtures for improved testing of UI components.
Enhanced markdown rendering capabilities across multiple components using the markdown-to-jsx library.
Simplified the cosmos and cosmos:build scripts for easier execution.
Added a new plugin for Vite integration in the Cosmos configuration.
Updated Vite configuration for improved performance and debugging capabilities.

Bug Fixes

Addressed potential issues with Chrome's HSTS policy affecting local development server access.

Documentation

Updated README with new development setup instructions and troubleshooting tips.
Added comprehensive guides for using the Kontur Atlas platform and pricing plans.

Chores

Streamlined environment configurations by removing unnecessary variables.
Updated dependencies and improved testing strategies with new tools.
Enhanced coverage reporting configuration for tests.

@vkozio could you maybe rename the PR so that the future commit message in main would properly describe the summary of changes?


Discogs

I'm just leaving this as a stub with basic functionality. I'm very pleased with the functionality that's there, though. Seems rock solid. I might try to add a separate output for single and album, come to think of it. But take a look.

Closing this request and moving discogs.py over to slash_commander branch


Add "HEAD" method

Coverage remained the same at 98.627% when pulling 0e33c98ae49b3bc1d02cca6904585e2cdba620ca on HeadTriXz:master into bec5c13d507d24962f4096cec55920208cbd12aa on helperdiscord:master.

Coverage remained the same at 98.627% when pulling 0e33c98ae49b3bc1d02cca6904585e2cdba620ca on HeadTriXz:master into bec5c13d507d24962f4096cec55920208cbd12aa on helperdiscord:master.


some project updates and Response.send binding

I now understand how to use overloading to make the types more explicit. I'll close this for now and reopen with more expressive fns


Several changes to the build system

Hi Josef,
yesterday I had a look at the current status of Phonetisaurus build system and I started working on
a refactor. The refactor is not yet complete, but it is already usable (with minor changes).
Here I will briefly describe what I changed and why:

GNUC and DARWIN where defined in Makefile.in after custom checks. The first one was used to indicate openmp availability, the latest one to indicate Mac OSX. Compilers already define macros to indicate these two capabilities, so I used the compiler defined macros instead of the custom tests. Moreover if tests are needed, they should run in configure, not in Makefile.am (or Makefile.in);
I moved configure.ac and Makefile.am (was Makefile.in) outside of .autoconf directory. I do not know if there is any sane way to move them back in .autoconf directory, but in my experience autotools do not work very well when the sources are in a subtree of the parent directory with respect to the configure file. In particular it is not easy at all to make out-of-tree compilation to work (with the current setup out-of-tree compilation is working);
I added better tests for openfst. The tests are now more similar to other similar tests for other libraries. They are not complete (e.g., I test only symbols in fst and not in fstfar or fstngram, but they should already work in most situations);
I introduced tests for python;
I replaced custom made Makefile.in with Makefile.am. This guarantee out-of-tree compilation, proper usage of compilation flags (with conditional compilation as well) and that common users expectations are met (e.g., --prefix option, DESTDIR variable and uninstall target are now working as expected);
I introduces libtool. Why this is not strictly required, in my experience it simplify the building of shared libraries a lot;
7 I renamed phonetisaurus_train and phonetisaurus_apply into phonetisaurus-train and phonetisaurus-apply, according to the name of other binaries. Moreover they are now installed by the Makefile.

As a result of this work you can now compile everything with the following:
rm -fr _build
mkdir -p _build
cd _build
../src/configure
make
make install
cd ..
cp _build/.libs/Phonetisaurus.so phonetisaurus
python setup.py install

The only drawback of the above procedure is that you will end up with two copies of Phonetisaurus.so installed, as make install also install it in python modules directory (but not where your module expect it to be).
The reasoning behind these changes, despite the fact that they seem better to me, is that I need --prefix option and DESTDIR variable support for packaging. Moreover I will also need to add custom variables to building (needed for QA), which is now supported. And I will need to replace some flags (which is not yet supported). It would be nice to have a minimal test set. All these are much easier when using automake.
Let me know if there is any chance that this pull request will be accepted and if I have to adapt it.
Best regards,
Giulio

Wow thanks for this @giuliopaci I will definitely accept it.  There are a couple of small things, most of which you touched on already.  I'll go through it in detail the next couple days.  Main things are that the _apply and _train scripts probably need to stick with the present names, as they are related to the kaldi tag; but you could probably even omit them from your .deb.  I think we can also just drop openmp.  I previously played around with it a bit, but it is not actively in use in any of the builds right now, and I don't think it is really needed.
If this also solves the OSX build, then it will also close #25 which would be neat.

If it is useful for Kaldi, than I want it in the package: one of my long
term goal is to have all Kaldi requirements packaged in Debian and usable
for Kaldi without having to recompile them.
Do you think it will be possible to plan a name change for those scripts?
It should not be difficult to create a link to those scripts with the
current names during the transition.
I also have similar issues with rnnlm. Do you think we can rename it? Do
you think it would be possible to support --help in it?
Regarding openmp, I tried to disable it, but the build of
phonetisauru-g2prnn failed. Is this expected?
Finally, I do not think compilation will work out of the box on Mac OSX,
but we can try it, as Travis supports Mac OSX workers (in the worst case we
will just have to compile openfst from sources, if brew install openfst is
not working).
Il 19/ago/2017 21:20, "Josef Novak"<EMAIL_ADDRESS>ha scritto:

Wow thanks for this @giuliopaci https://github.com/giuliopaci I will
definitely accept it. There are a couple of small things, most of which you
touched on already. I'll go through it in detail the next couple days. Main
things are that the _apply and _train scripts probably need to stick with
the present names, as they are related to the kaldi tag; but you could
probably even omit them from your .deb. I think we can also just drop
openmp. I previously played around with it a bit, but it is not actively
in use in any of the builds right now, and I don't think it is really
needed.
If this also solves the OSX build, then it will also close #25
https://github.com/AdolfVonKleist/Phonetisaurus/issues/25 which would
be neat.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AdolfVonKleist/Phonetisaurus/pull/27#issuecomment-323542664,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATBq8NTbF3uCnD5stW4qHIE_PPfWGfSks5sZzWQgaJpZM4O8Xym
.

Hi again,
I updated the pull request with a few commits that fix compilation on Mac OSX (I also updated Travis configuration so that now it is compiled on Linux with gcc 4.9, Mac OSX with gcc and clang). Is there any reason why gcc 4.9 was used for testing and not latest available compiler?
I had to fix compilation when openmp is not enabled... But this means that now openmp is used when it is enabled. I think this is the correct behaviour, although, given what you said about openmp, probably it should be disabled. Or enabled on demand. Do you agree to disable it?
The workaround for Mac OSX flags parsing is making compilation "fail". This is because openfst flags parsing returns 1 when --help is passed to programs (0 should be the correct return value as the user explicitly requested for help). I temporarily added a workaround to Travis configuration, but it would be better to make flags parsing work on Mac OSX as well.
Cheers,
Giulio

No we can move up to a later version of gcc.  I do want to use at least 4.9 though, but Ubuntu 14.04 default to 4.8 I think.  Ideally I'd like a wider range of supported versions, but I just don't have the time.  No issue with the --help message, and I happy to disable openmp by default.  It is a bit more complicated and poorly documented how to use the RNN stuff, and I don't really think anyone is presently using it anyway.  I'll try to finish going through this all by end of night. Thanks again for the efforts.

I have gone through the commit(s) in a bit more detail now.  Again it is much appreciated and introduces a large number of improvements.

Regarding the dash vs underscore naming, in principle I have no issue with making the changes you request to the scripts, but before I try to push or retag that, can you explain the reason?  Is that a debian/ubuntu packaging policy requirement?

Regarding the configure script<EMAIL_ADDRESS>let's change that to<EMAIL_ADDRESS> I completely forgot about that, but it is better to be consistent on that score I think, especially if it will go into a package.

Regarding the python bindings, not everyone uses these, and not everyone wants to install the python development headers.  I'd prefer to keep them as a non-default option, the same way this works in the latest version of OpenFst.  Right now it looks like they are required and trigger a configure error if not found.

Regarding OSX: let's forget about it / not pursue any further in this commit series.  We are trying to shoehorn too many things into one commit.

Regarding kaldi integration: There is now a script for this in kaldi, install_phonetisaurus.sh.  It had one remaining issue related to linking and libtool and the default kaldi OpenFst install (my approach still required the user to update LD_LIBRARY_PATH with the OpenFst libs, but I manually verified that your improved configure scripts work with the existing setup, and handily resolve this issue.  They also appear to work fine with the manual configure options and existing install script.

There is one issue: the binaries are no longer build in src/bin/, but rather just in src/.   Unless there is a strong justification for this, it I'd prefer to keep these in src/bin, mainly because it would mean there would be no need to make another pull request to kaldi (no breaking changes).
The basic sanity test for this integration under Ubuntu 16.04 is something like:

$ git clone https://github.com/kaldi-asr/kaldi.git
$ cd kaldi/tools/
$ make openfst
$ cd extras/
$ ./install_phonetisaurus.sh
$ phonetisaurus-g2pfst --help

If we can agree on (or I can at least understand) the above, then I think we can merge it.

On 28/08/2017 16:14, "Josef Novak"<EMAIL_ADDRESS>wrote:

Regarding the dash vs underscore naming, in principle I have no issue
with making the changes you request to the scripts, but before I try to
push or retag that, can you explain the reason? Is that a debian/ubuntu
packaging policy requirement?

No, it is not a requirement for Debian, it is just my expectation as a user
to have all the commands with exactly the same prefix and not having to
remember which prefix is associated to each command (ie, it is a UX issue,
not a policy violation issue). The only requirement for Debian is to avoid
collisions with other packages.

Regarding the configure script<EMAIL_ADDRESS>let's
change that to<EMAIL_ADDRESS>I completely
forgot about that, but it is better to be consistent on that score I think,
especially if it will go into a package.

Ok, I will update it.

Regarding the python bindings, not everyone uses these, and not everyone
wants to install the python development headers. I'd prefer to keep them as
a non-default option, the same way this works in the latest version of
OpenFst. Right now it looks like they are required and trigger a configure
error if not found.

If I understand correctly you want them disabled by default. Is it right?
If yes I can add a --enable-python flag to configure.

Regarding OSX: let's forget about it / not pursue any further in this
commit series. We are trying to shoehorn too many things into one commit.

Ok, but it is already working. :-)

Regarding kaldi integration: There is now a script for this in kaldi,
install_phonetisaurus.sh. It had one remaining issue related to linking and
libtool and the default kaldi OpenFst install (my approach still required
the user to update LD_LIBRARY_PATH with the OpenFst libs, but I manually
verified that your improved configure scripts work with the existing setup,
and handily resolve this issue. They also appear to work fine with the
manual configure options and existing install script.

Ok. This has to do with using libtool, which by default set rpath in
binaries so that they can find the libraries.

There is one issue: the binaries are no longer build in src/bin/, but
rather just in src/. Unless there is a strong justification for this, it
I'd prefer to keep these in src/bin, mainly because it would mean there
would be no need to make another pull request to kaldi (no breaking
changes).

I am not sure that this can be changed at all (I never tried to compile
programs in non-default location), but I can try. However it is not correct
that kaldi relies on internal details of the building process. From kaldi,
or any user, perspective, the installation interface should be ./configure
&& make && make install, ./configure is now able to use --prefix and other
options, so that they can achieve any desired installation structure goals.

The basic sanity test for this integration under Ubuntu 16.04 is
something like:

$ git clone https://github.com/kaldi-asr/kaldi.git
$ cd kaldi/tools/
$ make openfst
$ cd extras/
$ ./install_phonetisaurus.sh
$ phonetisaurus-g2pfst --help
If we can agree on (or I can at least understand) the above, then I think
we can merge it.

Ok.
Cheers,
Giulio

No, it is not a requirement for Debian, it is just my expectation as a user to have all the commands with exactly the same prefix and not having to remember which prefix is associated to each command (ie, it is a UX issue, not a policy violation issue). The only requirement for Debian is to avoid collisions with other packages.

OK, that is reasonable to me.  Let's just go for it.

If I understand correctly you want them disabled by default. Is it right? If yes I can add a --enable-python flag to configure.

Yeah, that would be perfect.

Ok. This has to do with using libtool, which by default set rpath in binaries so that they can find the libraries.

Cool - again I was just commenting that it already works.

Ok, but it is already working. :-)
Ah, OK!  Somehow I thought there was still something not quite working there.  Sounds good.

I am not sure that this can be changed at all (I never tried to compile programs in non-default location), but I can try.

Ok, forget it, if those are the standard let's just keep your changes.

However it is not correct that kaldi relies on internal details of the building process.

It isn't the fault of Kaldi, it is my fault.  I'm responsible for setting the extras compile script to use the bin dir by default without modifying configure.

Sounds like that resolves all my questions.  I'll merge after one more trip through the test setup.  Thanks again!

I have started doing a rebase and implement most of the additional features.
I will force push my changes tomorrow or the day after tomorrow (I still
want to do some minor cleanup).
Cheers,
Giulio
Il giorno 28/ago/2017 19:44, "Josef Novak"<EMAIL_ADDRESS>ha
scritto:

No, it is not a requirement for Debian, it is just my expectation as a
user to have all the commands with exactly the same prefix and not having
to remember which prefix is associated to each command (ie, it is a UX
issue, not a policy violation issue). The only requirement for Debian is to
avoid collisions with other packages.
OK, that is reasonable to me. Let's just go for it.
If I understand correctly you want them disabled by default. Is it right?
If yes I can add a --enable-python flag to configure.
Yeah, that would be perfect.
Ok. This has to do with using libtool, which by default set rpath in
binaries so that they can find the libraries.
Cool - again I was just commenting that it already works.
Ok, but it is already working. :-)
Ah, OK! Somehow I thought there was still something not quite working
there. Sounds good.
I am not sure that this can be changed at all (I never tried to compile
programs in non-default location), but I can try.
Ok, forget it, if those are the standard let's just keep your changes.
However it is not correct that kaldi relies on internal details of the
building process.
It isn't the fault of Kaldi, it is my fault. I'm responsible for setting
the extras compile script to use the bin dir by default without modifying
configure.
Sounds like that resolves all my questions. I'll merge after one more trip
through the test setup. Thanks again!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AdolfVonKleist/Phonetisaurus/pull/27#issuecomment-325424321,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATBq1KLCLKms36R_8kzu0_Ehh7LZ64Zks5scvyKgaJpZM4O8Xym
.

Hi,
I completed the changes that we discussed for this pull request (and rebased on master).
In particular:

I added --enable-openmp and fixed compilation with openmp;
I added --enable-python option, with conditional Phonetisaurus.so in Makefile;
I moved all python related files in python subdirectory;
I moved configure script in top directory (but added a configure script in src/ so that it can also be used; I also compile binaries in bin/, so that when configure is invoked in src it will put binaries in bin/ as before);
I updated .travis.yml file so that it compiles on MacOSX using both gcc and clang;
I renamed the scripts as already discussed;
I updated README.md according to recent changes;
I fixed dist-* targets, so that make dist-gzip creates a proper tarball;
I updated email in configure.ac;
out-of-tree compilation is now working (i.e., mkdir build; cd build; ../configure; make; make install);
I added code in configure.ac to search for utf8.h, so that the system one is preferred if found;
I dropped m4 files from autoconf-archive, as it is better to rely on autoconf-archive availability.

Commit 6c48e02 should be compatible with current script in kaldi (although I did not test it).
Cheers,
Giulio

This looks great.  I see one remaining issue.  If I try to compile with configure --prefix=`pwd` , then make install fails:
libtool: install: /usr/bin/install -c bin/phonetisaurus-align \
    /home/ubuntu/Phonetisaurus/bin/phonetisaurus-align
/usr/bin/install: 'bin/phonetisaurus-align' and \
   '/home/ubuntu/Phonetisaurus/bin/phonetisaurus-align' are the same file

I was able to fix this by modifying Makefile.am to change bin_PROGRAMS to src_bin_PROGRAMS, and updating all bin_phonetisaurus_X to src_bin_phonetisaurus_X, and adding src_bindir = $(prefix)/bin.
This then builds the binaries in the src/bin directory, where the python wrapper scripts are already sitting, and resolves the install problem with --prefix=`pwd` .  I also prefer this from a consistency standpoint.
If those changes are acceptable from your configure/build side of things either I can just push them myself, or you can make one more commit.  Then we will be done.
I noticed that travis seems to not like compiling with clang as well, but I think we can ignore that as a non-issue for now; OSX build works locally for me, and travis succeeds with gcc.
What do you think?

Hi,
On 30/08/2017 10:10, "Josef Novak"<EMAIL_ADDRESS>wrote:

This looks great. I see one remaining issue. If I try to compile with
configure --prefix=pwd, then make install fails:
libtool: install: /usr/bin/install -c bin/phonetisaurus-align
/home/ubuntu/Phonetisaurus/bin/phonetisaurus-align
/usr/bin/install: 'bin/phonetisaurus-align' and
'/home/ubuntu/Phonetisaurus/bin/phonetisaurus-align' are the same file

This is partially expected, due to the fact that using "configure
--prefix=pwd" you are installing in the build directory, and as you are
invoking configure from inside the source directory, you have three
different directories that may conflict (i.e., source, build and
installation directories).
If you already have to change the building procedure, I suggest to change
it drastically, but obtaining very similar results.
My suggestion is to have three separate directories.
Suppose that you still want binaries in Phonetisaurus/src/bin, I suggest
something like:
mkdir -p Phonetisaurus
cd Phonetisaurus
git checkout into sources
INSTALL_PATH=" `pwd`"/src
mkdir -p build
cd build
../sources/configure --prefix="$INSTALL_PATH" && make && make install

I was able to fix this by modifying Makefile.am to change bin_PROGRAMS to
src_bin_PROGRAMS, and updating all bin_phonetisaurus_X to
src_bin_phonetisaurus_X, and adding src_bindir = $(prefix)/bin.
This then builds the binaries in the src/bin directory, where the python
wrapper scripts are already sitting, and resolves the install problem with
--prefix=pwd. I also prefer this from a consistency standpoint.

This is not solving the issue, just moving it around a little bit.
From configure point of view this is not more consistent, because you are
compiling src/bin/ that will be installed in , that by
default is /bin. In my opinion the most sane approach is to remove
both src/bin/ and bin/ prefixes (that have to be intended as
/src/bin and /bin). I added bin prefixes just to keep
compatibility with the build script in kaldi, so that if you run configure
from src (i.e., builddir=src), then "make" will build binaries in src/bin.
But that is just a hack.

If those changes are acceptable from your configure/build side of things
either I can just push them myself, or you can make one more commit. Then
we will be done.

In my opinion the safest approach is the one I described above.
Alternatively we can move the scripts from bin to scripts, and remove the
bin/ prefix in configure. In this way make install will work again.
I will upload an update in a few minutes with these changes, so that you
may have a look at them.

I noticed that travis seems to not like compiling with clang as well, but
I think we can ignore that as a non-issue for now; OSX build works locally
for me, and travis succeeds with gcc.

It worked yesterday. I guess it is just a temporary network failure.
Cheers,
Giulio

Ok.  All agreed, and as usual thanks for the extra explanation.  One last question; since we already break the kaldi script, what else would you want to change?  We don't have to have the configure copy in src/ I guess.

I just removed src/configure.
Ideally the other changes that I would like to see are:

rnnlm: there is no --help, no phonetisaurus- prefix, no documentation in README. It would be nice to have this fixed;
in latest packaged version there was phonetisaurus-calculateER. Why has it been removed? Is there a replacement for it?
it would be nice to improve the setup.py integration with autotools;
it would be nice to have a test suite;
it would be nice to have all the warnings removed;
it would be nice to have the MacOSX workaround removed;
it would probably be nice to install python server when user enable python.

Of these, the only problematic things for .deb packaging are rnnlm issues. This is also something that may affect kaldi as well. If kaldi is using python bindings, then the changes in setup.py may also affect kaldi.

Ok.  All points are good ones, and about half are on my list, but I think we can merge this PR, and address those later since they will not further break anything.
The bindings are not used in any of the kaldi scripts as far as I know, so no issue there.
The vanilla rnnlm trainer is basically just an old frozen version of the Mikolov tool.  I'm not sure how much I want to invest into that ATM, or if the effort is better spent elsewhere.
The calculate error script needs to be refactored very heavily (rewritten), or just swapped for standard sclite.  Undecided on that.
I'm working on refactoring the documentation, and setting up the test suite, but it will probably be a while yet.
OSX builds on travis seem super backed up, but I'll merge this after they finish up.
Feel free to update setup.py in another PR if you are so inclined.
The server bit I'd like to be expand on considerably; at the moment it is still just a stub; and I'm not totally convinced it really belongs here, as opposed to somewhere complementary.


Signal Transformation Computation is too slow

We copy the dataset and use a loop over the whole dataset which is too baaaaad :
'''
def specific_invert(self, df):
    df_orig = df.copy();
    df_orig.iloc[0] = df.iloc[0];
    for i in range(1,df.shape[0]):
        df_orig.iloc[i] = df.iloc[i] -  df.iloc[i - 1]
    return df_orig;

'''
There is room for improvement.

Fix : use aggreagtes like cumsum, cumprod on shifted series etc
for the previous example , an equivalent rewrite is :
def specific_invert(self, df):
    df_orig = df - df.shift(1);
    df_orig.iloc[0] = df.iloc[0];
    return df_orig;

detect all such errors in all transformations.


[capability] Add capability for simulate bad network

Please also update capability.proto, device.proto, grpc/client.py, grpc/service.py,
we may also bring up the grpc client/server test in seperate ticket


[WIP] Add outputs for cluster name and location to be used in the Marketplace UI

/gcbrun

/gcbrun


Could not install the extension XXX on tenant default due to the following error: Error code: 85132273

We are getting this error when deploying an extension to a 12.1.22475.22720 (ES) docker image, using AL 0.16.19969.
What does that error mean? There is another Issue mentioning this error #1758 , but the author closed it without comments.
Some extra info:

The first time we tried to publish the app, it failed with a different error, but we forgot to write it down, and now we only get this error code, even if we unpublish the extension.
The app is actually published, but not installed. We get the same error code if we try to install it using the Install-NAVApp powershell command.

The error indicates "duplicate key". It sounds like the tenant DB part of the install committed, but something went wrong during the final tiny piece of the install operation (app DB commit phase). Some things to check include:

If this is single tenant, restart the NST. If the above is an accurate diagnosis, the extension should appear installed (app DB issue repaired on mount).

If this is multi tenant, remount the tenant. Similar to 1, the internal state will be corrected on mount.

If these options don't pan out, can you check the event log for errors? Stack traces are particularly helpful in determining what data was duplicated. The event log might also contain info about the initial failure which would help.

If you can look at the DB directly, can you check the tenant DB for data (particularly NAV App Installed App)? If there is data here, this confirms that the tenant DB transaction did finish (meaning 1 or 2 should have been valid workarounds.


WIP: Small PoC for generating schema for messages?

I will be closing this PR, it was just to share with you the scrappy PoC, feel free to continue the discussion on the Issue


Exec format Error

[E][2024-08-27T01:03:37+0000][1] newProc():225 execve('/app/run') failed: Exec format error

I get this error when running it on a Raspberry Pi 4 with Ubuntu 24.04.
uname -a result:
Linux challengeInstance 6.8.0-1004-raspi #4-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 02:29:55 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

Your Raspberry Pi is arm64 but your /app/run file is probably not arm64. You should compile it for arm64.

How I tried,
RUN GOOS=linux GOARCH=arm64 go build -v -ldflags '-w -s' -o ./cmd/jailrun

in the docker and got errors with make -j in jail

Jail itself does not need to be recompiled. The /app/run file that you created needs to be compiled for arm64.

So then what will i need to change

We don't know anything about your /app/run file, so we can't help you here.

/app/run file is the standard one from this repo

It is a python script


METASPACE Version info

Asana task: https://app.asana.com/0/32351386244849/476375387859279
It can be useful, both for debugging as well as for API users, to know what version METASPACE is currently running. The best indicator of version we have is the Git commit hash and date.
During deployments:

Report production deployments to Slack and Sentry
Write a version.txt file containing the deployment date, commit date and commit hash of the latest deployment
Append to a version-history.txt file that keeps a historical log of deployments
Serve these as static files or through GraphQL

Closing this - not enough interest. Also, the effective deployment history can be seen by doing git reflog --date=iso on the server


Warning message in OUTPUT panel (source: Shared)

Does this issue occur when all extensions are disabled?: Yes (Using extension bisect)

Version: 1.83.0
Commit: e7e037083ff4455cf320e344325dacb480062c3c
Date: 2023-10-03T16:11:49.843Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.5.4-1-default
Steps to Reproduce:

Start VSCode.
Go to the OUTPUT panel.
Choose Shared source.
See the warning messages.

Warning messages content:

2023-10-06 10:44:18.711 [warning] [lua]: Couldn't find message for key config.diagnostics.circle-doc-class.
2023-10-06 10:44:18.711 [warning] [lua]: Couldn't find message for key config.diagnostics.inject-field.
2023-10-06 10:44:18.711 [warning] [lua]: Couldn't find message for key config.diagnostics.missing-fields.
2023-10-06 10:44:18.711 [warning] [lua]: Couldn't find message for key config.diagnostics.circle-doc-class.
2023-10-06 10:44:18.711 [warning] [lua]: Couldn't find message for key config.diagnostics.inject-field.
2023-10-06 10:44:18.711 [warning] [lua]: Couldn't find message for key config.diagnostics.missing-fields.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.basic.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.bit.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.bit32.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.builtin.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.coroutine.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.debug.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.ffi.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.io.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.jit.
2023-10-06 10:44:18.712 [warning] [lua]: Couldn't find message for key config.runtime.builtin.jit.profile.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.jit.util.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.math.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.os.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.package.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.string.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.string.buffer.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.table.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.table.clear.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.table.new.
2023-10-06 10:44:18.713 [warning] [lua]: Couldn't find message for key config.runtime.builtin.utf8.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.fileEncoding.utf8.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.fileEncoding.ansi.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.fileEncoding.utf16le.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.fileEncoding.utf16be.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.version.Lua 5.1.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.version.Lua 5.2.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.version.Lua 5.3.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.version.Lua 5.4.
2023-10-06 10:44:18.714 [warning] [lua]: Couldn't find message for key config.runtime.version.LuaJIT.

Please diagnose the root cause of the issue by running the command F1 > Help: Troubleshoot Issue and following the instructions. Once you have done that, please update the issue with the results.
Happy Coding!

@TylerLeonhardt This message is coming from here - https://github.com/microsoft/vscode/blob/13ba50105b216a4b6237d2ca8b1789a6523af8c1/src/vs/platform/extensionManagement/common/extensionNls.ts#L52

This is caused by the Lua extension. Can you please file this over there: https://github.com/LuaLS/lua-language-server


Update microsoft-public-symbols.md

@EliotSeattle - This PR is ready to go on it's way to master/live.


:robot: Add sharplaps.vm

Automated PR from https://github.com/mandiant/VM-Packages/issues/539 :rocket:

@Menn1s, @day1player, @skollr34p3r please review


index page: challenges: limit to 3 and sort by id by default

sorting by date currently doesn't show the newest on the same that as first. it would still be nice to fix date sorting as well.

implemented in 1976e3ca46c669c71fa3e3a7412b14721e1e9db5


Handle noindex directive

Resolve Issue #26

Thanks for PR!
looks good, but could you please to fix a few comments above? It should be merged when travis build will be ok.

really, thanks. Then it is a bug which should be fixed.

Tests passed.
Thanks!


Workspace support

Workspaces are a feature aimed at supporting multiple packages in the same repository. It makes large projects easier to manage by splitting them into smaller packages with independent dependencies. They handle editable installs and publishing automatically.
They are a commonly supported feature in other ecosystems, see the Review of large projects on github and Review of packaging tools. Our implementation will be modeled after cargo and rye.
Usage
There a two main usage patterns: A root package and helpers, and the flat workspace.

The workspace root is a directory with a pyproject.toml, all members need to be below that directory. The workspace root defines members and exclusions. All packages below it must either be a member or excluded. The workspace root can be a package itself or it is a virtual manifest.
Each member is a directory with a pyproject.toml that contains a [project] section. Each member is a python package, with a name, a version and dependencies. Workspace members can depend on other workspace members. You can consider the workspace another package source or index, similar to --find-links.
Workspace discovery
Currently in the uv pip interface, you have to explicitly provide the input files to use for dependencies. In the post-pip interface, uv will be based around workspaces with packages. For that, we need to find the relevant pyproject.toml files.

Go from the current directory up until we find a pyproject.toml. This is the current package.
If the package pyproject.toml contains a tool.uv.workspace section, it’s also the workspace root.
If not, go up again until we find a pyproject.toml

If it exists and contains a tool.uv.workspace section:

If we’re in the members, it’s the workspace root.
If we’re in the excludes, the package pyproject.toml is implicitly the workspace root, don’t go any further up.
If we’re in neither, error, that’s not allowed.

If it does not exist (we end up at the filesystem root), the package pyproject.toml is implicitly the workspace root (like cargo)
If it exists, but does not contain a tool.uv.workspace, ignore, our package in the data or test files of some other package.

Check: Go up further and check that there isn’t another invalid workspace root above ours that includes us.
Walk through the directories in the members and collect all other workspace member packages
Check: Between our workspace root and either member package directory, there isn’t any other stray pyproject.toml
Collect all entrypoint/scripts from the entire workspace, so we can run them no matter in which directory we are.
Lower the requirements of our target package using the information about the available workspace packages. By default, a required workspace package is installed as editable.

In our monorepo at work we have a fairly flexible layout, with more nesting / categorisation of projects. The rules we have for package discovery is that a) name in pyproject.toml must match folder name (limiting how much we have to read pyproject.toml files to do anything), b) a package cannot have another package inside it (limiting how much directory walking we need to do).

cc @potiuk regarding if this would work in Airflow

cc @potiuk regarding if this would work in Airflow

Generally yes. There are of course some details - particularly about optionality of those providers.

What we really would need in this case are those use cases:

a) power user (or CI) needs to install "albatross" package and all "providers" together and be able to hack on them together.
b) provider contributor (or CI) should be able to install one (or few, or all) of the "providers" separately in editable mode - but wiith the "albatross"  package installed from PyPi, or URL rather than from sources. this should allow for example to run the tests for main version of "provider_a" against past released version of "albatross" (or specifig tag / branch of "albatross")
c) albatross contributor should be able to install in editable mode just "albatross" and do not care about all other "providers"

Also an important use for airflow is that the providers might share the same top-level Python package with the main project, so part of their package structure is overlapping:

albatross
├── packages
│   ├── provider_a
│   │   ├── pyproject.toml
│   │   └── src
│   │       └── albatross
│   │           └── providers
│   │                └── provider_a
│   │                   ├── __init__.py
│   │                   └── foo.py
│   └── provider_b
│       ├── pyproject.toml
│       └── src
│   │       └── albatross
│   │           └── providers
│   │                └── provider_b
│   │                   ├── __init__.py
│   │                   └── foo.py
│├── pyproject.toml
├── README.md
├── uv.lock
└── src
    └── albatross
        └── main.py

I guess that will make things quite a bit difficult - because that means that when you do smth like thatin proivder_a:
from albatross.providers.provider_b import foo
It should import foo from provider b.

Another important thing is that this should nicely work with IDEs (free PyCharm for sure). The free PyCharm has limitation to only be able to have one "project" - no modules within project so you will not be able to open and hack together on provider_a and _b  or provider_a and albatross (which is very useful to be able to edit both.


JENKINS-26333 - Support for Custom Job Icon Plugin

support for custom icon plugin

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

I don't think that this plugin is a good candidate for DSL support. Unlike your example, the user has to look at the XML to determine the internal ID of the icon:
job {
//    customIcon('myFancyIcon.png')
    customIcon('6e63ee51fc9a8526befe96fa5d7c5498d80f515f.png')
}

If there is no way to configure the icon without having to look at the XML, I'm going to close this pull request.

Judging from how the plugin works, I fear there is no other way... Except maybe if we push the images itself too with the DSL.

I'm going to add support for uploading user content, see #475. After that has been merged I will have a second look at this PR.

Now it's possible to upload an icon from the DSL:
userContent('customIcon/job.png', streamFileFromWorkspace('icons/job.png'))

job('example') {
    properties {
        customIcon('job.png')
    }
}

I rebased your changes and merged them manually.


GIT_REMOTE required item not working correctly

The GIT_REMOTE item does check the command "git remote -v" that returns an object list as result. The applied match function does return an empty array if the match wasn't successful. This is not correctly checked.

Fixed in unstable branch.

Fixed in release 3.1


Adding --ignore-dependencies, --fail-fast, improve --continue-on-error, and improving CI report

Adding --ignore-dependencies and setting it as the default for running tests. Tests in one package cannot depend on the output of tests in another package, and there seems to be universal agreement on this. So it follows that tests can be run in full parallel.
Adding --fail-fast and fixing up --continue-on-error, so that jobs aren't killed part way through unless --fail-fast is set. When --continue-on-error is set, a failing job will not prevent subsequent jobs from running.
Improved the CI run report.
This adds depth information to the run order, as well as correcting as issue where the first item of a new level, was shown on the wrong level.
Using color to make the realtime output clearer for success and failures. As well as printing out the runtime per job, not the runtime of that job since the start of the whole run.
Also printing out the cumulative, saved and wall time in the final run report.
[ Run Order ]-------------------------------------------------------------------
├─[0] packages/examples/words/adipiscing
├─[0] packages/examples/words/amet
├─[0] packages/examples/words/consectetur
├─[0] packages/examples/words/dolor
├─[0] packages/examples/words/elit
├─[0] packages/examples/words/ipsum
├─[0] packages/examples/words/lorem
├─[0] packages/examples/words/sit
├─[0] packages/plugins/shared
└─[0] packages/plugins/plugin-package-yaml
  ├─[1] packages/examples/phrases/in-hac
  ├─[1] packages/examples/phrases/nullam-risus
  ├─[1] packages/plugins/plugin-build
  └─[1] packages/plugins/plugin-bundle
    ├─[2] packages/examples/phrases/lorem-ipsum
    └─[2] packages/plugins/plugin-test
      ├─[3] packages/examples/lorem-ipsum
      ├─[3] packages/examples/lorem-ipsum-docker
      └─[3] packages/plugins/plugin-all

[ Run / Command: build / Concurrency: 8 ]---------------------------------------
✅ packages/examples/words/consectetur                                     2.96s
✅ packages/examples/words/dolor                                           3.14s
✅ packages/examples/words/ipsum                                           3.46s
✅ packages/examples/words/elit                                            3.55s
✅ packages/examples/words/adipiscing                                      3.55s
✅ packages/examples/words/lorem                                           3.78s
✅ packages/examples/words/amet                                            3.78s
✅ packages/examples/words/sit                                             3.78s
✅ packages/plugins/shared                                                 2.15s
❌ packages/examples/phrases/in-hac                         (exit code: 2) 1.79s
✅ packages/examples/phrases/nullam-risus                                  1.79s
⏩ packages/examples/phrases/lorem-ipsum                                      --
⏩ packages/examples/lorem-ipsum                                              --
⏩ packages/examples/lorem-ipsum-docker                                       --
✅ packages/plugins/plugin-package-yaml                                    3.15s
✅ packages/plugins/plugin-build                                           3.09s
⏩ packages/plugins/plugin-test                                               --
✅ packages/plugins/plugin-bundle                                          3.09s
⏩ packages/plugins/plugin-all                                                --

[ build for All ]---------------------------------------------------------------

--[ Output: packages/examples/phrases/in-hac ]----------------------------------
src/index.ts:5:1 - error TS2304: Cannot find name 'dd'.
5 dd;
  ~~
Found 1 error in src/index.ts:5

[ Summary ]---------------------------------------------------------------------
Success: 13
Up to date: 0
Fail: 1
Skipped: 5
Excluded: 0
Total: 19
---
Cumulative: (cpu): 43.11s
Saved: 34.57s
Runtime (wall): 8.53s
[ build finished with 1 errors ]----------------------------------[ yarn.build ]

➤ YN0009: Build failed
➤ YN0000: Failed with errors in 8s 541ms

This fixes #214


Dependabot specified updates

Please provide a description of this PR:
As part of another PR proposing to update istio.io to have a monthly dependabot go module update, I ran a few tests, and noted that dependabot specified a few for istio/istio:
> dependabot update go_modules istio/istio --dry-run
...
INFO Results:
+-----------------------------------------------------------------------------------------+
|                           Changes to Dependabot Pull Requests                           |
+---------+-------------------------------------------------------------------------------+
| created | cloud.google.com/go/compute/metadata ( from 0.2.2 to 0.2.3 )                  |
| created | cloud.google.com/go/monitoring ( from 1.9.0 to 1.9.1 )                        |
| created | github.com/docker/cli ( from 20.10.21+incompatible to 20.10.22+incompatible ) |
| created | github.com/hashicorp/golang-lru ( from 0.5.4 to 1.0.1 )                       |
| created | github.com/onsi/gomega ( from 1.24.1 to 1.24.2 )                              |
| created | github.com/prometheus/common ( from 0.38.0 to 0.39.0 )                        |
| created | github.com/prometheus/prometheus ( from 0.36.2 to 0.40.7 )                    |
| created | go.uber.org/multierr ( from 1.8.0 to 1.9.0 )                                  |
| created | google.golang.org/api ( from 0.104.0 to 0.105.0 )                             |
+---------+-------------------------------------------------------------------------------+

This PR includes go gets for each of the specified packages with the exception of the github.com/prometheus/prometheus. The go get for that has issues with the version of the /envoyproxy/go-control-plane and go mod tidy will fail. Also I went with a later v2/2.0.1 of golang-lru as the specified version does not have the simplelru package.

@ericvn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

integ-ipv6_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ipv6

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

integ-ipv6_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ipv6

integ-cni_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

integ-ipv6_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ipv6

integ-cni_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-cni

integ-distroless_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-distroless

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

integ-ipv6_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ipv6

integ-cni_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-cni

integ-distroless_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-distroless

integ-telemetry_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-telemetry

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

integ-ipv6_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ipv6

integ-cni_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-cni

integ-distroless_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-distroless

integ-telemetry_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-telemetry

integ-ds_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ds

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests-arm64

unit-tests_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test unit-tests

integ-basic-arm64_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-basic-arm64

integ-ipv6_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ipv6

integ-cni_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-cni

integ-distroless_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-distroless

integ-telemetry_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-telemetry

integ-ds_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-ds

integ-operator-controller_istio
fe9ae4e3542cf2102da4a870c4d88653853af519
link
true
/test integ-operator-controller

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

https://github.com/oligot/go-mod-upgrade is a good tool btw

Nice! Added to my toolbox.


Fix an error for Style/InvertibleUnlessCondition when using empty parenthesis as condition

As it happens when you type something like return unless (foo = bar)

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[ ] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!


handle server error from emq_http_auth plugin

fix for #1037
please ignore version changes.
I know that this change is possibly not compatible with all auth plugins and the return code check should not be part of the core emq module. But this change helps us to improve handling of auth server outages

@terry-xiaoyu Do you have any plans to do such a change in a future release?
I'm not very familiar with erlang so from my perspective an erlang-developer can do this a lot faster and with better quality.


Command-line switches don't override .lfsconfig file

Currently I have a LFS-enabled repo with the following .lfsconfig file:
[lfs]
	fetchexclude = spec/fixtures/vcr_cassettes/**/*.yml

The expected behavior is that when anyone clones the repo, by default none of the big LFS-enabled .yml files are downloaded.  I cloned the repo and this worked as expected.
Then I ran git lfs pull -I spec/fixtures/vcr_cassettes/gbcoffice, expecting the command line options to override the config file and actually download the files I requested, but it did not.
Also tried git lfs pull -I spec/fixtures/vcr_cassettes/gbcoffice -X "", same behavior.
If I move/remove the config file, the commands work as expected, but moving/removing the file should not be needed when I'm being explicit about my intentions via command-line switches.
If you need any other information, feel free to ask.

I came here to report this same issue because I want to use LFS the same way. Glad to see that @dipnlik reported it already.
Are there any other workarounds besides temporarily changing .lfsconfig?

Hi, thanks for opening this. @dipnlik is spec/fixtures/vcr_cassettes/gbcoffice a directory, or a file?

spec/fixtures/vcr_cassettes/gbcoffice is a directory.  It has 3 files: categories.yml, subcategories.yml and offers.yml.
# .gitattributes
spec/fixtures/vcr_cassettes/**/*.yml filter=lfs diff=lfs merge=lfs -text

# git lfs env
git-lfs/1.2.0 (GitHub; darwin amd64; go 1.6.1)
git version 2.7.4 (Apple Git-66)

Endpoint=https://github.com/mercadoeletronico/agents-lfs.git/info/lfs (auth=none)
  SSH=git@github.com:mercadoeletronico/agents-lfs.git
LocalWorkingDir=/Users/dip/Dropbox/Developer/mercadoeletronico/agents-lfs
LocalGitDir=/Users/dip/Dropbox/Developer/mercadoeletronico/agents-lfs/.git
LocalGitStorageDir=/Users/dip/Dropbox/Developer/mercadoeletronico/agents-lfs/.git
LocalMediaDir=/Users/dip/Dropbox/Developer/mercadoeletronico/agents-lfs/.git/lfs/objects
LocalReferenceDir=
TempDir=/Users/dip/Dropbox/Developer/mercadoeletronico/agents-lfs/.git/lfs/tmp
ConcurrentTransfers=3
BatchTransfer=true
GIT_PS1_SHOWDIRTYSTATE=1
GIT_PS1_SHOWSTASHSTATE=1
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"

If you need anything else, just ask.  Thanks in advance for looking at this issue.

Aha! I added support for directory-based include/exclude filters in v1.2.1. Could you install the latest version of LFS and try again?

@ttaylorr updated my LFS installation via Homebrew to git-lfs/1.3.0 (GitHub; darwin amd64; go 1.6.3), and the issue still occurs.

Ah. @technoweenie provided a very helpful explanation to me of what's going on here, which I'm going to share here.
The exclude filter that is specified in your .lfsconfig file is being negated by the -I flag, which should allow LFS to include it in fetches/clones/pulls. However, it is still comparing against the exclude filter found in .lfsconfig because even when -X isn't given (or is given as -X ""), LFS sees an empty string internally, and signals itself to fallback to the ones found in the config (see here).
After it fallsback, both the include and the exclude filters are set to the same path, and are thus ignored by the filter checking mechanism, thereby excluding your files.
The most reasonable fix I think would be to check if *string == nil instead of len(string) == 0, but some sort of special token like "<ignore>" would work as well. 😄
Kudos to @technoweenie! ⚡


Blank windows after clicking 'Users' settings

Describe the bug
After clicking on the Users settings, all chat/settings become blank until we refresh the page while in another chat/setting other than Users
To Reproduce
Steps to reproduce the behavior:

Go to Users setting
Click on any other setting/chat
All windows are blank

Expected behavior
All windows should display their content.
Screenshots
Screencast showing the issue:
Users-bug.webm
Environment:

OS: Ubuntu 22.04
Browser: Google Chrome
Version: 107.0.5304.87 (Official Build) (64-bit)

I noticed that as well on my phone after the release. I also see it on the desktop now in production. Should be easy to fix, but I have some other things I have to take care of first unfortunately 😞

I found some time after all 😄 Fixed in v7.09
3c8e68e491d127c001035c7d73b4652acc50daf0


WooCommerceAPI is returning wrong endpoint information

I am using nodejs SDK v1.0.2. When I try to read the endpoint index, I just get a 1 result:
_wooHelper.get('', function(error, data, res){
console.log(res);
done();
});

console.log(res) outputs 1. Inspecting the data variable, it looks like the client is connecting to /wc-api/v3. Connecting to this url via curl also returns 1. Connecting via curl to /wc-api/v2 does return the expected index information.
I wanted to submit an issue as I am not sure if the result 1 when connecting to v3 is by design, and I am not sure how to tell the nodejs sdk woocommerce api client to instead connect to v2 and get the correct endpoint information.

Here is not a support channel and It's clear that you did not read any docs before trying test!


target has no isNative function

error: no field or member function named 'isNative' in 'Build.ResolvedTarget'
it's now target.query.isNative() if I see that right in the latest 0.12 dev build

This problem is known and the api adaptation has been completed, but there is a bug in the nightly version of the official website that prevents it from being built correctly.

now branch zig_build_api_change is available, but you need to build zig manually.
more details, see this issue: https://github.com/ziglang/zig/pull/18445

Now everything should be able to build, except for the dynamic linker on the windows platform, which is a bug in zig itself.