Restore Previous Styling

In previous Character Monitor versions, the height of the entry in chat was relative to the size of the test. Now it is 3-4x the size of the text and feels obtrusive. Please restore the previous size or add a setting to return this to previous state.

Hard seconded. I'd suggest adding a style switch, something along the lines of "Make tracking chat messages compact".
In a similar vein, perhaps a toggle-able mechanism to compact subsequent messages for the same actor/token into a single change log could be added. This would be particularly great for saving space when spell preparation macros are used etc.
Additionally, for joined messages something like the details tag or any similar structure could be used, where the message lists change categories and expandable structure contains timestamped change messages in order. This should probably be a separate issue, however.

@Sayshal as a quick and dirty workaround, if you feel like editing module contents, you could edit the stylesheet at:
Data/modules/dnd5e-character-monitor/styles/dnd5e-character-monitor.css
Making the following changes:
Line 20, replace:
    margin: 2px;
With:
    margin: 0px;
Line 21, replace:
    padding: 2px;
With:
    padding: 0px;
Note that this modification can be performed with FVTT running, all you need to do is refresh the page after saving (F5 in most browsers). All existing and future entries will change in accordance to the new values.
Keep in mind, you'll have to redo it by hand after every module update/re-installation.

Before and after comparison

The same set of messages captured in two states: prior to changes (left) and afterwards (right)

Yeah I set mine to this, I'm too stupid to get this to work on Custom CSS module so it's update-proof, but here's my code:
div div.dnd5e-cm {
    text-shadow: -1px -1px 0 #000, 1px -1px 0 #000, -1px 1px 0 #000, 1px 1px 0 #000;
    color: white;
    font-size: 12px;
    margin: -7px;
    padding: -7px;
    text-align: center;
}

I totally agree, I liked the old design better as well.

I didn't really change the style of the text. It's always been based off the dnd5e system CSS. But I do agree the new style of the messages isn't great. I reduced the font size and padding on monitor messages. New update soon.


The problem about phoneme （SSML）don't work in zh_TW

In my case, I want to produce audio but there are too much same word  have different pronounce.  I'm trying to use phoneme to specify the pronunciation in zh-TW.
But use <phoneme alphabet="sapi" ph="he 1"> 喝 </phoneme>, it will print out error.
Does it support Mandarin?

@yulin-li could you please comment on this issue?

@iajzhan could you help on this?

@Lucien20000118 Zh-TW does not support pinyin, should use 'Bopomofo' phones, pls refer to this page: https://docs.microsoft.com/en-us/azure/cognitive-services/speech-service/speech-ssml-phonetic-sets#zh-tw


Update networking-partners-msp.md

Hi, requested a change though not been implemented. Customers are still routed to the wrong page

@Prasheen24 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@Jak-MS : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@skishen525
Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

Hi,
Still not updated.
From: Sunil Kishen @.>
Sent: Thursday, July 14, 2022 1:23 AM
To: MicrosoftDocs/azure-docs @.>
Cc: Prasheen Dehda (Liquid C2) @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] Update networking-partners-msp.md (PR #95387)
#sign-off
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/pull/95387#issuecomment-1183776323, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARSXOOLHSHGZIEGMBPZIGFDVT5FV3ANCNFSM5222BUXQ.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>This email disclaimer applies to the original email, all attachments and any subsequent emails sent by Liquid Telecom. This email contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure, intended only for the named person or entity to which it is addressed. If you are not the intended recipient of this email and you received this e-mail in error, any review, use, dissemination, distribution, printing or copying of this e-mail is strictly prohibited and may be unlawful and/or an infringement of copyright. Please notify us immediately of the error and permanently delete the email from your system, retaining no copies in any media. No employee or agent is authorized to conclude any binding agreement on behalf of Liquid Telecom with another party or give any warranty by email without the express written confirmation by an authorized representative or a director of Liquid Telecom. Nothing in this email shall be construed as a legally binding agreement or warranty or an offer to contract. Liquid Telecom will not be responsible for any damages suffered by the recipient as a result of the recipient not taking cognizance of this principle. Liquid Telecom accepts no liability of whatever nature for any loss, liability, damage or expense resulting directly or indirectly from the access of any files which are attached to this message. Any email addressed to Liquid Telecom shall only be deemed to have been received once receipt is confirmed by Liquid Telecom orally or in writing. An automated acknowledgment of receipt will not suffice as proof of receipt by the Liquid Telecom. This email disclaimer shall be governed by the laws of South Africa.

Invalid command: '#sign-off'. Only the assigned author of one or more file in this PR can sign off. @skishen525

updated this in another PR


update proxy of release-6.5 to raftstore-proxy-6.5 by proxy pr 283

What problem does this PR solve?
Issue Number: ref #4982 close #6851
Problem Summary:
support openssl bugfix: stage 1
update proxy to raftstore-proxy-6.5
Proxy PR:
https://github.com/pingcap/tidb-engine-ext/pull/283
Including:\nSubmodule contrib/tiflash-proxy 874c0a3b63..aff4270ced:

Merge pull request #283

What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/rebuild

/run-all-tests

/run-unit-test

/run-unit-test

/run-unit-test

/merge


TNO-1976: Add more filters to advanced search and revamp

added multiple new filter abilities to advanced search
styling changes
code changes
and more

@Fosol -  ready for review!


Adding a Convox Syslog resource resource

Desired Terraform Convox provider syntax:
provider "convox" {
  host     = "foo.bar.com"
  password = "xxx"
}

resource "convox_syslog" "papertrail" {
   name     = "test-app.syslog"
    rack     = "rack/name-here"
    private  = true
    hostname = "logs10000.papertrailapp.com"
    port     = "30303"
    scheme   = "tcp+tls"
}

resource "convox_app" "test_app" {
  name = "test-app"
  rack = "rack/name-here"

  params {
    Internal = false
  }

  environment {
    Foo    = "bar"
    FooBar = 10
  }
}

resource "convox_resource_link" "test_app_papertrail" {
     rack          = "rack/name-here"
     app_name      = "${convox_app.test_app.name}"
     resource_name = "${convox_syslog.papertrail.name}"
 }

@mattaitchison any thoughts on this? New feature to manage logging and I've finally got some testing infrastructure in there. CI is next I guess.


React functional component types that match TS types

Proposal
It would be great if we can have React functional component types that match with React.FC on TS (which includes children in the props).
Use case
We tried the generate Flow typedef for a TS React component, we basically rename React.FC to React$StatelessFunctionalComponent, which make Flow complain because on TS side, the component was having children as a prop (which conforms the React.FC) but the React$StatelessFunctionalComponent doesn't have that.

Pretty sure this is a design decision that TS made that Flow decided not to take. For one, a component doesn't necessarily have to accept children, consider a component that decided to look like this
const Comp = ({ text }: { text: string }) => (

{text}

);

Or if it does accept children, it doesn't have to be React.Node, it could be a render function
const Comp = ({ children }: { children: () => React.Node }) => (

{children()}

);

Basically being explicit about these things is generally better. For me, having to define children as explicitly React.Node at least makes me consider if this could be simplified to just string | number?
On top of this, Flow doesn't require you to define the type of the component (unless you're exporting it), it can very easily infer, which would cause strange behaviour in some components having a children prop predefined, and others not.
And honestly I've never even used React$StatelessFunctionalComponent. Most of my components look like this, or something similar.
const Comp = (): React.Node => {
// ...


Check resource manager before passing schema URI through resolver

This PR is a minor adjustment to #819.  I had intended to use schemas from the new API before resorting to the old API, but my original implementation passed the schema URI through the old resolver first, which may be converting it to a filesystem URL that the new code can't recognize.  This change is simply to check the schemas from the new API first, and only pass the URI through the resolver if necessary.

This looks good.  Is codecov no longer set up on this repo?

Closing and re-opening this to see if codecov is fixed


in a build npm

Hello,
I use your project in my own mpp kotlin lib
I plan to use my lib and your in another app build by npm. (package.json)
Any Idea how I can publish my lib on npm or what i should add to my package.json to use my lib?
Thank-you !

Hi,
These two resources might be helpful:
https://www.reddit.com/r/Kotlin/comments/a3mngm/publish_kotlinjs_package_in_npm/
<EMAIL_ADDRESS>

@oshai hello, so, i've do a few research...
It would help a lot to use your lib in js if either you publish your lib on npm or if you publish the js build on github with a package.json:
https://stackoverflow.com/questions/17509669/how-to-install-an-npm-package-from-github-directly

do you have any link on how to do it from gradle?


[Feature] Rewrite Vanilla Interactions

Describe the problem
There's a ton of vanilla interactions to rewrite and objects to patch.
This issue will track the current progress.
Describe the solution
✅(?)Agent, ✅AirConditioner, ✅AlarmButton, ✅Altar, ✅AmmoDispenser, ✅ArcadeGame, ✅ATMMachine, ✅AugmentationBooth, ✅Barbecue, ✅BarbedWire, ✅Bars, ✅BarStool, ✅Bathtub, ✅Bed, ✅Boulder, ✅BoulderSmall, ✅Bush, ✅CapsuleMachine, ✅Chair, ✅ChestBasic, ✅CloneMachine, ✅Computer, ✅Counter, ✅Crate, ✅Desk, ✅Door, ✅Elevator, ✅ExplodingBarrel, ✅FireHydrant, ✅Fireplace, ✅FireSpewer, ✅FlameGrate, ✅FlamingBarrel, ✅GasVent, ✅Generator, ✅Generator2, ✅Gravestone, ✅(?)Item, ✅Jukebox, ✅KillerPlant, ✅Lamp, ✅LaserEmitter, ✅LoadoutMachine, ✅LockdownWall, ✅Manhole, ✅MineCart, ✅MovieScreen, ✅PawnShopMachine, ✅Plant, ✅Podium, ✅PoliceBox, ✅PoolTable, ✅PowerBox, ✅Refrigerator, ✅Safe, ✅SatelliteDish, ✅SawBlade, ✅SecurityCam, ✅Shelf, ✅Sign, ✅SlimeBarrel, ✅SlimePuddle, ✅SlotMachine, ✅Speaker, ✅Stove, ✅SwitchBasic, ✅Table, ✅TableBig, ✅Television, ✅Toilet, ✅Train, ✅TrapDoor, ✅TrashCan, ✅Tree, ✅Tube, ✅Turntables, ✅Turret, ✅VendorCart, ✅WasteBasket, ✅WaterPump, ✅Well, ✅Window.
Legend:
❌ - not implemented, 🔹 - not tested, 🔸 - testing failed, ✅ - implemented, (?) - may be tricky to implement.
Describe the alternatives
No response

Oh my god, I have done it.


swap out idbwrapper with straight indexeddb code

idbwrapper has outlived its usefulness to us, and has performance issues
fastest throughput I can get with idbwrapper is 60KB/s. Without it I can get 1MB/s (using substacks idb-blob-store module which uses the IDB API directly)

idb-blob-store chunks messages, so you can probably get even faster with raw idb

I agree, and not just for speed. That would solve the issue on the null
values as well.
Il giorno dom 6 dic 2015 alle 16:32 James Halliday<EMAIL_ADDRESS>ha scritto:

idb-blob-store chunks messages, so you can probably get even faster with
raw idb
—
Reply to this email directly or view it on GitHub
https://github.com/maxogden/level.js/issues/46#issuecomment-162380260.

Guys,
I've been working on replacing idb-wrapper with native indexedDB. I do have a working implementation ready[1]. But before I open up a PR I'd like to discuss the approach I've taken which is to store JS types natively and only coerce in _get() or _iterator() if asBuffer is true. Otherwise, if asBuffer is false, always return the native type. Previously this behavior was available via options.raw.
This required only one patch in the tests of abstract-leveldown (which I will submit if you guys think this is the right approach).
Additional changes worth mentioning (see commits in [1]):

remove unused dependencies and bump the ones that will stay with us

open:

support multiple stores in the same database
implement createIfMissing and errorIfExists

destroy:

delete the given object store, and if no other object stores exist
in the database, delete the database as well.

batch:

save keys and values using native JS types, no coercion / encoding
support sync on batch level, not operation level and only
supported in Firefox with "dom.indexedDB.experimental" pref set to
true

iterator:

If keyAsBuffer or valueAsBuffer, try to coerce most types into a
String. Drop redundant support for the raw option. Just pass
keyAsBuffer = false and/or valueAsBuffer = false.

put:

save keys and values using native JS types, no coercion / encoding
with experimental support for sync (Firefox only)

get:

If asBuffer, try to coerce most types into a String. Drop redundant
support for the raw option. Just pass asBuffer = false.

del:

with experimental support for sync (Firefox only)

[1] living in https://github.com/timkuijsten/level.js/tree/idbunwrapper (which is based on https://github.com/timkuijsten/level.js/tree/abstract-level2 (which in turn is based on https://github.com/timkuijsten/level.js/tree/iterator-refactor a.k.a. PR #51)).

According to observations noted in https://github.com/maxogden/level.js/pull/51#issuecomment-182506309 (aggressive IndexedDB cursor timeouts) I've reworked the iterator to reopen a cursor if the stream is not ended and the end of the cursor was not reached.

Just realized that automatically reopening a new cursor on a transaction timeout breaks the default snapshot property of leveldb and indexeddb. I've added the reopenOnTimeout option which defaults to false so that the default behavior mimics that of LevelDB (at the cost of getting a TransactionInactiveError if you're calling next not fast enough).

at the cost of getting a TransactionInactiveError if you're calling next not fast enough

It would be better to cache cursor results, so that it doesn't matter when next() is called, it can simply take a kv pair from the cache. This will make the behavior similar to leveldown and others, and not break streams (built on iterators) for example. I've got a sample implementation here.

I've added the reopenOnTimeout option

How about naming it snapshot, which defaults to true. If false, it keeps reading until the cache reaches a certain size (a highWaterMark like in streams). One can keep nexting until the cache is empty, after which a new cursor is created, and the cache refilled.

It would be better to cache cursor results, so that it doesn't matter when next() is called, it can simply take a kv pair from the cache. This will make the behavior similar to leveldown and others, and not break streams (built on iterators) for example.

and

How about naming it snapshot, which defaults to true.

I like the idea in general, but I'm not sure what cache.push and shift for every item do to performance/GC. Furthermore, if a large database is iterated with a slow stream consumer then big memory spikes might occur.

... If false, it keeps reading until the cache reaches a certain size (a highWaterMark like in streams). One can keep nexting until the cache is empty, after which a new cursor is created, and the cache refilled.

Sounds good. Would be nice to have some feedback from one of the maintainers.

if a large database is iterated with a slow stream consumer then big memory spikes might occur.

No way around that, sadly. One can get proper snapshotting or proper backpressure, but not both. All level.js can do is offer a choice.

Just wanted to chime in to say apologies I haven't been able to dive in to provide feedback on this yet, I think the work here is really awesome so far.
One question I have re: snapshots on top of IDB in general (not something I've thought about much until this point): Does creating a new cursor mean creating a snapshot based at a later point in time? Or can you create a cursor pointing at some old state to at least get the same read state out of the db as the previous one.
Re: the caching proposal, I do think we should find a way to paper over the TransactionInactiveError issue so that users of e.g. leveldown backed by level.js won't have to know/worry about it. I think in general a default mode should try to prioritize compatibility with modules that will be running in node on leveldown, so we should try to make snapshot semantics match as much as possible. If people want to tune performance in the browser it should be an opt-in.

Does creating a new cursor mean creating a snapshot based at a later point in time?

Yes. The implementation might not use snapshots, but effectively, for the purposes of this discussion, yes. It means creating a new readonly transaction, which guarantees:

As long as a "readonly" transaction is running, the data that the implementation returns [..] must remain constant. There are a number of ways that an implementation ensures this. The implementation can prevent any "readwrite" transaction [..] until the "readonly" transaction finishes. Or the implementation can allow the "readonly" transaction to see a snapshot of the contents of the object stores which is taken when the "readonly" transaction started.

I've just pushed a fairly big update of the iterator.
I've replaced the reopenOnTimeout option with a snapshot option, that defaults to true as suggested by @vweevers. It either reads a snapshot without timeouts (at the cost of memory spikes) or, if you pass snapshot = false, it uses back pressure using default stream semantics and highWaterMarks (at the cost of not iterating over a snapshot of the database).
I've split out the indexeddb cursor iterator into a separate module so that it can be used as a nodejs stream. It hopefully makes the iterator in level.js a bit easier to read and understand.
p.s. I've also tried to upgrade to abstract-leveldown 2.6.0, but this introduces some problems with serializing object values and I was not able to get the new _serializeValue feature to work. Maybe someone can give that a look? I'm a bit diffuse on how asBuffer, valueEncoding, _serializeValue etc. should all work together. For now my earlier suggested patch should be used to get all tests working.

Regarding encoding and serialization:

level.js doesn't need to concern itself with encoding, only serialization.
The flow of writes is: user value -> encode -> serialize -> IDB. The serialization is meant to convert encoded values (usually strings or Buffers) to whatever type the underlying store (IDB) can handle. Because IDB can store values of any type, _serializeValue() should just return values as-is. With maybe a special handling of null, depending on which patch lands in abstract-leveldown. There's no need to do anything with Buffers, because the browser will store those as Uint8Arrays (Buffer being a subclass of Uint8Array).
The flow of reads is: IDB -> deserialize -> decode -> user value. The way I see it, deserialization is an implicit step in abstract-leveldown, where asBuffer comes into play. If the encoding expects a Buffer, or if the user specified { asBuffer: true } in the get() or iterator options, then abstract-leveldown will pass { asBuffer: true } to level.js. In this case, level.js should convert typed arrays back to Buffers. Use typedarray-to-buffer for optimal performance.
Keys can be of type Array, String, Date or Number (except NaN). IndexedDB Second Edition also supports binary keys (ArrayBuffers or views thereof), though browser support isn't there yet. See here for an example of _serializeKey that handles all this.
Unlike other *down adapters, the id encoding is very powerful with level.js, because one can store anything. We should however warn (in the readme) that with the id encoding, level.js returns the value as stored by IDB. asBuffer is false in this case. If Buffers went in, Uint8Arrays come out.

@timkuijsten seeing as I already implemented the above in a private fork, I can publish that if you want, but I can't make promises as to when.
One other note, with regards to removing IDBWrapper. I'm using level.js in production, and at one point it had to store 1.5 million entries. A bottleneck in IDBWrapper, depending on batch size, is that its batch function creates all the put and delete requests at once. I bypassed IDBWrapper and wrote a batch function that waits for a request to complete before making the next, resulting in a huge CPU drop:
function next() {
  if (index === ops.length) return

  var op = ops[index++]
    , req = op.type === 'del' ? store.delete(op.key) : store.put(op.value, op.key)

  req.onsuccess = next
  req.onerror = onRequestError
}


convert layer to kirkstone

Convert recipes to the new override syntax using
find meta-ofdpa | grep -e '.bb$' -e '.inc$' -e '.conf$' -e '.bbappend$' | xargs -n 1 ./scripts/contrib/convert-overrides.py
for the basic overrides (append, prepend, remove, ${ARCH}), and manually
replace the machine overrides by hand.
Finally set the layer compatibility to kirkstone.
Signed-off-by: Jonas Gorski<EMAIL_ADDRESS>

I would have liked for the commit message to contain a link to convert-overrides.py [1] (or at least a hint that it is from the poky repo) and a link explaining the syntax change [2].
Same goes, of course, for the conversion commits in the other repos.
[1] https://git.yoctoproject.org/poky/tree/scripts/contrib/convert-overrides.py?h=kirkstone [2] https://docs.yoctoproject.org/migration-guides/migration-3.4.html#override-syntax-changes

Done (also for the other repos).


Fix the Windows package

As I've done for libXau and libX11.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Fix ReDoS with autolink

Patterns like <<<<<<<<<<:/:/:/:/:/:/:/:/:/:/ currently exhibit O(n^3) complexity, allowing a 5KB document to take 7174ms to parse. With this change, it drops to O(n^2) and 73ms.
Tested with
<script src="simple-markdown.min.js"></script>
<script>
var str = "<".repeat(2000)+":/".repeat(1500);
var t1 = performance.now();
SimpleMarkdown.defaultInlineParse(str);
var t2 = performance.now();
document.write(str.length+" bytes, "+(t2-t1)+"ms");
</script>

This PR will change parsing of weird things like <foo:bar:/baz>. If you'd prefer leaving behavior 100% unchanged, the regex can instead be changed to /^<(?=[^ >]+:\/)([^ >]+)>/, with no meaningful performance difference.
What is the project policy for what counts as a DoS? Quadratic complexity is fine, anything higher is a bug? More than 1ms per byte on a 10KB document is a bug? Anything superlinear is a bug? If the latter, I can name a few other inputs with quadratic runtime.

This looks great; thanks for contributing it! I think the parsing change is fine.
Yeah, I think anything superlinear is probably a problem. If you have examples I'd be happy to look into and fix them, or happy to accept your fixes! (I haven't done a lot of measuring times per document size, but I expect if we had everything linear most of those would be fine too.)

Actually, I might have missed something: what's still quadratic about the fixed version here? The whole parse, or the individual autolink match?
I think the whole parse in general will be quadratic as it may re-run any regex for each character in the worst case (like your example), but the matchers themselves should ideally all be linear.

I'm referring to it being quadratic (formerly cubic) in the entire parse. All other superlinears I'm aware of mean quadratic documents as well, per my definition. I apologize for the confusion, I should've been clearer.
I wrote this analysis of the quadratic documents before you submitted your second post, so I'll post it even though it's not necessarily interesting.
<<<<<<<<<<<<<<<<<<<< - autolink tries to start at every one, fails because no :/ (and no >). Could be fixed by rejecting < in autolinks, but unless the other quadratic documents are fixed, fixing this doesn't really solve anything.
******************** - the outermost pair of asterisks become italics, which is parsed recursively. The inner parser also sees a long string of asterisks, and turns the outermost into italics; repeat until there's only one or two asterisks left. Can be fixed by rejecting recursive italics, but that'd be more effort than it's worth. And the strong rule would most likely require something similar.
____________________ - same as the above. Still italics, even.
\``\``\``\``\``\``\``\``\``\`` - the first backtick is a perfectly normal escape. Second one tries to find a sequence of exactly 1 backtick so it can close, but all subsequent ones are doubles, so it scans to the end of the string and fails, emitting a single plaintext backtick. Next up is a backslash, which eats the third backtick, and the fourth one scans to the end again. I cannot think of any way to fix this without altering parsing of realistic documents.
There are most likely other ways to cause quadratic (or worse) document parsing; I didn't check all parsing rules. Some of them exceed my brain capacity.

Thanks & sorry for the late reply! That was a thoughtful and helpful explanation!
I think you're right in that right now the quadratic document cases would be pretty challenging to address without a major re-thinking of how this works. I believe most parsing algorithms are quadratic in the worst case, so while we could probably do better for markdown specifically, that might be generally okay.

There are most likely other ways to cause quadratic (or worse) document parsing; I didn't check all parsing rules. Some of them exceed my brain capacity.

I've generally tried to check these visually as well, but as in this example, I don't always see them. If you run into any more, I'd love to hear about them so we can fix them :).
Thanks again for your comments and PR here and for making this project better for everyone!


Automation of Ubuntu Package Architecture & Version

Modified buildubuntu.sh to automatically get architecture from JAVA_ARCH environment variable, make modifications to server & client control files to set architecture, and set output filenames to the correct architecture. Also automatically inserts correct version number into package control files.

Looks like someone beat you to the punch on this one...I just merged another change from a couple days ago that's doing essentially the same thing. Go ahead and rebase and see if there's anything else left from your change that's useful. Thanks!

I saw that after I made my pull request. I like what he did better. :-)


Add a test that applies a predicate to response body in HttpServiceSpec

@DanSimon @benblack86 @jlbelmonte @aliyakamercan @amotamed
Want to try out this whole process

Codecov Report

Merging #524 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #524      +/-   ##
==========================================
- Coverage   84.74%   84.72%   -0.03%
==========================================
  Files          98       98
  Lines        4294     4294
  Branches      338      338
==========================================
- Hits         3639     3638       -1
- Misses        655      656       +1

Impacted Files
Coverage Δ

.../scala/colossus/metrics/collectors/Histogram.scala
91.91% <0%> (-0.74%)
:arrow_down:

Continue to review full report at Codecov.

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

👍


Refs #7800. Added support for service_instance_name.

Build status:

Linux

Build status:

Linux

Build status:

Linux


Incorrect version specified in apply patch

Current and expected behavior
I have a function that is supposed to patch a resource:
    // helper to send a merge patch
    pub async fn patch(&self, data: &serde_json::Value) -> Result<()> {
        let mut pp = PatchParams::default();
        pp.field_manager = Some(String::from("application/apply-patch"));
        // Run this patch with a smaller deserialization surface via kube::Resource
        // kube::Api would force ShipcatManifest fully valid here
        // and this would prevent status updates during schema changes.
        println!("patch");
        println!("DATA: {:?}", data);
        let req = self
            .mfs
            .patch_subresource("status", &self.name, &pp, &Patch::Apply(data))
            .map_err(ErrorKind::KubeApi)?;
        let o = self
            .client
            .request::<MinimalMfCrd>(req) // <- difference from using Api::patch_status
            .await
            .map_err(ErrorKind::KubeError)?;
        debug!("Patched status: {:?}", o.status);
        Ok(())
    }

But whenever this function is called, I'm getting this error:
shipcat: apply error: kube api: ApiError: Incorrect version specified in apply patch. Specified patch version: , expected: babylontech.co.uk/v1: BadRequest (ErrorResponse { status: "Failure", message: "Incorrect version specified in apply patch. Specified patch version: , expected: babylontech.co.uk/v1", reason: "BadRequest", code: 400 }): Api(ErrorResponse { status: "Failure", message: "Incorrect version specified in apply patch. Specified patch version: , expected: babylontech.co.uk/v1", reason: "BadRequest", code: 400 })

It looks like my patch doesn't provide a version? To be honest I'm really confused about what's happening here.
Possible solution
No response
Additional context
The content of data:
DATA: Object {"status": Object {"conditions": Object {"generated": Object {"status": Bool(true), "reason": Null, "message": Null, "lastTransitionTime": String("2022-11-18T14:03:38Z"), "source": Object {"name": String("jean-patrickfrancoia"), "url": Null}}}, "summary": Object {"lastSuccessfulGenerate": String("2022-11-18T14:03:38Z"), "lastAction": String("Generate")}}}

Environment
Client Version: v1.21.14
Server Version: v1.21.14-eks-fb459a0

Configuration and features
kube = { version = "0.76.0", features=["rustls-tls"], default-features = false }
k8s-openapi = { version = "0.16.0", features = ["v1_21"]}

Affected crates
No response
Would you like to work on fixing this bug?
No response

Looks like your MinimalMfCrd or mfs do not correctly include the apiVersion (you are serializing the empty string for that field, which is not allowed).

I think it's MinimalMfCrd but I'm not sure. The let req = self... line executes properly, it's really the last command that fails.
#[derive(Clone, Serialize, Deserialize)]
pub struct MinimalManifest {
    pub name: String,
    pub version: String,
}
type MinimalMfCrd = Object<MinimalManifest, ManifestStatus>;

...

/// Status object for shipcatmanifests crd
///
/// All fields optional, but we try to ensure all fields exist.
#[derive(Deserialize, Serialize, Clone, Debug, Default, JsonSchema)]
#[serde(rename_all = "camelCase")]
pub struct ManifestStatus {
    /// Detailed individual conditions, emitted as they happen during apply
    #[serde(default)]
    pub conditions: Conditions,
    /// A more easily readable summary of why the conditions are what they are
    #[serde(default)]
    pub summary: Option<ConditionSummary>,
}

Where does apiVersion come from?

MinimalMfCrd is an Object which contains types (TypeMeta) which contains the api_version.


adding defaultEvent which does not preventDefault.

adding drag and drop events to default attributes.
event now inherits from defaultEvent and preventsDefault.

see https://github.com/mojo-js/paperclip.js/issues/268#issuecomment-116363551


Fix for user menu

This should fix the drop down menu on user page from where you can log out.

Also anychanges that are made upstream might be lost if we update bootstrap once. We should considering building the theme file our self

I would suggest merging this now because people keep reporting the issue and it would solve it for now.
If future themes are going to be built using tailwind in place of bootstrap then it is not a long term issue, but in a mid-term we can buid a more cross-theme solution if needed, it would just be good to get a fix out there.  @jaapmarcus thoughts?

We need to update all the theme files and only one. And add at the bottom:
/* Fix for menu */
.nav-item:hover .dropdown-menu {display: block;}
For example if we ever need to update the theme files at least git can merge it


docs(Confirm): refactor and use index.js

Looks like this PR snuck in when docs were down, code looks good so merging.  There is an issue with the Confirm examples themselves (using old Modal API), but I'll update that on another PR.


Badges broken in 1.2.6?

Bug Report
Please fill out this information:

Browser version: FF 64.0
Extension version: 1.2.6
Operating system: Win10 LTSB 2016

What is happening?
Badges no longer appear on the Standard Notes icon when a URL/domain has associated notes.

What are the steps to reproduce the bug?
Unclear. I tried the various different badge display types and all showed nothing.
Are you seeing it on your end? If not I can examine my setup more closely. My userchrome.css is pretty customized but deleting it did not bring badges back.

Yes im having the same problem in Firefox latest on Ubuntu!
This is definitely a bug from latest update, as it worked before. Please fix!

@oositP @seascape
Ok, this is actually a pretty easy fix, I'll publish an update ASAP. Essentially, I changed around some things in the site parser, but I forgot to reflect those changes in the badge code.
Specifically, setup.js line 110
Currently it is let site = siteParser(tab.url, res.options.default_display, res);
And it should be let site = siteParser(tab.url, res);

Confirmed fixed. Thank you!


Cassie sim analysis

tidied up scripts

You've got a ton of conflicts here, I'm guessing mostly with files that you've never changed, due to a mistake somewhere in the merge process.

Just took a quick look to try to sort out the conflicts, and the code isn't really clean enough for me to do so. The fact that GitHub here is saying there are 496 files changed is a sign that things haven't gone smoothly!
Some initial steps required:

Merge back to master, and resolve files with conflicts. Mostly, this means taking whatever's in master.
Remove duplicate files (I see many instances here of the same files)
Remove the data files. These should never be checked into the repository.


Makes the gem fully workable to deploy with actual structure of FIAS database

Correlates tables and DBF-files from the FIAS database archive
Helps to set uuid-type to the right columns in the database
Prevents to import from empty DBF-file

Please fix the project so that it can be successfully tested in Travis CI.
And please accept my pull request otherwise gem can not work at all.


[docs] Migrating from v4 to v5 - Missing details in documentation

Related page
https://mui.com/material-ui/migration/migration-v4/#update-typescript
Kind of issue
Unclear explanations
Issue description
quoting:
"If your project includes these packages, you'll need to update them:
react-scripts
@types/react
@types/react-dom"
what does this mean update them?
update to which versions?
I have an old CRA application,
React app (v17),
styled-components (v6),
and wishes to upgrade MUI v4 to v5. This will enable us also to upgrade React to v18.
I'm having tons of compile issues on the flow, not sure what is the reason for that.
have tried to go over the documentation - but it keeps happening,
and first step where I feel vague is the one quoted above.
I have upgraded @types to v17, due to React version
and react-scripts to v4, although there's v5 as well.
not sure what should be done here - will be glad for clarification in this regard.
Also for styled-components support, you said it's a must to add 'paths' to tsconfig - and when tried to do so, and afterwards run 'npm start', 'paths' was deleted automatically from the file.
Will appreciate any help to make a progress.
Context
No response
Search keywords: react-scripts

Agree, it's vague. We should be clearer. Can you provide more details on the issues you're facing when upgrading to the latest version of React types and react-scripts?


Ensure that .csv files are actually CSV files

GitHub has a web interface for viewing and editing of data files, including CSV. For details, see https://docs.github.com/en/repositories/working-with-files/using-files/working-with-non-code-files#rendering-csv-and-tsv-data. Here's s screenshot of the GH i/f from the GH docs:

It would be nice if the CLOmonitor data files, like those under https://github.com/cncf/clomonitor/tree/main/database/data/cncf, were actually formatted per the file suffix. Would that be possible?
I haven't actually tried the GH interface for editing tables, but it does seem more convenient than editing the raw text. Just a thought. Thanks!
/cc @nate-double-u @caniszczyk

Or maybe you have another suggestion for updating the data tables?

Hi @chalin
We use semicolons in those data files instead of commas as separator because there are some fields (like checks sets or descriptions) that use commas very often. Those could be quoted though, but it can be error prone (i.e. some are missed).
Most spreadsheet software (Excel, Numbers, etc) should allow you to edit those files nicely, like in the screenshot you attached. Although they are not CSV strictly speaking, it's very common to name them this way as well when using some alternative common separators, and software that allows editing CSV files usually works fine with them (not GitHub yet though ;).
Said this, if you still think this can be a problem, we can change them 🙂 When adding new projects, it'll often be needed to edit multiple files (to add the org, project and repo, for example), not just one, so it'll probably be easier to do that on your local computer than from the GitHub UI anyway.

Will close this one for now, please feel free to reopen if needed 🙂


1.0.0-beta3: History back/forward always render 3 times

Basic example:
import React from 'react';
import ReactDom from 'react-dom';
import Router from 'react-router';
import BrowserHistory from 'react-router/lib/BrowserHistory';
import routes from './routes';

ReactDom.render(<Router history={new BrowserHistory} children={routes}/>, document.getElementById('html'));

import React from 'react';
import {Link} from 'react-router';

class App extends React.Component { // MAIN ROUTE
  render() {
    console.log('location', this.props.location); // THIS
    return (

<Link to="/">Home</Link>

<Link to="/stats">Stats</Link>

<Link to="/login">Login</Link> | <Link to="/logout">Logout</Link>

<Link to="/projects">Projects</Link>

    );
  }
}

export default App;

When using browser back and forward buttons console.log('location', this.props.location); is always rendered 3 times but navigation with <Link> elements shows only one.

on master I see multiple renders depending on which route you're going to, but usually just one. With a static route config this seems unnecessary, but digging into the code might reveal otherwise. Mind creating a failing test?

this was caused by isTransitioning prop that got rendered down, we don't do that anymore, but we may again in the future, it shouldn't be anything to worry about, "always rerender".
If we bring it back, and there's evidence that "always rerender" is not okay for the router (meaning its noticeable in the UI), we can worry about it.

ok, cool


Integrating pywhispercpp as the first extension to lollms-webui

Hi Abdeladim. I finally start to write extensions to lollms and I was thinking that first extension should be audio in and audio out. But I need to comply with my rule number 1: Every thing should be done locally. No data is sent anywhere out of your PC.
To do this, I think whisper is really cool. Even cooler is whispercpp, but since I use python, i need pywhispercpp :)
Do you have an example of your code that uses direct input stream from microphone? That would simplify the integration greatly.

Hi Saifeddine,
That's great to hear. We'll finally see lollms with audio :)
Yes I have done an example that uses direct input stream from the mic, it is the assistant example.
I created it in this way because I had the idea to deploy it in a raspberry PI as an assistant.
The class Assistant is already ready to be imported and you only need to pass a callback to it. Otherwise you can tweak the source code to serve your needs. It's fairly simple.
Let me know if you need anything else.

Wonderful!


Specifies required pycryptodomex version, from implicit 3.15.0 to required 3.9.7 in requirements

Description of your pull request and other information

Upon running the compilation prereqs: python3 -m pip install -U pyinstaller -r requirements.txt, the file requirements.txt contains pycryptodomex without a specified version, which therefore leads to the downloading of  v3.15.0 instead of the required v3.9.7. This leads to an error, which is fixed by specifying the version explicitly in requirements.txt
python3 -m pip install -U pyinstaller -r requirements.txt
Requirement already satisfied: pycryptodomex in /usr/local/lib/python3.9/site-packages (from -r requirements.txt (line 2)) (3.9.7)
Collecting pycryptodomex
  Downloading pycryptodomex-3.15.0-cp35-abi3-macosx_10_9_x86_64.whl (1.6 MB)

Attempting uninstall: pycryptodomex
    Found existing installation: pycryptodomex 3.9.7
    Uninstalling pycryptodomex-3.9.7:
      Successfully uninstalled pycryptodomex-3.9.7

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
cryptosteganography 0.8.3 requires pycryptodomex==3.9.7, but you have pycryptodomex 3.15.0 which is incompatible.

When updating requirements.txt, replacing pycryptodomex with pycryptodomex==3.9.7, the correct version is pulled, the incorrect version is uninstalled and the compilation process finishes successfully.
python3 -m pip install -U pyinstaller -r requirements.txt
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Ignoring brotlicffi: markers 'platform_python_implementation != "CPython"' don't match your environment
Requirement already satisfied: pyinstaller in /usr/local/lib/python3.9/site-packages (5.3)
Requirement already satisfied: mutagen in /usr/local/lib/python3.9/site-packages (from -r requirements.txt (line 1)) (1.45.1)
Collecting pycryptodomex==3.9.7
  Using cached pycryptodomex-3.9.7-cp39-cp39-macosx_12_0_x86_64.whl
Requirement already satisfied: websockets in /usr/local/lib/python3.9/site-packages (from -r requirements.txt (line 3)) (10.3)
Requirement already satisfied: brotli in /usr/local/lib/python3.9/site-packages (from -r requirements.txt (line 4)) (1.0.9)
Requirement already satisfied: certifi in /usr/local/lib/python3.9/site-packages (from -r requirements.txt (line 6)) (2022.6.15)
Requirement already satisfied: altgraph in /usr/local/lib/python3.9/site-packages (from pyinstaller) (0.17.2)
Requirement already satisfied: pyinstaller-hooks-contrib>=2021.4 in /usr/local/lib/python3.9/site-packages (from pyinstaller) (2022.8)
Requirement already satisfied: setuptools in /usr/local/lib/python3.9/site-packages (from pyinstaller) (62.3.2)
Requirement already satisfied: macholib>=1.8 in /usr/local/lib/python3.9/site-packages (from pyinstaller) (1.16)
Installing collected packages: pycryptodomex
  Attempting uninstall: pycryptodomex
    Found existing installation: pycryptodomex 3.15.0
    Uninstalling pycryptodomex-3.15.0:
      Successfully uninstalled pycryptodomex-3.15.0
  DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Successfully installed pycryptodomex-3.9.7

Template
Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[x] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

What is the issue with 3.10.15? If there is something, we should adjust out code accordingly, not pin to outdated versions

cryptosteganography 0.8.3 requires pycryptodomex==3.9.7, but you have pycryptodomex 3.15.0 which is incompatible.

This is you using conflicting libraries - not our fault. You can ask cryptosteganography devs to unpin their dependency, or install yt-dlp with --no-deps


vp2420 release

Split vp24xx into vp2420 and vp2410. Then add new release information for vp2420.

Check this PR for all changes that affected the name change: https://github.com/Dasharo/docs/pull/394

@sulewskiprzemyslaw you can verify the test matrix like you've wanted. Essentially I've copied the matrix from vp2410 to vp2420, and didn't change anything for vp2410.


P4RT-1.2: Updated the port name verification with p1.Name() instead of dutPort1.Name

P4RT-1.2 :  func subscribeOnChangeInterfaceName uses dutPort1.Name to verify the port name in the response for gnmi subscription. However struct dutPort1 is not initialized with value for field Name and it leads to comparison with empty string. Corrected this by replace dutPort1.Name with p1.Name().

Pull Request Functional Test Report for #2424 / 3b0fa6e82ac2013eb523011e124b5c52398ab97a
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

P4RT-1.2: P4RT Daemon Failure

Cisco 8000E

P4RT-1.2: P4RT Daemon Failure

Cisco XRd

P4RT-1.2: P4RT Daemon Failure

Juniper cPTX

P4RT-1.2: P4RT Daemon Failure

Juniper ncPTX

P4RT-1.2: P4RT Daemon Failure

Nokia SR Linux

P4RT-1.2: P4RT Daemon Failure

Openconfig Lemming

P4RT-1.2: P4RT Daemon Failure

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

P4RT-1.2: P4RT Daemon Failure

Cisco 8808

P4RT-1.2: P4RT Daemon Failure

Juniper PTX10008

P4RT-1.2: P4RT Daemon Failure

Nokia 7250 IXR-10e

P4RT-1.2: P4RT Daemon Failure

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 50.153%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1642

Relevant Lines:
3274

💛  - Coveralls


Cannot use tactics with layer-caas-base

Trying to create a tactic for my k8s charm and experiencing an issue. The issue is that I cannot build my charm without including the wheelhouse tactic (from layer-caas-base) in my charm.
Building my charm shows (layer.yaml)
bdx@devdev:~/allcode/charms/layers/layer-elastic-operator$ make build
rm -rf .tox/
rm -rf build/
rm -rf charm-store-push-result.txt
tox -e build
build create: /home/bdx/allcode/charms/layers/layer-elastic-operator/.tox/build
build installdeps: -r/home/bdx/allcode/charms/layers/layer-elastic-operator/test-requirements.txt
build installed: atomicwrites==1.3.0,attrs==19.2.0,entrypoints==0.3,filelock==3.0.12,flake8==3.7.8,importlib-metadata==0.23,mccabe==0.6.1,more-itertools==7.2.0,packaging==19.2,pep8==1.7.1,pkg-resources==0.0.0,pluggy==0.13.0,py==1.8.0,pycodestyle==2.5.0,pyflakes==2.1.1,pyparsing==2.4.2,pytest==5.2.0,six==1.12.0,toml==0.10.0,tox==3.14.0,virtualenv==16.7.5,wcwidth==0.1.7,yapf==0.28.0,zipp==0.6.0
build runtests: PYTHONHASHSEED='0'
build runtests: commands[0] | sh -c snap list charm 2>/dev/null || sudo snap install charm --classic
Name   Version  Rev  Tracking  Publisher  Notes
charm  2.7.1    390  stable    johnsca    classic
build runtests: commands[1] | charm build --log-level DEBUG -o /home/bdx/allcode/charms/layers/layer-elastic-operator/build src
build: {
  "CHARM_BUILD_DIR": null,
  "CHARM_INTERFACES_DIR": "/home/bdx/allcode/charms/layers/layer-elastic-operator/interfaces",
  "CHARM_LAYERS_DIR": "/home/bdx/allcode/charms/layers/layer-elastic-operator/layers",
  "INTERFACE_PATH": null,
  "JUJU_REPOSITORY": "/home/bdx/allcode/charms/layers/layer-elastic-operator/build",
  "LAYER_PATH": null,
  "_charm": "src",
  "_charm_metadata": {
    "description": "Elastic.co K8S operator.\n",
    "display-name": "elastic-operator",
    "maintainers": [
      "Omnivector Solutions<EMAIL_ADDRESS>    ],
    "name": "elastic-operator",
    "resources": {
      "elastic_operator_image": {
        "description": "Elastic operator image.",
        "type": "oci-image"
      }
    },
    "series": [
      "kubernetes"
    ],
    "storage": {
      "cert": {
        "location": "/tmp/cert",
        "type": "filesystem"
      }
    },
    "summary": "Elastic Operator",
    "tags": [
      "elastic",
      "elastic.co"
    ]
  },
  "_name": null,
  "_top_layer": null,
  "_warned_home": false,
  "build_dir": "/home/bdx/allcode/charms/layers/layer-elastic-operator/build/builds",
  "cache_dir": "/home/bdx/.cache/charm/27022",
  "config": "BuildConfig({'_tactics': [], 'configured': False})",
  "debug": false,
  "description": false,
  "force": false,
  "force_color": false,
  "hide_metrics": false,
  "interface_service": null,
  "layer_index": null,
  "log_level": "DEBUG",
  "no_local_layers": false,
  "output_dir": "/home/bdx/allcode/charms/layers/layer-elastic-operator/build",
  "report": false,
  "series": null,
  "verbose": false,
  "wheelhouse_overrides": null
}
charmtools.fetchers: git rev-parse HEAD: b'4ddd74e05e0eff93ffaa7a4763a91b2b09a860ea\n'
build: Destination charm directory: /home/bdx/allcode/charms/layers/layer-elastic-operator/build/builds/elastic-operator
charmtools.build.fetchers: Checking layer index: https://juju.github.io/layer-index/layers/caas-base.json
charmtools.build.fetchers: Found repo: https://github.com/juju-solutions/layer-caas-base.git
charmtools.fetchers: git clone https://github.com/juju-solutions/layer-caas-base.git /home/bdx/.cache/charm/27022/layer/tmps9oqkmm6: b"Cloning into '/home/bdx/.cache/charm/27022/layer/tmps9oqkmm6'...\nwarning: templates not found /snap/charm/390/share/git-core/templates\n"
charmtools.fetchers: git rev-parse HEAD: b'fac96d3e2cc3b67fd450985800377643e8e13c73\n'
charmtools.build.fetchers: Copying /home/bdx/.cache/charm/27022/layer/tmps9oqkmm6 to /home/bdx/.cache/charm/27022/layer/caas-base
charmtools.build.fetchers: Cleaning up /home/bdx/.cache/charm/27022/layer/tmps9oqkmm6
Traceback (most recent call last):
  File "/snap/charm/390/bin/charm-build", line 11, in <module>
    load_entry_point('charm-tools==2.7.1', 'console_scripts', 'charm-build')()
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 941, in main
    build()
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 649, in __call__
    self.generate()
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 592, in generate
    layers = self.fetch()
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 273, in fetch
    return self.fetch_deps(self.top_layer)
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 278, in fetch_deps
    self.fetch_dep(layer, results)
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 313, in fetch_dep
    base_layer.fetch()
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 114, in fetch
    self._name = self.config.name
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/builder.py", line 51, in config
    self._config.configure(self.config_file)
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/config.py", line 66, in configure
    tactic = load_tactic(name, basedir)
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/build/tactics.py", line 1282, in load_tactic
    obj = utils.load_class(dpath, basedir)
  File "/snap/charm/390/lib/python3.6/site-packages/charmtools/utils.py", line 333, in load_class
    module = importlib.import_module(module_path)
  File "/snap/charm/390/usr/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tactics.wheelhouse'
ERROR: InvocationError: '/snap/bin/charm build --log-level DEBUG -o /home/bdx/allcode/charms/layers/layer-elastic-operator/build src'
__________________________________________________________ summary __________________________________________________________
ERROR:   build: commands failed
Makefile:20: recipe for target 'build' failed
make: *** [build] Error 1

Adding the wheelhouse.py tactic to my tactics/ and to my layer.yaml allows the charm to build.
This issue only presents itself when using layer-caas-base in a k8s charm and does not happen when building a legacy charm with layer-basic.
Any ideas?

The caas-base layer includes a custom WheelhouseTactic to override the default one built into charm build to account for the fact that k8s charms cannot perform the normal bootstrap and installation, so instead of bundling packaged wheel or egg files, it has to essentially create an embedded virtualenv.  However, both the tactics/ directory and the tactics: [] list in layer.yaml should be merged without you having to re-specify and include that custom tactic.
That the merging isn't happening as it should is a bug with charm build.  Would you mind moving this issue over to charm-tools?

Moved to https://github.com/juju/charm-tools/issues/551


changed security branch ref to 1.3.

Signed-off-by: Naveen Pajjuri<EMAIL_ADDRESS>Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #339 (59418ef) into 1.3 (fba320b) will decrease coverage by 0.78%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                1.3     #339      +/-   ##
============================================
- Coverage     72.33%   71.54%   -0.79%
+ Complexity      902      895       -7
============================================
  Files           139      139
  Lines          4453     4453
  Branches        525      525
============================================
- Hits           3221     3186      -35
- Misses          913      938      +25
- Partials        319      329      +10

Impacted Files
Coverage Δ

...rch/replication/action/status/ShardInfoResponse.kt
74.78% <0.00%> (-18.27%)
:arrow_down:

...replication/task/shard/ShardReplicationExecutor.kt
58.33% <0.00%> (-12.51%)
:arrow_down:

...rch/replication/task/shard/ShardReplicationTask.kt
72.79% <0.00%> (-3.68%)
:arrow_down:

...ation/task/shard/ShardReplicationChangesTracker.kt
60.60% <0.00%> (-3.04%)
:arrow_down:

...replication/metadata/ReplicationMetadataManager.kt
62.24% <0.00%> (-2.05%)
:arrow_down:

...arch/replication/task/autofollow/AutoFollowTask.kt
67.80% <0.00%> (-1.37%)
:arrow_down:

.../action/status/TransportReplicationStatusAction.kt
94.44% <0.00%> (-1.12%)
:arrow_down:

...rch/replication/task/index/IndexReplicationTask.kt
69.53% <0.00%> (ø)

Continue to review full report at Codecov.

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


add comments about 'ru_' sections in SGE_accounting_file_format.rst

man 2 getrusage and C/C

done with Commit 35a37e8


fix: bootstrap client entrypoint scripts as defined in index.html

Description
We currently hardcode a reference to entry-client.jsx in Html.tsx. This breaks when users attempt to change the file to be TypeScript.
This PR makes the server entrypoint smarter and leverages React 18's new bootstrapScripts and bootstrapModules SSR option which injects the script tags early enough so progressive Hydration happens as the response is streamed.
The server entrypoint uses regex to parse the user's template, grabs the <script> tags, and parses their contents to determine the values to provide to the React 18 streaming renderer.
Fixes #427
IMPORTANT: This is currently blocked by a bug in @vitejs/plugin-react documented here: https://github.com/vitejs/vite/issues/6759

Before submitting the PR, please make sure you do the following:

[x] Add your change under the Unreleased heading in the package's CHANGELOG.md
[x] Read the Contributing Guidelines
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
[x] Update docs in this repository for your change, if needed

Great! Excited to see early hydration as well 🎉

Fran did this in a better and smarter way and even made it work without the upstream fix https://github.com/Shopify/hydrogen/pull/736


Karpenter stuck on "Waiting On Cluster Sync"

Description
Observed Behavior:
Hi everyone, I've deployed Karpenter using the corresponding Helm chart for version v0.31.0 but i encounter a very strange problem: the main replica keeps logging "Waiting on cluster sync" and basically doesn't spawn any nodes. I've checked the AWS Auth configmap of my Cluster and the role is correctly present as well as the Karpenter service account and basic Karpenter configmap. In the past months I've succesfully installed Karpenter v.0.27.3 in more than 15 clusters at my company using Helm chart v0.27.3 and we didn't encounter problems at all.
(The Machine CRD was added to the workflow as described in the docs, since it was added in v0.28)
These are the logs
2023-10-27T17:01:47.700Z        DEBUG   controller.provisioner  waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:48.689Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:49.690Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:50.691Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:51.692Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:52.693Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:53.693Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:54.694Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:55.695Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:56.695Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:57.696Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:57.701Z        DEBUG   controller.provisioner  waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:58.697Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:01:59.697Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:00.698Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:01.699Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:02.699Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:03.700Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:04.700Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:05.701Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:06.701Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:07.702Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:07.702Z        DEBUG   controller.provisioner  waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:08.702Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:09.703Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:10.704Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:11.705Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:12.705Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:13.706Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:14.707Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:15.708Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:16.708Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:17.703Z        DEBUG   controller.provisioner  waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:17.709Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:18.710Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:19.711Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:20.712Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:21.712Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:22.713Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:23.714Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:24.715Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:25.715Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:26.716Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:27.704Z        DEBUG   controller.provisioner  waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:27.717Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:28.717Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:29.718Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:30.719Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:31.719Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:32.720Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:33.720Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:34.721Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:35.722Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:36.722Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:37.704Z        DEBUG   controller.provisioner  waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:37.723Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:38.724Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:39.724Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}
2023-10-27T17:02:40.725Z        DEBUG   controller.deprovisioning       waiting on cluster sync {"commit": "61b3e1e-dirty"}

Another thing i noticed is that Machine resources are not getting created at all after deploying my AWSNodeTemplate and Provisioner. I fear that I'm missing some AWS-related resources, maybe were introduced after 0.27.3, but from the docs it doesn't seem anything AWS-related was added. The nodes are not even started (I can't see them in EC2 Console)
Expected Behavior:
I should see nodes getting started from AWS EC2 Console first and then I should see them getting attached to the Cluster
Reproduction Steps (Please include YAML):
apiVersion: v1
kind: Namespace
metadata:
  name: karpetenter-test-ns
---
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: provisioner-test
spec:
  consolidation:
    enabled: true
  labels:
    intent: apps
  requirements:
    - key: karpenter.k8s.aws/instance-category
      operator: In
      values:
        - c
        - m
        - r
        - t
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - ondemand
        - spot
    - key: kubernetes.io/arch
      operator: In
      values:
        - amd64
    - key: karpenter.k8s.aws/instance-size
      operator: NotIn
      values:
        - nano
        - micro
        - small
        - medium
        - large
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  ttlSecondsUntilExpired: 2592000
  providerRef:
    name: node-template-test

---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: node-template-test
spec:
  securityGroupSelector:
    karpenter.sh/discovery: mycluster
  subnetSelector:
    karpenter.sh/discovery: mycluster
  tags:
    KarpenerProvisionerName: provisioner-test
    NodeType: karpenter-workshop
    IntentLabel: apps
    Gias_ID: test
    Env: test
    Name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
  namespace: karpetenter-test-ns
spec:
  replicas: 5
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      nodeSelector:
        intent: apps
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
          resources:
            requests:
              cpu: 1
              memory: 1.5Gi

This is the Cloudformation used to create Karpenter resources on AWS
#Template
AWSTemplateFormatVersion: '2010-09-09'

Description: EKS infrastructure for Karpenter

Parameters:
  EksClusterName:
    Type: String
    Description: Name of existing EKS Cluster
  QueueName:
    Type: String
    Description: Name of SQS Queue to create where interruption events will be notified
  RoleNamePrefix:
    Type: String
  EventBridgeRulePrefix:
    Type: String
  OidcEndpoint:
    Type: String
    Description: EKS OIDC Endpoint without https://

Resources:
  NodeRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: !Join [ "-", [!Ref RoleNamePrefix, "KarpenterNodeRole"] ]
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - ec2.amazonaws.com
            Action:
              - 'sts:AssumeRole'
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
      Policies:
        - PolicyName: CWLogsPolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - logs:DescribeLogGroups
                  - logs:DescribeLogStreams
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvent
                  - logs:PutRetentionPolicy
                Resource:
                    - "*"
        - PolicyName: ECRPullPushPolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - ecr:BatchCheckLayerAvailability
                  - ecr:GetDownloadUrlForLayer
                  - ecr:GetRepositoryPolicy
                  - ecr:DescribeRepositories
                  - ecr:ListImages
                  - ecr:DescribeImages
                  - ecr:BatchGetImage
                  - ecr:GetAuthorizationToken
                Resource:
                  - "*"
        - PolicyName: LambdaInVpcPolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - ec2:DescribeAvailabilityZones
                  - ec2:DescribeNetworkInterfaceAttribute
                  - ec2:DescribeNetworkInterfaces
                  - ec2:DescribeSecurityGroups
                  - ec2:DescribeSubnets
                  - autoscaling:DescribeVpcAttribute
                  - elasticfilesystem:Describe*
                  - kms:ListAliases
                Resource:
                  - "*"
        - PolicyName: ClusterAutoscalerPolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - autoscaling:DescribeAutoScalingGroups
                  - autoscaling:DescribeAutoScalingInstances
                  - autoscaling:DescribeLaunchConfigurations
                  - autoscaling:DescribeTags
                  - autoscaling:SetDesiredCapacity
                  - autoscaling:TerminateInstanceInAutoScalingGroup
                Resource:
                  - "*"
  NodeInstanceProfile:
    Type: 'AWS::IAM::InstanceProfile'
    Properties:
      Path: /
      InstanceProfileName:  !Join [ "-", [!Ref RoleNamePrefix, "KarpenterInstanceProfile"] ]
      Roles:
        - !Ref NodeRole
  ControllerRole:
    Type: 'AWS::IAM::Role'
    Properties:
      RoleName: !Join [ "-", [!Ref RoleNamePrefix, "KarpenterCtrlRole"] ]
      AssumeRolePolicyDocument: !Sub
        - |
          {
              "Version": "2012-10-17",
              "Statement": [
                  {
                      "Effect": "Allow",
                      "Principal": {
                          "Federated": "arn:${AWS::Partition}:iam::${AWS::AccountId}:oidc-provider/${OidcEndpoint}"
                      },
                      "Action": "sts:AssumeRoleWithWebIdentity",
                      "Condition": {
                          "StringEquals": {
                              "${OidcEndpoint}:aud": "sts.amazonaws.com",
                              "${OidcEndpoint}:sub": "system:serviceaccount:karpenter:karpenter"
                          }
                      }
                  }
              ]
          }
        - OidcEndpoint: !Ref OidcEndpoint
      Path: /
      Policies:
        - PolicyName: karpenter-controller
          PolicyDocument: !Sub
            - |
              {
                  "Statement": [
                      {
                          "Action": [
                              "ssm:GetParameter",
                              "ec2:DescribeImages",
                              "ec2:RunInstances",
                              "ec2:DescribeSubnets",
                              "ec2:DescribeSecurityGroups",
                              "ec2:DescribeLaunchTemplates",
                              "ec2:DescribeInstances",
                              "ec2:DescribeInstanceTypes",
                              "ec2:DescribeInstanceTypeOfferings",
                              "ec2:DescribeAvailabilityZones",
                              "ec2:DeleteLaunchTemplate",
                              "ec2:CreateTags",
                              "ec2:CreateLaunchTemplate",
                              "ec2:CreateFleet",
                              "ec2:DescribeSpotPriceHistory",
                              "pricing:GetProducts"
                          ],
                          "Effect": "Allow",
                          "Resource": "*",
                          "Sid": "Karpenter"
                      },
                      {
                          "Action": "ec2:TerminateInstances",
                          "Condition": {
                              "StringLike": {
                                  "ec2:ResourceTag/karpenter.sh/provisioner-name": "*"
                              }
                          },
                          "Effect": "Allow",
                          "Resource": "*",
                          "Sid": "ConditionalEC2Termination"
                      },
                      {
                          "Effect": "Allow",
                          "Action": "iam:PassRole",
                          "Resource": "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/${NodeRole}",
                          "Sid": "PassNodeIAMRole"
                      },
                      {
                          "Effect": "Allow",
                          "Action": "eks:DescribeCluster",
                          "Resource": "arn:${AWS::Partition}:eks:${AWS::Region}:${AWS::AccountId}:cluster/${ClusterName}",
                          "Sid": "EKSClusterEndpointLookup"
                      }
                  ],
                  "Version": "2012-10-17"
              }
            - ClusterName: !Ref EksClusterName
        - PolicyName: karpenter-interruption
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - "sqs:DeleteMessage"
                  - "sqs:GetQueueAttributes"
                  - "sqs:GetQueueUrl"
                  - "sqs:ReceiveMessage"
                Resource: !Sub
                  - "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:${SqsQueueName}"
                  - SqsQueueName: !GetAtt [ SqsQueue, "QueueName" ]
  SqsQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: !Ref QueueName
      MessageRetentionPeriod: 300
      SqsManagedSseEnabled: true
  SqsQueuePolicy:
    Type: AWS::SQS::QueuePolicy
    Properties:
      Queues:
        - !Ref SqsQueue
      PolicyDocument:
        Statement:
          - Action:
              - "SQS:SendMessage"
            Effect: "Allow"
            Resource: !Sub
              - "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:${SqsQueueName}"
              - SqsQueueName: !GetAtt [ SqsQueue, "QueueName" ]
            Principal:
              Service:
                - "events.amazonaws.com"
                - "sqs.amazonaws.com"

  HealthEventRule:
    Type: 'AWS::Events::Rule'
    Properties:
      Description: AWS Health Event to SQS Queue
      Name: !Join [ "-", [ !Ref EventBridgeRulePrefix, "HE" ] ]
      State: ENABLED
      EventPattern:
        detail:
          service:
          - EC2
        detail-type:
        - AWS Health Event
        source:
        - aws.health
      Targets:
        - Arn: !GetAtt [ SqsQueue, "Arn" ]
          Id: 'KarpenterInterruptionQueueTarget'

  SpotInterruptionRule:
    Type: 'AWS::Events::Rule'
    Properties:
      Description: AWS Spot Interruption to SQS Queue
      Name: !Join [ "-", [ !Ref EventBridgeRulePrefix, "SI" ] ]
      State: ENABLED
      EventPattern:
        detail-type:
        - EC2 Spot Instance Interruption Warning
        source:
        - aws.ec2
      Targets:
        - Arn: !GetAtt [ SqsQueue, "Arn" ]
          Id: 'KarpenterInterruptionQueueTarget'

  InstanceRebalanceRule:
    Type: 'AWS::Events::Rule'
    Properties:
      Description: AWS Instance Rebalance to SQS Queue
      Name: !Join [ "-", [ !Ref EventBridgeRulePrefix, "IR" ] ]
      State: ENABLED
      EventPattern:
        detail-type:
        - EC2 Instance Rebalance Recommendation
        source:
        - aws.ec2
      Targets:
        - Arn: !GetAtt [ SqsQueue, "Arn" ]
          Id: 'KarpenterInterruptionQueueTarget'

  InstanceStateChangeRule:
    Type: 'AWS::Events::Rule'
    Properties:
      Description: AWS Instance State Change to SQS Queue
      Name: !Join [ "-", [ !Ref EventBridgeRulePrefix, "ISC" ] ]
      State: ENABLED
      EventPattern:
        detail:
          state:
          - stopping
          - terminated
          - shutting-down
          - stopped
        detail-type:
        - EC2 Instance State-change Notification
        source:
        - aws.ec2
      Targets:
        - Arn: !GetAtt [ SqsQueue, "Arn" ]
          Id: 'KarpenterInterruptionQueueTarget'

Outputs:
  NodeRoleARN:
    Value: !GetAtt [ NodeRole, "Arn" ]
  InstanceRoleProfileName:
    Value: !Ref NodeInstanceProfile
  ControllerRoleARN:
    Value: !GetAtt [ ControllerRole, "Arn" ]
  QueueName:
    Value: !GetAtt [ SqsQueue, "QueueName" ]

Versions:

Karpenter: v0.31.0
Chart Version: 0.16.3
Kubernetes Version (kubectl version): 1.25

I've encountered the same bug as you. hope fixed soon

@samuel-esp
I've resolved the issue today. there was a configuration error on a statefulset regarding designating wrong storageclass name, which causing following error
controller	Reconciler error	{"commit": "61b3e1e-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-10-15-17-111.ap-northeast-2.compute.internal"}, "namespace": "", "name": "ip-10-15-17-111.ap-northeast-2.compute.internal", "reconcileID": "44d1886d-d994-46dd-999c-9350370361bc", "error": "tracking volume usage, StorageClass.storage.k8s.io \"pypi-packages\" not found"}

after fixing the storageclass error, karpenter finally came to work normal.
You should checkout if there's a configuration problem which makes karpenter stop working.

I have observed the same error message, and tracked it to a missing service linked role for spot instances: https://karpenter.sh/docs/troubleshooting/#missing-service-linked-role

@ebizboy
I've a found a similar error on mine, but looks very generic
2023-10-30T08:23:39.918Z        ERROR   controller      Reconciler error        {"commit": "61b3e1e-dirty", "controller": "node_state", "controllerGroup": "", "controllerKind": "Node", "Node": {"name":"ip-10-142-248-143.eu-central-1.compute.internal"}, "namespace": "", "name": "ip-10-142-248-143.eu-central-1.compute.internal", "reconcileID": "f2f58a84-9ffd-4efc-9756-462ca47512e7", "error": "tracking volume usage, StorageClass.storage.k8s.io \"manual\" not found"}
@michaelvl
I will investigate but I don't think the cause is the service linked role as I'm in the same account where I've previously installed Karpenter in other EKS Clusters. By the way my AWSNodeTemplate configuration also has the On-Demand fallback, so it should work even without spot instances i suppose

The issue was solved creating the storage class "manual" in my case
The question now is: is this behavior intended? I remember the same type of "Error" logs in the previous versions and we didn't have problems @jonathan-innis

I'm surprised that you didn't see this behavior in v0.27.2 with the same problem. Looks like we still log wiating on cluster sync even on this version if we fail to resolve any of the node details: https://github.com/aws/karpenter-core/blob/v0.27.2/pkg/controllers/provisioning/provisioner.go#L122

Hi @jonathan-innis I will investigate in depth the log history for my clusters where Karpenter is installed with v0.27.3. I’ll let you know if the error log I encountered in the past is the same or different, I recall encountering similar logs with StorageClasses before v0.31.0


C# Connecting a signal autogenerates function outside of class

Godot version
3.5.1 stable
System information
Arch Linux
Issue description
Connecting a signal autogenerates the function outside the node's class and gives an error that top-level function do not exist yet in Godot

Steps to reproduce
Connect signals in Godot
Minimal reproduction project
N/A

IIRC already reported

Duplicate of https://github.com/godotengine/godot/issues/18721


fixes #10: Removed unwanted content read permission

Removed unwanted content read permission as it is erroneous to have two content permission statement.

GitHub action logs
looks like CI systems are meant to set --force on the mkdocs gh-deploy command?
https://github.com/mkdocs/mkdocs/issues/973#issuecomment-228616514


fix: add support for Yarn PnP mode by adding CSS preprocessors as opt…

…ional dependencies
As Vite can require sass, stylus or less at runtime, we should add these packages as optional dependencies to ensure Vite plays nice with Yarn 2's PnP mode.
As the peer dependencies are optional, package managers won't complain if these dependencies are not provided.
I'm a little unsure of the versions I specified: I just specified the latest stable version. If specifying lower dependency version ranges would make more sense, let me know

Info about peerDependenciesMeta

Yarn 1 (doesn't support it, like npm 6): https://classic.yarnpkg.com/en/docs/dependency-types
Yarn 2: https://yarnpkg.com/configuration/manifest
npm 7: https://docs.npmjs.com/cli/v7/configuring-npm/package-json#peerdependenciesmeta

FYI peerDependenciesMeta is supported since Yarn 1.13 and NPM 6.11

This is added in the wrong package.json 🤦  This is the workspace package.json, but the one for the published vite package.


new feature: support apache hudi and other open table formats

Feature Description
Would love to see Apache Hudi along with other open table formats
Problem and Solution
support data lakehouse where you have the data in open formats and then you can move your query engine to the data.
Additional Context
Apache Hudi has a rust library that I think you can use https://github.com/apache/hudi-rs
Are you willing to contribute to the development of this feature?

[ ] Yes, I am willing to contribute to the development of this feature.

Hi, @alberttwong. I believe this issue has been mistakenly raised, as OpenDAL can't support Apache Hudi. Instead, we can integrate OpenDAL support into hudi-rs to access more storage services.

Replaced by https://github.com/apache/hudi-rs/issues/131


Make code filter conform to GitHub

According to the GFM spec, fenced code blocks can't have more than three spaces indent, and opening and closing tags don't have to have the same amount of indent.
Closing tags must also have at least as many characters as opening tags. However, gollum only supports exactly three backticks for fenced codeblocks on all pages. This PR implements the minimum length for end tags for tilde-style ~~~ fenced code blocks on markdown, however.
Also solved a bug that was causing the info-string (codeblock language) not to be correctly parsed for tilde fenced blocks: ~~~ruby was illegal, ~~~.ruby expected, but this is not correct according to the current GFM spec.
Question:

However, gollum only supports exactly three backticks for fenced codeblocks on all pages.

Does that strike us as sane behavior, or do we want fenced codeblocks that can use any number of backticks (higher than three, and at least as long end tag as star tag)?

Does that strike us as sane behavior?

Yes, for me the syntax is much clearer with exactly three backticks instead of any number over two.

👍 was hoping you'd say that!


protocol: Fix types

I tried to build it and got 133 errors.

Oh, are those used to index a large array? That seems a tad silly, but I guess also makes sense.


Dont see the Alarmoapp

Alarmo Version
V1.9.5
HA Version
Latest
Bug description
Hey i cant See the alarmocard Or anything. I always install the HA and alarmo 5 times and i delete the Cache but it dont works i Only the the hacs App.
Steps to reproduce
No response
Relevant log output
No response

You need to go to integrations and add Alarmo here to set it up.
For Alarmo card you need to install it separate (it’s in HACS as well).

I have installed it do you have anydesk? then you can come to my computer if you have time

i have installed alarmo but i dont the the alarmopanel..:(

ok i have fix it thanks

close


[Uploader] Use a  styled as a button instead of

To enable the Uploader to work in IE10 we need to replace the Upload <button> with a <label> styled as a button.

Use the accessibility for attribute on a label, pointing to the input
Make sure the input is not hidden
Hide the input by moving it off screen using absolute positioning

This button:
<Button role = { buttonRole }
        className  = { uploaderButtonClass }
        onClick    = { !isDisabled && onClick }
        isDisabled = { isDisabled }
        isReadOnly = { isReadOnly }
        iconType   = { iconType }>
    { buttonLabel }
</Button>

should be replaced with a <label> styled to look like a button when uploadState="default". For uploadState="uploaded" the button is kept.

There is a misalignment with the shadow and the content.

Also the shadow in the "uploading" and "uploaded" uploading states is not aligned as well.

[ ] Tested in IE10.

The current Uploader component makes no sense. Let’s deprecate it and implement a new UploadButton component consisting of just the button (to be implemented as a styled <label> as described above).

This issue is no longer valid – you can just build uploader will be built from existing components (e.g: Button, ProgressBar, etc.)


thunderbird: clean up, make flags closer to default, official branding

Motivation for this change
Clean up derivation, strip away flags that upstream is not happy with (such as --disable-alsa), enable official Thunderbird branding.
Superset of #38943, #36449.
cc @jerith666 @vcunat
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@sylvestre: Could you look at this again?
Section with flags is: https://github.com/NixOS/nixpkgs/blob/37e8462c4d1a4714cf2013c85f6f66f4abfd01d2/pkgs/applications/networking/mailreaders/thunderbird/default.nix#L96-L122
This has been largely based off Debian mozconfig. We can't run tests since all builds are sandboxed, and system libs contain Nix-specific patches.

@yegortimoshenko Is this waiting on review from Mozilla?

@ryantm: the enableOfficialBranding ? true part should work for them, I believe.  The rest can most likely be done independently.

I suggest this be superseded by #75328

Sure. yegortimoshenko can always reopen if he disagrees.

We did not advance the issue branding by default. @sylvestre: can you suggest how to proceed with that?  (I.e. whether it's OK or what's the problem with our current state.  Or how to find this out.)

for the record, official branding was enabled in #94880.

@jerith666 could you please tell me who reviewed the nix patches on top of tb?
Thanks

I don't know -- I only noticed #94880 because I had official branding enabled locally and got a merge conflict with it.  You've already commented on #94880 so I think you probably know more than I do.  :)


Support for new types in godot 4.4.  Added better error messages for …

Should be mergeable to main and 4.3.  Will be needed for 4.4 generator eventually.

There were a couple of conflicts with the 4.3 merge, but I merged an equivalent version.


Unittesting service registration

Hi there, I'd like to be able to write unit tests to verify that services registered in the configuration method can be resolved. It doesn't seem to be possible at the moment.

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

ID: 5786402e-9d88-5de0-607a-1c2a143af006
Version Independent ID: 15368d1c-b22e-7eb2-413f-cc0d41d2b909
Content: Use dependency injection in .NET Azure Functions
Content Source: articles/azure-functions/functions-dotnet-dependency-injection.md
Service: azure-functions
GitHub Login: @craigshoemaker
Microsoft Alias: cshoe

@hannesne Thank you for your question. We will review this and provide an update on this in the mean time you can check this SO post if that helps.
@craigshoemaker / @fabiocav any thoughts on this?

Thanks that got me on the right track. If we made FunctionsHostBuilder a public class, then we could just instantiate one in the unittest. I'm now creating a Mock of IFunctionsHostBuilder and giving it a concrete ServiceCollection, as in the post. Here's the code I'm using:
    [TestClass]
    public class StartupUnitTest
    {
        [TestMethod]
        public void CanResolveRegisteredServices()
        {
            Startup startup = new Startup();
            Mock<IFunctionsHostBuilder> builderMock = new Mock<IFunctionsHostBuilder>();
            IServiceCollection serviceCollection = new ServiceCollection();
            builderMock.SetupGet(mock => mock.Services).Returns(serviceCollection);
            IFunctionsHostBuilder builder = builderMock.Object;

            startup.Configure(builder);

            ServiceProvider provider = serviceCollection.BuildServiceProvider();
            object externalProcessManager = provider.GetService(typeof(IExternalProcessManager));
            externalProcessManager.Should().NotBeNull();
            externalProcessManager.Should().BeOfType<ExternalProcessManager>();
        }
    }

I'm also using the FluentAssertions and Moq nuget packages.

The code is in my github here: https://github.com/hannesne/FunctionsExternalProcessSample

@hannesne Thank you for the confirmation and sharing your sample, it will help other in the community.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


[client] Transport between two entities

User tab in the Market module
It allows transfer of resources from one entity to another

Hi @ponderingdemocritus I will love to work on this


"Reset sort" toolbar button

Description of the feature, modification, idea or suggestion
Add "Reset sort" button to available toolbar buttons. Action same as right click on column header and choose Reset sort.
Proposed implementation details (optional)
When current tab doesnt have Reset sort feature (f.e. Services, Network) - button disabled (grayed).

How often do you reset the tree sorting? Have you tried using column sets instead?

How often do you reset the tree sorting?

Very often. Usual is default sorting (tree) but after start often need to sort by CPU or RAM and immediately restore to default.

I also switch tree sorting very frequently, especially to CPU sort and back.
A small quality-of-life detail that is painfully missing after I came over from using Process Explorer is the shortcut (Ctrl-T) and toolbar button to restore the tree sorting.
Please please please at a shortcut like Ctrl-T as well! :)


Modifying ClassNLLCriterion.cu

Replacing ClassNLLCriterion.cu in ~/torch/extra/cunn/lib/THCUNN/ throws up errors :
/u/<user>/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(126): error: identifier "THCRealTensor_checkGPU" is undefined

/u/<user>/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(130): error: identifier "THCRealTensor_checkGPU" is undefined

/u/<user>/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(198): error: identifier "THCRealTensor_checkGPU" is undefined

/u/<user>/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(203): error: identifier "THCRealTensor_checkGPU" is undefined

4 errors detected in the compilation of "/tmp/tmpxft_0000621d_00000000-7_ClassNLLCriterion.cpp1.ii".
CMake Error at THCUNN_generated_ClassNLLCriterion.cu.o.cmake:267 (message):
  Error generating file
  /u/<user>/torch/extra/cunn/build/lib/THCUNN/CMakeFiles/THCUNN.dir//./THCUNN_generated_ClassNLLCriterion.cu.o

I think the problem is caused by the torch7 version, because torch7’s backend development is quite active. The torch7 version I used is c0e51b98acbb54e6655343a57152b6e711ffdc2b.

There seems to be some more errors in THCNN , is there a specific version of that required ?
Error Message :
In file included from /u/<user>/torch/extra/cunn/lib/THCUNN/BatchNormalization.cu:1:0:
/u/<user>/torch/extra/cunn/lib/THCUNN/THCUNN.h:11:35: fatal error: THCGenerateFloatTypes.h: No such file or directory
 #include "THCGenerateFloatTypes.h"
                                   ^
compilation terminated.
CMake Error at THCUNN_generated_BatchNormalization.cu.o.cmake:206 (message):
  Error generating
  /u/<user>/torch/extra/cunn/build/lib/THCUNN/CMakeFiles/THCUNN.dir//./THCUNN_generated_BatchNormalization.cu.o
make[2]: *** [lib/THCUNN/CMakeFiles/THCUNN.dir/./THCUNN_generated_BatchNormalization.cu.o] Error 1
make[1]: *** [lib/THCUNN/CMakeFiles/THCUNN.dir/all] Error 2
make: *** [all] Error 2

The error seems to be caused by the problem of torch's install script. I am not sure what the specific reason is.

Line 44 of install.sh git submodule update --init --recursive probably needs to be uncommented since our goal is to build the specific version c0e51b98acbb54e6655343a57152b6e711ffdc2b.

Running with the git update commented out yields the following error, during the building of rocks/cunn-scm-1.rockspec. (BTW, we are building with CUDA v 8.0 for CUDA architecture 3.5.)
/u/vj0/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(126): error: identifier "THCRealTensor_checkGPU" is undefined

/u/vj0/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(130): error: identifier "THCRealTensor_checkGPU" is undefined

/u/vj0/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(198): error: identifier "THCRealTensor_checkGPU" is undefined

/u/vj0/torch/extra/cunn/lib/THCUNN/ClassNLLCriterion.cu(203): error: identifier "THCRealTensor_checkGPU" is undefined

4 errors detected in the compilation of "/tmp/tmpxft_000006f4_00000000-7_ClassNLLCriterion.cpp1.ii".
CMake Error at THCUNN_generated_ClassNLLCriterion.cu.o.cmake:264 (message):
  Error generating file
  /u/vj0/torch/extra/cunn/build/lib/THCUNN/CMakeFiles/THCUNN.dir//./THCUNN_generated_ClassNLLCriterion.cu.o

The environment we used:
OS: Scientific Linux 7.1
GCC: 4.9.1 20140922 (Red Hat 4.9.1-10)
GPU: 980 or titan x
CUDA: 7.5

I compress my torch folder and upload it to Google Drive.
Link: https://drive.google.com/file/d/0B8yp1gOBCztycW42eDNNaExWSlU/view?usp=sharing
Hope this would help.

Thanks, with this torch folder I was able to make it work -- blew away cmake cache files, and ran install.sh. I am able to run lang2logic now... awesome!

Great!

hi @saraswat ,  I met the same problem as you. my question is how to remove the cmake cache files. I am a rookie for linux os. thanks!

@saraswat  I solved it. just run clean.sh. Thanks!


Removed unwanted debug task that was merged by mistake.

As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date:

/approve
though... might be interesting for further debugging?

/approve
using right account may help right? Still - wouldn't those ones be useful for deeper debugging?

/lgtm