Update openblas to version 0.3.15

Motivation for this change
Openblas version 0.3.13 and 0.3.14 fails to properly identify the architecture on some ARMV8 systems. This is documented in the openblas change log for version 0.3.15 as a bugfix for ARM64 archs: https://github.com/xianyi/OpenBLAS/blob/v0.3.15/Changelog.txt#L40
The fix changelog note reads:

fixed a segmentation fault in DYNAMIC_ARCH builds (reappeared in 0.3.14)

Things done

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

[x] NixOS
[ ] macOS
[x] Ubuntu 18.04 multiuser nixpkgs

[ ] 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 nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

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

[ ] Fits CONTRIBUTING.md.

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

This will have to go to staging because of the massive rebuild count.

I think the ideal target is staging (https://github.com/NixOS/nixpkgs/tree/staging(

/rebase staging

This is already in staging with #122035, assuming it wasn't reverted.

No, it wasn't reverted. https://github.com/NixOS/nixpkgs/blob/staging/pkgs/development/libraries/science/math/openblas/default.nix#L125


Openssl version needs a bump

0.6 is out and this is still pinned to the 0.5 range, causing a build failure for hyper.

@reem  covers in #30

+1

Fixed in #60


Johanna/6723 add destination disease columns upload table

BACKEND PULL REQUEST
Related Issue

Resolves #6723

Changes Proposed

Creates the model for the new table UploadDiseaseDetails and corresponding repository.
Updates to TestResultUploadService include:

CVS validation logic moved to its own method.
Processing of the ReportStream response (covid and universal pipeline) have been moved to their own method.
Method saveSubmissionToDb now receives the destination pipeline and the disease/count breakdown.

Creates auxiliary classes :

FHIRBundleRecord : contains the serialized fhir bundle plus the diseases/count breakdown as metadata.
CovidSummisionSummary: contains the RS response and other information relevant to covid reporting (e.g.: submissionId, org, destination).
UniversalSummisionSummary: contains the RS response and other information relevant to universal reporting (e.g.: submissionId, org, destination).
Pipeline: new type to represent COVID | UNIVERSAL pipeline names.

TestResultUpload now uses the @builder annotation.

Testing
Code is available in dev2.

Upload a file and verify that the upload records and the disease details are correctly logged in our DB.
Verify validations work as usual.

I have address the feedback from Boban and Bob. New code is available in dev2 thanks!


request error Context conflict

Environment
production and dev
Reproduction
https://stackblitz.com/edit/nuxt-issue-20070
It is also related to the package "@nuxtjs/i18n" and "useCookie".
1. On a clean nuxt 3 project, install:
"@nuxtjs/i18n": "^8.0.0-beta.10"
2. Create global middleware like this:
export default defineNuxtRouteMiddleware(() => {
  const session = useCookie<string>("uuidSession");
});

3. Use siege and gtimeout to send multiple concurrent requests:
brew install siege
brew install coreutils
gtimeout 30 siege -c 5 http://localhost:3000
then sometimes I will get the error:
[nuxt] [request error] [unhandled] [500] Context conflict
Describe the bug
Error appears in production and local logs:
[nuxt] [request error] [unhandled] [500] Context conflict

Additional context
No response
Logs
[nuxt] [request error] [unhandled] [500] Context conflict                                                                                12:51:26
  at checkConflict (./node_modules/unctx/dist/index.mjs:6:13)
  at Object.call (./node_modules/unctx/dist/index.mjs:31:7)
  at contextCaller (./node_modules/nuxt/dist/app/nuxt.js:61:26)
  at Hookable.callHookWith (./node_modules/hookable/dist/index.mjs:198:20)
  at Hookable.nuxtApp.hooks.callHook (./node_modules/nuxt/dist/app/nuxt.js:64:63)
  at ./.nuxt/dev/index.mjs:723:32
  at processTicksAndRejections (node:internal/process/task_queues:96:5)
  at async ./.nuxt/dev/index.mjs:394:22
  at async Object.handler (./node_modules/h3/dist/index.mjs:1247:19)
  at async Server.toNodeHandle (./node_modules/h3/dist/index.mjs:1322:7)

@kazupon can you please provide a workaround?

same! @kazupon please we need your help, it is blocking issue

@kazupon useCookie is not the issue, i tried without and the same error happeneds

@kazupon useCookie is not the issue, i tried without and the same error happened

For me removing useCookie helps, but I need it

Hi!
Thank you for your reporting!
I would like you to sepelate this issue if this issue can be reproduced with your cusomt module without using nuxt i18n first. 🙏
If so, you should report it to nuxt as an issue, as it is probably a problem with useCookie.

Hi! Thank you for your reporting!
I would like you to sepelate this issue if this issue can be reproduced with your cusomt module without using nuxt i18n first. 🙏 If so, you should report it to nuxt as an issue, as it is probably a problem with useCookie.

👍 thx @kazupon after digging deeper it stuck in the app:render hook. The unctx is checking the currentContext vs instance ctx and throws an 500 error

@EduardoMateos
can you please try below Nuxt 3.3.2?
See: https://github.com/nuxt/nuxt/pull/19753

@c-schwan you're right. in version 3.3.0 it doesn't happen.

How can we resolve it?

fixed: https://github.com/nuxt/nuxt/pull/20510
version 3.4.3


Remove try! statement from FailableIterator

My team has recently experienced crashes of an app in production related to SQLite.swift. Upon further review, we discovered that these crashes are occurring due to this try! encountering a throw from failableNext().
This PR resolves the issue by returning nil if a throw is encountered.
Here is the entire thread that crashes. Note that it occurs when using the Apollo-iOS framework, found here:
Thread 7 name:
Thread 7 Crashed:
0   libswiftCore.dylib            	0x000000010117f968 0x100fa0000 + 1964392
1   libswiftCore.dylib            	0x000000010117f968 0x100fa0000 + 1964392
2   libswiftCore.dylib            	0x000000010102f994 0x100fa0000 + 588180
3   SQLite                        	0x0000000100d7e80c _T06SQLite16FailableIteratorPAAE4next7ElementQzSgyFAA9StatementC_Tg5 + 212 (Statement.swift:211)
4   SQLite                        	0x0000000100d674c8 _T06SQLite10ConnectionC7prepares11AnySequenceVyAA3RowVGAA9QueryType_pKFs0D8IteratorVyAHGycfU_AHSgycfU_TA + 76 (Query.swift:927)
5   SQLite                        	0x0000000100d67578 _T06SQLite3RowVSgIxo_ADIxr_TRTA + 48 (Query.swift:0)
6   libswiftCore.dylib            	0x000000010114e9bc 0x100fa0000 + 1763772
7   libswiftCore.dylib            	0x000000010114e9fc 0x100fa0000 + 1763836
8   libswiftCore.dylib            	0x000000010114ead0 0x100fa0000 + 1764048
9   libswiftCore.dylib            	0x000000010102a8c8 0x100fa0000 + 567496
10  libswiftCore.dylib            	0x000000010114e16c 0x100fa0000 + 1761644
11  libswiftCore.dylib            	0x000000010118fd78 0x100fa0000 + 2030968
12  libswiftCore.dylib            	0x0000000100fa8774 0x100fa0000 + 34676
13  libswiftCore.dylib            	0x000000010115f5bc 0x100fa0000 + 1832380
14  libswiftCore.dylib            	0x000000010114f4fc 0x100fa0000 + 1766652
15  Apollo                        	0x0000000100a01c3c _T06Apollo21SQLiteNormalizedCacheC13selectRecords33_0382DE2BE0B0836588D3F2CA65C602E7LLSayAA6RecordVGSaySSG7forKeys_tKFTf4gn_n + 1284 (SQLiteNormalizedCache.swift:0)
16  Apollo                        	0x0000000100a02710 _T06Apollo21SQLiteNormalizedCacheC12mergeRecords33_0382DE2BE0B0836588D3F2CA65C602E7LLs3SetVySSGAA06RecordO0V7records_tKFTf4gn_n + 116 (SQLiteNormalizedCache.swift:0)
17  Apollo                        	0x0000000100a031c8 _T06Apollo21SQLiteNormalizedCacheC5mergeAA7PromiseCys3SetVySSGGAA06RecordG0V7records_tFTf4gn_n + 304 (SQLiteNormalizedCache.swift:0)
18  Apollo                        	0x00000001009ff290 _T06Apollo21SQLiteNormalizedCacheCAA0cD0A2aDP5mergeAA7PromiseCys3SetVySSGGAA06RecordG0V7records_tFTW + 44 (SQLiteNormalizedCache.swift:0)
19  Apollo                        	0x000000010099d1ec _T06Apollo0A5StoreC7publishAA7PromiseCyytGAA9RecordSetV7records_SvSg7contexttFyyyc_ys5Error_pctcfU_yycfU_Tf4ggng_n + 164 (ApolloStore.swift:52)
20  Apollo                        	0x000000010099f788 _T06Apollo0A5StoreC7publishAA7PromiseCyytGAA9RecordSetV7records_SvSg7contexttFyyyc_ys5Error_pctcfU_yycfU_TA + 104 (ApolloStore.swift:0)
21  Apollo                        	0x00000001009c0f1c _T0Ix_IyB_TR + 36 (GraphQLQueryWatcher.swift:0)
22  libdispatch.dylib             	0x00000001812b2a54 _dispatch_call_block_and_release + 24 (init.c:994)
23  libdispatch.dylib             	0x00000001812b2a14 _dispatch_client_callout + 16 (object.m:502)
24  libdispatch.dylib             	0x00000001812c1540 _dispatch_queue_concurrent_drain + 540 (inline_internal.h:2500)
25  libdispatch.dylib             	0x00000001812bd304 _dispatch_queue_invoke$VARIANT$mp + 348 (queue.c:5304)
26  libdispatch.dylib             	0x00000001812bfcf4 _dispatch_root_queue_drain + 600 (inline_internal.h:2539)
27  libdispatch.dylib             	0x00000001812bfa38 _dispatch_worker_thread3 + 120 (queue.c:6104)
28  libsystem_pthread.dylib       	0x000000018155b06c _pthread_wqthread + 1268 (pthread.c:2286)
29  libsystem_pthread.dylib       	0x000000018155ab6c start_wqthread + 4

@stephencelis any chance this could get a review/merge soon?

Hi @ethansinjin! Thanks for the submission! I've handed off maintenance, but hopefully @jberkel could give it a quick look to make sure it doesn't break anything?

@ethansinjin it's called FailableIterator for a reason, mapping errors to nil would be obscuring the actual error (and lose the distinction between error case and no more elements).
If I remember correctly the problem is that Swift's iterator protocol doesn't assume that the iteration can produce errors. Statement has a failableNext() throws -> [Binding?]? which could perhaps be used instead.
What's the error thrown in your case?

@jberkel: EXC_BAD_INSTRUCTION fatal error: unexpectedly found nil while unwrapping an Optional value

@ethansinjin unwrapping an optional value? that sounds like it's not the immediate cause. would expect to see some error thrown from within SQLite.

My apologies, I don't think that's the actual crash.
It looks like the following function is the root cause of the crash:
Statement.swift lines 185-187:
public func step() throws -> Bool {
        return try connection.sync { try self.connection.check(sqlite3_step(self.handle)) == SQLITE_ROW }
    }

One of the trys is failing. The caller of this code is Statement.swift lines 224 to 229:
extension Statement : FailableIterator {
    public typealias Element = [Binding?]
    public func failableNext() throws -> [Binding?]? {
        return try step() ? Array(row) : nil
    }
}

Because failableNext() receives a throw, it throws. Next, up the chain to Statement.swift lines 209 to 213:
extension FailableIterator {
    public func next() -> Element? {
        return try! failableNext()
    }
}

Because next() receives a throw, it throws. But, since it is a try!, this triggers a crash.
The Swift Programming Language Docs section on Error Handling, specifically "Disabling Error Propagation":

Sometimes you know a throwing function or method won’t, in fact, throw an error at runtime. On those occasions, you can write try! before the expression to disable error propagation and wrap the call in a runtime assertion that no error will be thrown. If an error actually is thrown, you’ll get a runtime error.

Please let me know if there's any more information I can provide!

Have a look at the check function (Connection:642)
func check(_ resultCode: Int32, statement: Statement? = nil) throws -> Int32 {
  guard let error = Result(errorCode: resultCode, connection: self, statement: statement) else {
    return resultCode
  }
  throw error
}

It's very likely that the error gets thrown from there, which means that SQLite returned an error code. You should see this error somewhere in the log output. If not, try to put a breakpoint at the line where the error is thrown and run it in the debugger.

We've run into this crash as well when sqlite3_step() encounters an error while iterating rows.
From my understanding, and as @ethansinjin discusses above, the prepare function returns a collection that is effectively an AnySequence { AnyIterator { try! sqlite3_step() } }. This means that any failure that occurs during iteration (e.g. the table was deleted while iterating its rows on a separate connection), will crash your application. This is a very unexpected behavior in Swift, especially from a function that throws and isn't marked with Unsafe name or a ! operator.
After looking at the options for a fix, it seems like this is perhaps a deeper design issue. I see two options two prevent the crash:

Return a Sequence that ends when an error is encountered (@ethansinjin's fix), which would be a nonbreaking change but would unexpectedly suppress the error that occurred.

Adopt a construct like Cursor from GRDB that is effectively an iterator that can throw on each next(). There's a discussion here https://github.com/groue/GRDB.swift/pull/148 about this construct, with the following summary:

Until now, GRDB would assume that both SQLite and the database file(s) were fundamentally trustable. Well, the file system is not trustable. Applications have to be able to deal with I/O errors.

This would require all consumers to migrate to a different API, but would be more correct than the current implementation, in that it could produce an error during iteration, just as the sqlite3_step() does.

Let me know which option seems like the best next step, or if there's another alternative I'm not considering.
on an entirely separate note 👋 @ethansinjin hope things are well!

We have run into the same crash. Any chance that you can take a look? thanks! CC: @jberkel

Hello, I am having the same issue, and I've read this thread and am having the same issue.
2 thoughts.

FailableIterator should be named to FatalIterator if this change or something like it doesn't go in. Unwrapping optionals is inherently "failable", but it's also not an exception. If the intent was to be failable yet catchable, it should not be unwrapping try!.

If this fix does not go in, I suggest this change instead, and the respective required changes to go with it.

extension FailableIterator {
    public func next() -> Element? throws {
        return try failableNext()
    }
}

Though the function signature is curious as it returns nullable. So in conclusion, what is "failable" in your definition here?
It should be noted that another library which uses this library, wraps it in a Promise API. And the way promises work, is that they catch exceptions from within the promise context. So in essence you use a promise to have safe error recoverable interface that is simply analogous to do {} catch {}. Though if something does not mark as throws, and it can fail, there is nothing a consumer API can do about that, but crash.

How about this change?
extension Connection {

    public func prepare(_ query: QueryType) throws -> AnySequence<Row> {
        let expression = query.expression
        let statement = try prepare(expression.template, expression.bindings)

        let columnNames = try columnNamesForQuery(query)

        return AnySequence {
            AnyIterator { statement.next().map { Row(columnNames, $0) } }
        }
    }
    ...

to this:
extension Connection {

    public func prepare(_ query: QueryType) throws -> AnySequence<Row> {
        let expression = query.expression
        let statement = try prepare(expression.template, expression.bindings)

        let columnNames = try columnNamesForQuery(query)

        return AnySequence {
            AnyIterator { statement.failableNext().map { Row(columnNames, $0) } }
        }
    }

Actually, about this the previous change I just metioned, and the change for this PR?
The reason behind this is because now that I see the use case of FailableIterator, it is to provide failableNext(). We just need to use that where appropriate, and not crash where it isn't appropriate and next() is used.

Hi,
We are experiencing the same issues. Will this patch be merged into master? We need to find a solution that will last, seen many people implement this change locally but we are keen on not branching out this library for future compatibility
Thanks!
@ethansinjin @jberkel

I run into the same issue. I was curious to understand why the iterator calls .next() everytime its created. This reads like every iterator creation moves the initial cursor and would therefore return a different sequence:
public func prepare(_ query: QueryType) throws -> AnySequence<Row> {
    let expression = query.expression
    let statement = try prepare(expression.template, expression.bindings)

    let columnNames = try columnNamesForQuery(query)

    return AnySequence {
        AnyIterator { statement.next().map { Row(columnNames, $0) } }
    }
}

instead of maybe
public func prepare(_ query: QueryType) throws -> AnySequence<Row> {
    let expression = query.expression
    let statement = try prepare(expression.template, expression.bindings)

    let columnNames = try columnNamesForQuery(query)
    let results = try statement.failableNext()
    return AnySequence {
        AnyIterator { results.map { Row(columnNames, $0) } }
    }
}

See https://github.com/stephencelis/SQLite.swift/pull/1002

I'd also like to know if this is going to be merged? Cause I am seeing the same issue in my crashreports. Can't reproduce it locally though..

Closing as this was fixed by another PR (replacing the ! by a ?)

@NathanFallet which PR?

@kylebrowning it was #1030, which was later reverted in #1075.

So its not fixed?

See #1030 if you need more details


A BUG in the interface caused by characters during credit and deposit

Steps:

In self-help lending, continue to deposit the corresponding mortgage
Enter input “.”

Problem Description:

Address: 5Coiddko324JRzZpr7yKMEhXhhmEEZS1PL3bW3zuydiiyj1G

duplicated #127


Subsequent Chef runs fail on setuptools on Ubuntu 16.04

I've been seeing errors on Ubuntu 16.04 with subsequent chef runs failing after a successful first converge on python_package[setuptools] action install (full gist):
  * python_package[setuptools] action install

    ================================================================================
    Error executing action `install` on resource 'python_package[setuptools]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '1'
    ---- Begin output of ["/usr/bin/python2.7", "-", "setuptools"] ----
    STDOUT:
    STDERR: No handlers could be found for logger "pip.download"
    Traceback (most recent call last):
      File "<stdin>", line 38, in <module>
      File "/usr/local/lib/python2.7/dist-packages/pip/index.py", line 514, in find_requirement
        'No matching distribution found for %s' % req
    pip.exceptions.DistributionNotFound: No matching distribution found for setuptools
    ---- End output of ["/usr/bin/python2.7", "-", "setuptools"] ----
    Ran ["/usr/bin/python2.7", "-", "setuptools"] returned 1

I also have 14.04 systems that run the same code without issue.
Our use is pretty vanilla, I think:
python_runtime '2.7'

python_virtualenv <py_home> do
  group <py_group>
  user <py_user>
end

execute 'update virtualenv permissions' do
  command "chown -R <py_user>:<py_group> <py_home>"
end

I welcome any suggestions to mitigate this.
Thanks!

Update: as near as I can tell, this is only happening with interactive chef-client runs. Runs from a chef-client service or via test-kitchen seem fine, but sudo chef-client fails every time for me.

@luckymike Any odd environment variables in your session?

@coderanger nothing leaps out. We have some job specific vars à la FB_AD_CLICK_SECRET but nothing I'd expect to interfere with python.

Same here.
---- Begin output of ["/usr/bin/python3.5", "-", "setuptools"] ----
STDOUT:
STDERR: The directory '/home/air15884/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Could not find a version that satisfies the requirement setuptools (from versions: )
Traceback (most recent call last):
  File "<stdin>", line 38, in <module>
  File "/usr/local/lib/python3.5/dist-packages/pip/index.py", line 514, in find_requirement
    'No matching distribution found for %s' % req
pip.exceptions.DistributionNotFound: No matching distribution found for setuptools
---- End output of ["/usr/bin/python3.5", "-", "setuptools"] ----

How can I set up pip to work with -H flag?
If executing pip with sudo, you may want sudo's -H flag.

This is probably the same bug as #42, bad user/perm stuffs on non-root venvs.


Fixed Rate Borrow - Block Analitica dashboard

BA dashboard pages for Fixed Rate Borrow. These pages will be contained within the existing Hyperdrive Block Analitica dashboard and accessible via a global toggle [Hyperdrive][Fixed Rate Borrow] on the dashboard home page.
New FRB Pages:

Home
Markets
Market-specific pages (1 for each Hyperdrive-Morpho compatible market)
Coverage Positions
Coverage Position-specific pages (1 for each individual position)
Activity
Wallets
Wallet-specific pages

Requirements doc:
https://docs.google.com/document/d/137kJqVBhJ4bJ7TPrzWWrpGeEXbeFbQPv_luYj84u9-k/edit?usp=sharing

Requirements doc (90%)
Project Scope & Timelines (in progress)
Contract (in progress: DELV legal <> BA)
Development
User Testing & QA

Requirements were completed end of June. Andrea sent over the agreement to BA team. BA is expected to get started on development this week.


Undo a breaking change

This change wasn't caught in my previous PR because the baselines hadn't been updated yet 😆

FYI only as this is the same as the other changes I made


Not all semver specifications are supported

Currently this triggers an error when parsed.
pragma solidity >=0.7.0 <=0.8.5;

Here is a detailed example of a grammar that supports all current semver compatible notations.
On another hand, solidity's official lexer just accepts a blob between the tokens pragma and ;
Hopefully this helps.

@Janther this input is parsing successfully without errors (see below). Can you please clarify? which error are you seeing?
  - (SourceUnit) ► (members꞉ SourceUnitMembers): # "pragma solidity >=0.7.0 <=0.8.5;\n" (0..33)
      - (item꞉ SourceUnitMember) ► (variant꞉ PragmaDirective): # "pragma solidity >=0.7.0 <=0.8.5;\n" (0..33)
          - (pragma_keyword꞉ PragmaKeyword): "pragma" # (0..6)
          - (pragma꞉ Pragma) ► (variant꞉ VersionPragma): # " solidity >=0.7.0 <=0.8.5" (6..31)
              - (leading_trivia꞉ Whitespace): " " # (6..7)
              - (solidity_keyword꞉ SolidityKeyword): "solidity" # (7..15)
              - (sets꞉ VersionExpressionSets): # " >=0.7.0 <=0.8.5" (15..31)
                  - (item꞉ VersionExpressionSet): # " >=0.7.0 <=0.8.5" (15..31)
                      - (item꞉ VersionExpression) ► (variant꞉ VersionComparator): # " >=0.7.0" (15..23)
                          - (leading_trivia꞉ Whitespace): " " # (15..16)
                          - (operator꞉ GreaterThanEqual): ">=" # (16..18)
                          - (operand꞉ VersionExpression) ► (variant꞉ VersionSpecifiers): # "0.7.0" (18..23)
                              - (item꞉ VersionSpecifier): "0" # (18..19)
                              - (separator꞉ Period): "." # (19..20)
                              - (item꞉ VersionSpecifier): "7" # (20..21)
                              - (separator꞉ Period): "." # (21..22)
                              - (item꞉ VersionSpecifier): "0" # (22..23)
                      - (item꞉ VersionExpression) ► (variant꞉ VersionComparator): # " <=0.8.5" (23..31)
                          - (leading_trivia꞉ Whitespace): " " # (23..24)
                          - (operator꞉ LessThanEqual): "<=" # (24..26)
                          - (operand꞉ VersionExpression) ► (variant꞉ VersionSpecifiers): # "0.8.5" (26..31)
                              - (item꞉ VersionSpecifier): "0" # (26..27)
                              - (separator꞉ Period): "." # (27..28)
                              - (item꞉ VersionSpecifier): "8" # (28..29)
                              - (separator꞉ Period): "." # (29..30)
                              - (item꞉ VersionSpecifier): "5" # (30..31)
          - (semicolon꞉ Semicolon): ";" # (31..32)
          - (trailing_trivia꞉ EndOfLine): "\n" # (32..33)

when going through the tree, this is the error I get when reaching the level of VersionComparator
const source = `
pragma solidity >=0.7.0 <=0.8.5;
`;

const language = new Language('0.8.25');
new SourceUnit(language.parse(RuleKind.SourceUnit, source).tree())
  .members
    .items[0]
      .variant
        .pragma
          .variant
            .sets
              .items[0]
                .items[0]
                  .variant
                    .operator; // Missing child node at index '1'.

Thanks for the repro. Looking into it!

Not sure if it's related but I have found a similar error when parsing code with a ComparisonExpression.
There might be an issue when parsing comparison symbols (eg: <=).
Since the same would happen when reading the VersionComparator.
const source = `
contract Comparison {
  function compare(uint a, uint b) public pure returns(bool) {
      return a <= b;
  }
}

`;

const language = new Language('0.8.25');
const parsed = new SourceUnit(language.parse(RuleKind.SourceUnit, source).tree())
  .members
    .items[0]
      .variant
        .members
          .items[0]
            .variant
              .body
                .variant
                  .statements
                    .items[0]
                      .variant
                        .expression
                          .variant
                            .leftOperand; // Missing child node at index '2'.


Finalize TX-PVLS indicator: Percentage of ART patients with a suppres…

…sed viral load (VL) result (<1000 copies/ml) documented in the medical or laboratory records/laboratory information systems (LIS) within the past 12 months

Description of what I changed
I have added threshold for failure as it is different in different countries, for example AMPATH uses 30 instead of 1000

E2E test

TESTED:
cd dwh; ./validate_indicators.sh
Checklist: I completed these to help reviewers :)

[x] My IDE is configured to follow the code style of this project.
No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend

[x] I am familiar with Google Style Guides for the language I have coded in.
No? Please take some time and review Java and Python style guides. Note, when in conflict, OpenMRS style guide overrules.

[ ] I have added tests to cover my changes. (If you refactored existing code that was well tested you do not have to add tests)
No? -> write tests and add them to this commit git add . && git commit --amend

[X] I ran mvn clean package right before creating this pull request and added all formatting changes to my commit.

[X] All new and existing tests passed.
No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.

[X] My pull request is based on the latest changes of the master branch.
No? Unsure? -> execute command git pull --rebase upstream master

thank you @bashir2  for the review. Let me address  this feedback then get back to you


Bootstrap network check

Better Robustness for the Docker Swarm bootstrap

containers are auto removed when killed (better test experience)
Docker Swarm DNS resolution check at end of init, container is killed if test fails
update the etcd image (quits early in case of DNS issues)

how to test:
hack/deploy

the services should all stabilize.
PS: you can monitor the container initialization in the InfraKit logs:
docker logs -f instance-plugin-docker 2>&1 | grep exec
time="2017-04-05T17:43:41Z" level=debug msg="exec the init script"
time="2017-04-05T17:43:49Z" level=debug msg="Init script succesfully executed"

These two lines will appear for each successfully initialized node. Be aware that initialization failure can come from other things than DNS issues.

It doesn't work on linux anymore. The master works fine though.

With the latest changed, the swarm never gets deployed on my machine. Nodes keep failing and restarting and eventually, the timeout is reached.

On my mac, it works 3 times and failed the forth at the end, two nodes which has no swarm dns working have not been re-created and stay like that until the script timeout


Make sure country name is always tracked in en_US

This update is to make sure country names are tracked in the same language across the events to streamline analytics and segmentations.

Included in 1.1.1 version


Bump rdkafka to 0.13.0

Main changes from rdkafka-ruby changelog

Support cooperative sticky partition assignment in the rebalance callback (methodmissing)
Support both string and symbol header keys (ColinDKelley)
Handle tombstone messages properly (kgalieva)
Add topic name to delivery report (maeve)
Allow string partitioner config (mollyegibson)
Fix documented type for DeliveryReport#error (jimmydo)
Bump librdkafka to 2.0.2 (lmaia)
Use finalizers to cleanly exit producer and admin (thijsc)
Lock access to the native kafka client (thijsc)
Fix potential race condition in multi-threaded producer (mensfeld)
Fix leaking FFI resources in specs (mensfeld)
Improve specs stability (mensfeld)
Make metadata request timeout configurable (mensfeld)
call_on_partitions_assigned and call_on_partitions_revoked only get a tpl passed in (thijsc)

Full diff https://my.diffend.io/gems/rdkafka/0.12.0/0.13.0
Changes in librdkafka from their changelog

See changes
librdkafka v2.0.2
librdkafka v2.0.2 is a maintenance release:

Fix OpenSSL version in Win32 nuget package (#4152).

librdkafka v2.0.1
librdkafka v2.0.1 is a maintenance release:

Fixed nuget package for Linux ARM64 release (#4150).

librdkafka v2.0.0
librdkafka v2.0.0 is a feature release:

KIP-88
OffsetFetch Protocol Update (#3995).
KIP-222
Add Consumer Group operations to Admin API (started by @lesterfan, #3995).
KIP-518
Allow listing consumer groups per state (#3995).
KIP-396
Partially implemented: support for AlterConsumerGroupOffsets
(started by @lesterfan, #3995).
OpenSSL 3.0.x support - the maximum bundled OpenSSL version is now 3.0.7 (previously 1.1.1q).
Fixes to the transactional and idempotent producer.

Upgrade considerations
OpenSSL 3.0.x
OpenSSL default ciphers
The introduction of OpenSSL 3.0.x in the self-contained librdkafka bundles
changes the default set of available ciphers, in particular all obsolete
or insecure ciphers and algorithms as listed in the
OpenSSL legacy
manual page are now disabled by default.
WARNING: These ciphers are disabled for security reasons and it is
highly recommended NOT to use them.
Should you need to use any of these old ciphers you'll need to explicitly
enable the legacy provider by configuring ssl.providers=default,legacy
on the librdkafka client.
OpenSSL engines and providers
OpenSSL 3.0.x deprecates the use of engines, which is being replaced by
providers. As such librdkafka will emit a deprecation warning if
ssl.engine.location is configured.
OpenSSL providers may be configured with the new ssl.providers
configuration property.
Broker TLS certificate hostname verification
The default value for ssl.endpoint.identification.algorithm has been
changed from none (no hostname verification) to https, which enables
broker hostname verification (to counter man-in-the-middle
impersonation attacks) by default.
To restore the previous behaviour, set ssl.endpoint.identification.algorithm to none.
Known Issues
Poor Consumer batch API messaging guarantees
The Consumer Batch APIs rd_kafka_consume_batch() and rd_kafka_consume_batch_queue()
are not thread safe if rkmessages_size is greater than 1 and any of the seek,
pause, resume or rebalancing operation is performed in parallel with any of
the above APIs. Some of the messages might be lost, or erroneously returned to the
application, in the above scenario.
It is strongly recommended to use the Consumer Batch APIs and the mentioned
operations in sequential order in order to get consistent result.
For rebalancing operation to work in sequencial manner, please set rebalance_cb
configuration property (refer [examples/rdkafka_complex_consumer_example.c]
(examples/rdkafka_complex_consumer_example.c) for the help with the usage) for the consumer.
Enhancements

Self-contained static libraries can now be built on Linux arm64 (#4005).
Updated to zlib 1.2.13, zstd 1.5.2, and curl 7.86.0 in self-contained
librdkafka bundles.
Added on_broker_state_change() interceptor
The C++ API no longer returns strings by const value, which enables better move optimization in callers.
Added rd_kafka_sasl_set_credentials() API to update SASL credentials.
Setting allow.auto.create.topics will no longer give a warning if used by a producer, since that is an expected use case.
Improvement in documentation for this property.
Added a resolve_cb configuration setting that permits using custom DNS resolution logic.
Added rd_kafka_mock_broker_error_stack_cnt().
The librdkafka.redist NuGet package has been updated to have fewer external
dependencies for its bundled librdkafka builds, as everything but cyrus-sasl
is now built-in. There are bundled builds with and without linking to
cyrus-sasl for maximum compatibility.
Admin API DescribeGroups() now provides the group instance id
for static members KIP-345 (#3995).

Fixes
General fixes

Windows: couldn't read a PKCS#12 keystore correctly because binary mode
wasn't explicitly set and Windows defaults to text mode.
Fixed memory leak when loading SSL certificates (@Mekk, #3930)
Load all CA certificates from ssl.ca.pem, not just the first one.
Each HTTP request made when using OAUTHBEARER OIDC would leak a small
amount of memory.

Transactional producer fixes

When a PID epoch bump is requested and the producer is waiting
to reconnect to the transaction coordinator, a failure in a find coordinator
request could cause an assert to fail. This is fixed by retrying when the
coordinator is known (#4020).
Transactional APIs (except send_offsets_for_transaction()) that
timeout due to low timeout_ms may now be resumed by calling the same API
again, as the operation continues in the background.
For fatal idempotent producer errors that may be recovered by bumping the
epoch the current transaction must first be aborted prior to the epoch bump.
This is now handled correctly, which fixes issues seen with fenced
transactional producers on fatal idempotency errors.
Timeouts for EndTxn requests (transaction commits and aborts) are now
automatically retried and the error raised to the application is also
a retriable error.
TxnOffsetCommitRequests were retried immediately upon temporary errors in
send_offsets_to_transactions(), causing excessive network requests.
These retries are now delayed 500ms.
If init_transactions() is called with an infinite timeout (-1),
the timeout will be limited to 2 * transaction.timeout.ms.
The application may retry and resume the call if a retriable error is
returned.

Consumer fixes

Back-off and retry JoinGroup request if coordinator load is in progress.
Fix rd_kafka_consume_batch() and rd_kafka_consume_batch_queue() skipping
other partitions' offsets intermittently when seek, pause, resume
or rebalancing is used for a partition.
Fix rd_kafka_consume_batch() and rd_kafka_consume_batch_queue()
intermittently returing incorrect partitions' messages if rebalancing
happens during these operations.

librdkafka v1.9.2
librdkafka v1.9.2 is a maintenance release:

The SASL OAUTHBEAR OIDC POST field was sometimes truncated by one byte (#3192).
The bundled version of OpenSSL has been upgraded to version 1.1.1q for non-Windows builds. Windows builds remain on OpenSSL 1.1.1n for the time being.
The bundled version of Curl has been upgraded to version 7.84.0.

librdkafka v1.9.1
librdkafka v1.9.1 is a maintenance release:

The librdkafka.redist NuGet package now contains OSX M1/arm64 builds.
Self-contained static libraries can now be built on OSX M1 too, thanks to
disabling curl's configure runtime check.

Full diff https://github.com/confluentinc/librdkafka/compare/v1.9.0...v2.0.2

A word of advice here: this release is unstable. Producer crashes due to race conditions, and the consumer has similar problems. I am working with thijsc to sort them out, and I expect a stable beta (and a later non-beta) in a couple of weeks. Unless this is critical to you guys, I would recommend not bumping to this beta.

A word of advice here: this release is unstable. Producer crashes due to race conditions, and the consumer has similar problems. I am working with thijsc to sort them out, and I expect a stable beta (and a later non-beta) in a couple of weeks. Unless this is critical to you guys, I would recommend not bumping to this beta.

Thanks for the heads up @mensfeld  this will just be a beta release to test it out with some of our apps

Hi @deepredsky and @mensfeld, 0.13 is out of beta, could we revive this PR so that we can bump it? (And get cooperative rebalancing)

@MacTynow yes. 0.13 is now stable. It still does not coop on short lived cooperative rebalances (ref https://github.com/appsignal/rdkafka-ruby/issues/254) but aside from that all good.

Some specs are still failing, I will have a closer look next week

https://github.com/zendesk/racecar/pull/339 is fixing the broken spec and also additional changes related to the cooperative-sticky assignment strategy. Closing this PR in favor of that one


frog modularization & testing

Codecov Report
Base: 63.55% // Head: 72.35% // Increases project coverage by +8.79% :tada:

Coverage data is based on head (d3c78f3) compared to base (58c37c1).
Patch coverage: 50.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #43      +/-   ##
==========================================
+ Coverage   63.55%   72.35%   +8.79%
==========================================
  Files          11       14       +3
  Lines         579      539      -40
==========================================
+ Hits          368      390      +22
+ Misses        211      149      -62

Impacted Files
Coverage Δ

src/frog/io.jl
44.44% <44.44%> (ø)

src/frog/report.jl
51.72% <51.72%> (ø)

src/frog/frontend.jl
52.94% <52.94%> (ø)

src/frog/structs.jl
100.00% <100.00%> (ø)

src/memote/reactions.jl
97.67% <0.00%> (-0.29%)
:arrow_down:

src/memote/biomass.jl
100.00% <0.00%> (ø)

src/memote/network.jl
100.00% <0.00%> (ø)

src/memote/annotations.jl
100.00% <0.00%> (ø)

src/memote/metabolites.jl
100.00% <0.00%> (ø)

src/common.jl
79.48% <0.00%> (+0.41%)
:arrow_up:

... and 1 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Updated with some Lithuanian translations

Some translations for Lithuanian language

Hi @lrakauskas! Welcome and thank you for adding these translations! Looks like our build system is a bit confused, but it doesn't look like it has anything to do with your changes. I'll see if I can fix that.
In the meantime, would you be able to go to this link to sign our CLA (Contributor License Agreement)? It just grants us a non-exclusive license to use your contribution and certifies you have the right to contribute the code you submit. For both our sakes, we need this before we can accept a pull request. Don't worry, it's super easy.

Hi. No problem. Signed :)

@codeluggage I've noticed that "lt.coffee" file doesn't contain all translations. I'm looking forward to translate actual levels but can't really find a way to do it via github ? I've found https://codecombat.com/i18n where I can find what seems like Levels but translating it via that webpage would take quite a lot of time since you need to keep reloading page for each translation. Can you suggest any options to translate Levels besides webpage I've mentioned?
I'm really looking forward to level translation as my little brother is starting to use CodeCombat so it's important that he understands all levels and can work unsupervised. Thanks


dico: 2.9 -> 2.10

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/dico/versions.
meta.description for dico is: "Flexible dictionary server and client implementing RFC 2229"
meta.homepage for dico is: "https://www.gnu.org/software/dico/"
meta.changelog for dico is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.10 with grep in /nix/store/v7fmkni2qydagm05vq7ygn364v066ib9-dico-2.10

directory tree listing: https://gist.github.com/d4bcab6a96405dcdbeac9b9a5a0151b1

du listing: https://gist.github.com/1538ab201953a12f046bacebe20f00f9

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
dico

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/v7fmkni2qydagm05vq7ygn364v066ib9-dico-2.10 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A dico https://github.com/r-ryantm/nixpkgs/archive/6b4021489bc92aaebede3bfaa51b227aeacd14d0.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/v7fmkni2qydagm05vq7ygn364v066ib9-dico-2.10
ls -la /nix/store/v7fmkni2qydagm05vq7ygn364v066ib9-dico-2.10/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:

dico

Maintainer pings
cc @lovek323 for testing.

I've tested this, all works well.


Ready for Production

Giving the user an option to ask if we want the files ready for production or development.
This should present the user with

Do you want a production ready Dockerfile.

We should be able to setup two files, either one for production and one for development. (Using .prod)

Refactoring also the folder structure


AzureTest: Replace Environment Variable with Configuration File

Currently we are using environment variables defined in a particular test scheme to control the recording mechanism. This is problematic since one could accidentally commit real values for these variables, which we do not want. Instead, we should load a configuration file and access necessary settings to control the recording in that way.

This might be helpful in this effort:
https://github.com/417-72KI/BuildConfig.swift
Another suggestion from Victor, having a dedicated plist to contain these values that is in gitignore.

PR #924 merged, so this is done.


HTTP Response codes

Pin sends back HTTP response codes, some of these indicate errors. Is it possible to retrieve these response codes using your library?

Buzz will always return an object regardless of the outcome. Therefore $service->submit($request) will always return something, without exception or warnings.
I thought about adding some validation to ensure its a JSON response but frankly the response side of things is up to the end user. The library just helps with request building and transport.


Chore/exception compatibility

Description of Change

removes Py42UserNotFoundError. This would be a breaking change for situations where a username did not exist (normally an empty list is returned).
makes Py42UserAlreadyAddedError an instance of Py42BadRequestError in order to make exception handling backwards compatible.
makes Py42LegalHoldNotFoundOrPermissionDeniedError an instance of Py42ForbiddenError in order to make exception handling backwards compatible.

Codecov Report

Merging #180 into master will decrease coverage by 0.33%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #180      +/-   ##
==========================================
- Coverage   92.76%   92.43%   -0.34%
==========================================
  Files          59       59
  Lines        2253     2246       -7
==========================================
- Hits         2090     2076      -14
- Misses        163      170       +7

Impacted Files
Coverage Δ

src/py42/exceptions.py
95.16% <100.00%> (-0.23%)
:arrow_down:

src/py42/services/users.py
77.27% <100.00%> (-1.30%)
:arrow_down:

src/py42/_compat.py
61.11% <0.00%> (-38.89%)
: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 765dee5...89e429f. Read the comment docs.

The changes seem fine. Need change log for breaking change.

Oh yeah.  This isn't released, but the CHANGELOG needs to be amended to get rid of the User exception one.

We could potentially leave User Does Not Exists Exception and just import it other places... There is a strong chance we will need this exception in more places than just the CLI.

It doesn't make much sense to me to have Py42 define exceptions that it does not raise - I have never imported an exception from a library to raise it, just to catch it.
Thanks for the reminder to edit the change log, I'll do that this morning


Xaml Islands, ms-settings with WPF app as admin mode won't launch

Describe the bug

Steps to reproduce the bug

Steps to reproduce the behavior:

Create an application with a XAML island v1
Have a Hyperlink to ms-settings:colors
launch application under admin

Expected behavior

Colors launches, with a pure WPF implementation, this works as expected
Screenshots

Version Info

NuGet package version:
[Microsoft.UI.Xaml.2.5.0-prerelease.200923002]

Windows app type:

UWP
Win32

Yes

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2020 Update (19041)
Yes

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context

https://github.com/microsoft/PowerToys/issues/7819 for finding issue

@chrisglein @MikeHillberg  I remember there was some issue with launching from hyperlink inside a XAML island, but fail to recollect it.

Believe that the launch APIs may have assumptions about package identity, so Hyperlink may have issues outside of that context?
We have an existing issue report on this.
Duplicate of #2357.


house

Repro steps:

Action: appService.Deploy
Error type: Error
Error Message: "NereidYan" is connected to a GitHub repository. Push to GitHub repository to deploy.
Version: 0.13.0
OS: win32
VS Code Version: 1.32.3

Call Stack
Object.<anonymous> (dist/extension.bundle.js:277:3372352)
Generator.next (<anonymous>)
module.exports.n (dist/extension.bundle.js:277:3370987)
new Promise (<anonymous>)
module.exports.n (dist/extension.bundle.js:277:3370764)
module.exports.t.deploy.i.window.withProgress (dist/extension.bundle.js:277:3372215)
c._withProgress (c:/BuildschoolHtml/Microsoft VS extensionHostProcess.js:422:75)
c.withProgress (c:/BuildschoolHtml/Microsoft VS extensionHostProcess.js:421:836)
Object.withProgress (c:/BuildschoolHtml/Microsoft VS extensionHostProcess.js:674:269)
Object.<anonymous> (dist/extension.bundle.js:277:3372058)
Generator.next (<anonymous>)
o (dist/extension.bundle.js:277:3370820)
process._tickCallback (internal/process/next_tick.js:68:7)

Hi @NereidYan,
If your app is connected to a GitHub repo, then you can push changes to that repo and your web-app will pick up those changes automatically.  No deployments necessary! :)
If this is not your issue, please let me know.


Improve Test Coverage for dojo-core

Improve Test Coverage for dojo-core
Issue Overview
The dojo-core crate could benefit from enhanced test coverage. Writing more tests will not only ensure stability and reliability but also provide contributors with a better understanding of the codebase.
Affected Component
dojo-core
Desired Outcome
Boost the test coverage for the dojo-core crate.
Improve understanding of the crate's functionalities and mechanics for contributors.

Reference
For reference on integration testing, especially with Rust code, consider the following example from the torii client:
system_test.rs#L13
Copy of https://github.com/dojoengine/dojo/issues/850

Fixed by https://github.com/dojoengine/dojo/pull/871


Create test_builder.py

We need a unit test suite for builder.py, which currently has only ~25% coverage.

This is largely fixed, coverage is now around 86%.

Coverage is currently around 86% and the builder is well tested by the SBML/BNGL importers. Closing this issue.


Version 2.6.0 cannot use custom API endpoint and custom script name

Describe the Bug
I don't know if it's because of the deployment of umami to fly.io, the custom interface and custom script name of the 2.6.0 version can't be used normally, but both of them can work normally in the 2.5.0 version.
Environment introduction:
umami access domain name: tg.123.cn
COLLECT_API_ENDPOINT = "/api/59qrTtdFFrV"
TRACKER_SCRIPT_NAME = "PGmXAF3tDjvN9"

Insert umami on the website to be counted
  src="//js.123.fun/um/PGmXAF3tDjvN9.js"
  data-website-id="ID"
  data-host-url="https://tg.123.cn"

It can be used normally in umami 2.5.0 version
Troubleshoot
Accessing https://tg.123.cn/script.js is normal, accessing https://tg.123.cn/PGmXAF3tDjvN9.js prompts 404,
Visit the website with a browser (chrome F12-network), js.123.fun/um/PGmXAF3tDjvN9.js has been loaded normally, https://tg.123.cn/api/59qrTtdFFrV prompt 404
Back to version 2.5.0, except for visiting https://tg.123.cn/PGmXAF3tDjvN9.js404, umami can count normally.
Database
PostgreSQL
Relevant log output
2023-08-30T05:51:19.652 app[4d89440be57587] nrt [info] - ready started server on <IP_ADDRESS>:8080, url: http://localhost:8080

2023-08-30T05:59:51.791 app[4d89440be57587] nrt [info] TypeError: Cannot destructure property 'url' of 'payload' as it is undefined.

2023-08-30T05:59:51.791 app[4d89440be57587] nrt [info] at __WEBPACK_DEFAULT_EXPORT__ (/app/.next/server/pages/api/send.js:502:13)

2023-08-30T05:59:51.791 app[4d89440be57587] nrt [info] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

2023-08-30T06:00:03.897 app[4d89440be57587] nrt [info] TypeError: Cannot destructure property 'url' of 'payload' as it is undefined.

2023-08-30T06:00:03.897 app[4d89440be57587] nrt [info] at __WEBPACK_DEFAULT_EXPORT__ (/app/.next/server/pages/api/send.js:502:13)

2023-08-30T06:00:03.897 app[4d89440be57587] nrt [info] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Which browser are you using? (if relevant)
Chrome
How are you deploying your application? (if relevant)
Fly.io，Docker

Same issue, TRACKER_SCRIPT_NAME is ignored on ghcr.io/umami-software/umami:postgresql-v2.6.0. Reverted to 2.5.0.

+1

@aaro-n I might not be following exactly what is going on in your explanation. But I think the TRACKER_SCRIPT_NAME no longer automatically appends .js. So your website src should exactly match the TRACKER_SCRIPT_NAME.
e.g. TRACKER_SCRIPT_NAME = "PGmXAF3tDjvN9"
src="//js.123.fun/um/PGmXAF3tDjvN9"

@saschwarz Remove .js from the src item, that is, src="//js.123.fun/um/PGmXAF3tDjvN9", access to https://tg.123.cn/api/59qrTtdFFrV will still result in 404, access https://tg.123.cn/api/send displays Internal Server Error, log
2023-08-30T23:09:31.922 app[4d89440be57587] nrt [info] TypeError: Cannot destructure property 'url' of 'payload' as it is undefined.

2023-08-30T23:09:31.922 app[4d89440be57587] nrt [info] at __WEBPACK_DEFAULT_EXPORT__ (/app/.next/server/pages/api/send.js:502:13)

2023-08-30T23:09:31.922 app[4d89440be57587] nrt [info] at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Umami returns to version 2.5.0, visit https://tg.123.cn/api/send and https://tg.123.cn/api/59qrTtdFFrV both show Invalid payload., no error log

2.6.0
2023-08-30T23:16:24.945 runner[4d89440be57587] nrt [info] Pulling container image ghcr.io/umami-software/umami:postgresql-latest

2023-08-30T23:16:25.574 runner[4d89440be57587] nrt [info] Successfully prepared image ghcr.io/umami-software/umami:postgresql-latest (628.847169ms)

2023-08-30T23:16:25.936 runner[4d89440be57587] nrt [info] Configuring firecracker

2023-08-30T23:16:26.112 app[4d89440be57587] nrt [info] INFO Sending signal SIGINT to main child process w/ PID 265

2023-08-30T23:16:26.771 app[4d89440be57587] nrt [info] INFO Main child exited with signal (with signal 'SIGINT', core dumped? false)

2023-08-30T23:16:26.771 app[4d89440be57587] nrt [info] INFO Starting clean up.

2023-08-30T23:16:26.771 app[4d89440be57587] nrt [info] WARN hallpass exited, pid: 266, status: signal: 15 (SIGTERM)

2023-08-30T23:16:26.772 app[4d89440be57587] nrt [info] 2023/08/30 23:16:26 listening on [fdaa:0:6f3f:a7b:d86c:69d9:3c7c:2]:22 (DNS: [fdaa::3]:53)

2023-08-30T23:16:27.761 app[4d89440be57587] nrt [info] [ 334.760070] reboot: Restarting system

2023-08-30T23:16:28.256 app[4d89440be57587] nrt [info] [ 0.041354] PCI: Fatal: No config space access function found

2023-08-30T23:16:28.471 app[4d89440be57587] nrt [info] INFO Starting init (commit: 5293a085)...

2023-08-30T23:16:28.546 app[4d89440be57587] nrt [info] INFO Preparing to run: `docker-entrypoint.sh yarn start-docker` as nextjs

2023-08-30T23:16:28.556 app[4d89440be57587] nrt [info] INFO [fly api proxy] listening at /.fly/api

2023-08-30T23:16:28.559 app[4d89440be57587] nrt [info] 2023/08/30 23:16:28 listening on [fdaa:0:6f3f:a7b:d86c:69d9:3c7c:2]:22 (DNS: [fdaa::3]:53)

2023-08-30T23:16:29.107 app[4d89440be57587] nrt [info] yarn run v1.22.19

2023-08-30T23:16:29.167 app[4d89440be57587] nrt [info] $ npm-run-all check-db update-tracker start-server

2023-08-30T23:16:29.866 app[4d89440be57587] nrt [info] $ node scripts/check-db.js

2023-08-30T23:16:29.996 app[4d89440be57587] nrt [info] ✓ DATABASE_URL is defined.

2023-08-30T23:16:30.209 app[4d89440be57587] nrt [info] ✓ Database connection successful.

2023-08-30T23:16:30.314 app[4d89440be57587] nrt [info] ✓ Database version check successful.

2023-08-30T23:16:31.507 app[4d89440be57587] nrt [info] Prisma schema loaded from prisma/schema.prisma

2023-08-30T23:16:31.507 app[4d89440be57587] nrt [info] Datasource "db": PostgreSQL database "postgres", schema "public" at "db.xxxxxx.supabase.co:6543"

2023-08-30T23:16:31.507 app[4d89440be57587] nrt [info] 3 migrations found in prisma/migrations

2023-08-30T23:16:31.507 app[4d89440be57587] nrt [info] No pending migrations to apply.

2023-08-30T23:16:31.507 app[4d89440be57587] nrt [info] ✓ Database is up to date.

2023-08-30T23:16:31.752 app[4d89440be57587] nrt [info] $ node scripts/update-tracker.js

2023-08-30T23:16:31.813 app[4d89440be57587] nrt [info] Updated tracker endpoint: /api/59qrTtdFFrV.

2023-08-30T23:16:32.096 app[4d89440be57587] nrt [info] $ node server.js

2023-08-30T23:16:32.543 app[4d89440be57587] nrt [info] - ready started server on <IP_ADDRESS>:8080, url: http://localhost:8080

2.5.0
2023-08-30T23:18:44.427 runner[4d89440be57587] nrt [info] Pulling container image ghcr.io/umami-software/umami@sha256:5fc95115445ff5c5a16f86637f743b0b184fc9f4995381d75299ed92fe22328b

2023-08-30T23:18:45.132 runner[4d89440be57587] nrt [info] Successfully prepared image ghcr.io/umami-software/umami@sha256:5fc95115445ff5c5a16f86637f743b0b184fc9f4995381d75299ed92fe22328b (705.330921ms)

2023-08-30T23:18:45.475 runner[4d89440be57587] nrt [info] Configuring firecracker

2023-08-30T23:18:45.658 app[4d89440be57587] nrt [info] INFO Sending signal SIGINT to main child process w/ PID 265

2023-08-30T23:18:45.732 app[4d89440be57587] nrt [info] INFO Main child exited with signal (with signal 'SIGINT', core dumped? false)

2023-08-30T23:18:45.732 app[4d89440be57587] nrt [info] INFO Starting clean up.

2023-08-30T23:18:45.742 app[4d89440be57587] nrt [info] WARN hallpass exited, pid: 266, status: signal: 15 (SIGTERM)

2023-08-30T23:18:45.748 app[4d89440be57587] nrt [info] 2023/08/30 23:18:45 listening on [fdaa:0:6f3f:a7b:d86c:69d9:3c7c:2]:22 (DNS: [fdaa::3]:53)

2023-08-30T23:18:46.735 app[4d89440be57587] nrt [info] [ 138.518250] reboot: Restarting system

2023-08-30T23:18:47.214 app[4d89440be57587] nrt [info] [ 0.039665] PCI: Fatal: No config space access function found

2023-08-30T23:18:47.431 app[4d89440be57587] nrt [info] INFO Starting init (commit: 5293a085)...

2023-08-30T23:18:47.495 app[4d89440be57587] nrt [info] INFO Preparing to run: `docker-entrypoint.sh yarn start-docker` as nextjs

2023-08-30T23:18:47.506 app[4d89440be57587] nrt [info] INFO [fly api proxy] listening at /.fly/api

2023-08-30T23:18:47.508 app[4d89440be57587] nrt [info] 2023/08/30 23:18:47 listening on [fdaa:0:6f3f:a7b:d86c:69d9:3c7c:2]:22 (DNS: [fdaa::3]:53)

2023-08-30T23:18:48.045 app[4d89440be57587] nrt [info] yarn run v1.22.19

2023-08-30T23:18:48.096 app[4d89440be57587] nrt [info] $ npm-run-all check-db update-tracker start-server

2023-08-30T23:18:48.760 app[4d89440be57587] nrt [info] $ node scripts/check-db.js

2023-08-30T23:18:48.886 app[4d89440be57587] nrt [info] ✓ DATABASE_URL is defined.

2023-08-30T23:18:49.047 app[4d89440be57587] nrt [info] ✓ Database connection successful.

2023-08-30T23:18:49.141 app[4d89440be57587] nrt [info] ✓ Database version check successful.

2023-08-30T23:18:50.222 app[4d89440be57587] nrt [info] Prisma schema loaded from prisma/schema.prisma

2023-08-30T23:18:50.222 app[4d89440be57587] nrt [info] Datasource "db": PostgreSQL database "postgres", schema "public" at "db.xxx.supabase.co:6543"

2023-08-30T23:18:50.222 app[4d89440be57587] nrt [info] 3 migrations found in prisma/migrations

2023-08-30T23:18:50.222 app[4d89440be57587] nrt [info] No pending migrations to apply.

2023-08-30T23:18:50.222 app[4d89440be57587] nrt [info] ✓ Database is up to date.

2023-08-30T23:18:50.486 app[4d89440be57587] nrt [info] $ node scripts/update-tracker.js

2023-08-30T23:18:50.547 app[4d89440be57587] nrt [info] Updated tracker endpoint: /api/59qrTtdFFrV.

2023-08-30T23:18:50.815 app[4d89440be57587] nrt [info] $ node server.js

2023-08-30T23:18:51.265 app[4d89440be57587] nrt [info] Listening on port 8080 url: http://<IP_ADDRESS>:8080

2.5 and 2.6 environment variables are the same

Environment variables:
  APP_SECRET = "xxxxxx"
  CLIENT_IP_HEADER = "x-forwarded-for"
  COLLECT_API_ENDPOINT = "/api/59qrTtdFFrV"
  DATABASE_URL = "postgres://postgres:xxxx@db.zzzzzz.supabase.co:6543/postgres?pgbouncer=true"
  DISABLE_UPDATES = "1"
  FORCE_SSL = "1"
  PORT = "8080"
  TRACKER_SCRIPT_NAME = "PGmXAF3tDjvN9"
  HOSTNAME = "<IP_ADDRESS>"

  DEFAULT_LOCALE = "zh-CN"

Fixed in v2.6.2.

The 2.6.2 version has fixed the problem and the problem is closed


(#317) - Add allow_persistent_cookies config

Why:
To have an easy way of persisting user's session
What:
Implement allow_persistent_cookies setting from CouchDB (https://github.com/apache/couchdb/blob/817b2b6f5f0883092df60c1ec8ec7ec6d6094a23/src/couch/src/couch_httpd_auth.erl#L443)
I couldn't find any tests responsible for the actual cookies. Maybe you can point me into the right direction?

Thanks for your pull request. Sorry for getting to this only now. This looks good! I'm happy to merge this, provided it passes the test suite. If you could rebase it against the latest master, that should fix the current Travis errors.
I don't think there aren't any cookie-specific tests, if you want to add some that would be great, but I'm happy to take this as-is.

Thanks!


Travis CI Setup

The codebase for datamined is growing large enough that we should start running continuous integration tests. The simplest way to do this is likely through Travis CI.

Activated datamined on Travis-CI, but haven't yet integrated tests.


nodeinit.restartPods=true isn't working on GKE

{
textPayload: "find: '/var/lib/cni/networks/': No such file or directory
"
resource: {
type: "k8s_container"
labels: {
project_id: "xxxxx"
location: "xxxxxx"
pod_name: "cilium-node-init-rqzcf"
cluster_name: "gke-cluster-xxxxx"
namespace_name: "cilium"
container_name: "node-init"
}
}
timestamp: "2021-03-02T12:25:46.033791028Z"
severity: "ERROR"
labels: {
k8s-pod/app: "cilium-node-init"
k8s-pod/pod-template-generation: "1"
k8s-pod/controller-revision-hash: "xxxxx"
compute.googleapis.com/resource_name: "gke-xxxxxx"
}
logName: "projects/xxxxxxx/logs/stderr"
receiveTimestamp: "2021-03-02T12:25:55.026224571Z"
}

Cilium version: 1.9.0
GKE version: 1.17.15-gke.800

Create a GKE cluster
Install Cilium with nodeinit.restartPods=true

helm install --wait --timeout 300s cilium cilium/cilium --version 1.9.0 --namespace cilium --set nodeinit.enabled=true --set nodeinit.reconfigureKubelet=true --set nodeinit.removeCbrBridge=true --set nodeinit.restartPods=true --set cni.binPath=/home/kubernetes/bin --set gke.enabled=true --set ipam.mode=kubernetes --set nativeRoutingCIDR=$(gcloud container clusters describe gke-cluster-xxx --zone xxxxxx --format 'value(clusterIpv4Cidr)') --set kubeProxyReplacement=disabled --set hubble.listenAddress=':4244'  --set hubble.relay.enabled=true --set hubble.ui.enabled=true

gcloud container clusters resize gke-cluster-xxxx --node-pool gke-cluster-cbugscaleup-node-pool --num-nodes 0
wait until all pods terminate
gcloud container clusters resize gke-cluster-xxxx --node-pool gke-cluster-cbugscaleup-node-pool --num-nodes 1
"find: '/var/lib/cni/networks/': No such file or directory during node startup

So, everytime that I need to do resize nodes I need to manually restart unmanaged pods.

Thanks for filing the issue. I took a look at this and I was able to reproduce it with the latest version of Cilium as well (v1.9.5).
Strangely enough though, that directory does exist. If I do an ls /var/lib/cni/networks/ before the find, it works. It seems like GKE is lazily mounting this path on first access. I don't know if that's what's happening for a fact, but it's behaving as such.

Could you try applying this diff and see if that resolves it for you?
diff --git a/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml b/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml
index 50cd92ba2..db98ad10c 100644
--- a/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml
+++ b/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml
@@ -225,6 +225,12 @@ spec:
               if [ ! -f /etc/crictl.yaml ] || grep -q 'docker' /etc/crictl.yaml; then
                 # Works for COS, ubuntu
                 # Note the first line is the containerID with a trailing \r
+                set +e
+                until [[ -d /var/lib/cni/networks ]]; do
+                  echo "waiting for /var/lib/cni/networks..."
+                  sleep 3s
+                done
+                set -e
                 for f in `find /var/lib/cni/networks/ -type f ! -name lock ! -name last_reserved_ip.0`; do docker rm -f "$(sed 's/\r//;1q' $f)" || true; done
               elif [ -n "$(docker ps --format '{{ "{{" }}.Image{{ "}}" }}' | grep ^[0-9]*\.dkr\.ecr\.[a-z]*-[a-z]*-[0-9]*\.amazonaws\.com/amazon-k8s-cni)" ]; then
                 timeout=1

Hitting this as well.
@christarazi using the loop waiting for /var/lib/cni/networks works! Unfortunately there is another race condition, as not all files/containers under /var/lib/cni/networks/ may be present when the ... docker rm -f ... runs. An infinite loop solves this (see patch below), but it also means that the script is stuck here (so the restartPods functionality must be at the end of the node-init script if this approach is used). Using this script, we eventually get no Cilium unmanaged nodes (even in the extreme scenario of scaling all nodes to 0 and then scaling up again).
Sometimes Cilium is faster than GKE (so that we don't have Cilium unmanaged Pods), and then the script ends up looping on "waiting for /var/lib/cni/networks...". Other times GKE is faster than Cilium (so that we do have Cilium unmanaged Pods), and then the script ends up looping on "Cleaning up Cilium unmanaged Pods..." instead.
Seems like entries under /var/lib/cni/networks are propagated (e.g. we get Cilium unmanaged Pods) until the cilium-agent on the node is up and running. So it's also important that enough resources are reserved for the cilium-agents, otherwise it may take a long time as it competes with other workloads (being constantly restarted by the node-init script) for resources.
diff --git a/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml b/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml
index 50cd92ba2..7a3d0e940 100644
--- a/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml
+++ b/install/kubernetes/cilium/templates/cilium-nodeinit-daemonset.yaml
@@ -224,8 +224,22 @@ spec:
               echo "Restarting kubenet managed pods"
               if [ ! -f /etc/crictl.yaml ] || grep -q 'docker' /etc/crictl.yaml; then
                 # Works for COS, ubuntu
-                # Note the first line is the containerID with a trailing \r
-                for f in `find /var/lib/cni/networks/ -type f ! -name lock ! -name last_reserved_ip.0`; do docker rm -f "$(sed 's/\r//;1q' $f)" || true; done
+                set +e
+                until [[ -d /var/lib/cni/networks ]]; do
+                  echo "waiting for /var/lib/cni/networks..."
+                  sleep 3s
+                done
+                set -e
+                while :; do
+                  echo "Cleaning up Cilium unmanaged Pods..."
+                  # Note the first line is the containerID with a trailing \r
+                  for f in `find /var/lib/cni/networks/ -type f ! -name lock ! -name last_reserved_ip.0`; do
+                    docker rm -f "$(sed 's/\r//;1q' $f)" || true
+                    rm -f "$f"
+                  done
+                  echo "Cleaning up Cilium unmanaged Pods done"
+                  sleep 10s
+                done
               elif [ -n "$(docker ps --format '{{ "{{" }}.Image{{ "}}" }}' | grep ^[0-9]*\.dkr\.ecr\.[a-z]*-[a-z]*-[0-9]*\.amazonaws\.com/amazon-k8s-cni)" ]; then
                 timeout=1
                 for i in $(seq 1 7); do

@splushii Thanks for the detailed write-up. Would you mind opening a PR with that patch? We can figure out a solution to resolve the infinite loop problem during the review process.

@christarazi @splushii
I have noticed the same issue and have been testing a patch for this which seems to be pretty effective. I opted to add a wait in before the pods are restarted that checks if the cilium agent is ready by curling the socket it deploys. While cilium agent is unavailable the curl command times out and returns a non 0 exit code, once the socket is available the curl returns a zero exit code and allows the script to continue to restart the pods:
{{- if .Values.nodeinit.restartPods }}
{{- if .Values.nodeinit.waitForCiliumAgent }}
              echo "Waiting for cilium agent to be ready"
              set +e
              curl -X GET --unix-socket /run/cilium/cilium.sock http://localhost/healthz 1>/dev/null 2>/dev/null
              while [ $? -ne 0 ]; do
                sleep 1
                curl -X GET --unix-socket /run/cilium/cilium.sock http://localhost/healthz 1>/dev/null 2>/dev/null
              done
              set -e
              echo "Cilium agent ready"
{{- end }}
...restart logic...
{{- end }}

I thought it best to make this optional by the helm chart value nodeinit.waitForCiliumAgent .
There is one drawback, curling the current endpoint returns a 404 once the actual socket is available, maybe someone with some more knowledge about this could get it to return 200, then we can ensure that the health of the agent is good before continuing.

@aanm is working on a PR to fix #16602 which mostly deprecate the use of nodeinit so this issue is likely to be resolved once the PR is up.


Refactored to use upcoming EventManager v3

Updates all code to work with the upcoming v3 of EventManager. In particular:

Updated the EventManager factory to inject the SharedEventManager at instantiation, if that service is present.
Updated the EventManager initializer to inject not only if no EM instance is present, but also if the current EM instance has no shared manager present.  The latter is a good indication that the EM instance was lazy-loaded by the getter.
Updated the Application constructor to pass arguments. This was necessary due to a strange circular dependency with the changes to the initializer. It's also better DI.
Fixed all attachAggregate() calls to use $aggregate->attach(), and ensured there were no calls to $events->attach() that were attaching aggregates.
Reviewed all trigger() calls for appropriate signatures, updating those that needed it. In many cases, an additional call to $event->setName() was also required.

This can likely be merged to develop sooner rather than later, as it represents a work-in-progress towards the updated MVC.

Pinging @zendframework/community-review-team and @ezimuel — would love some review. :smile:

Feedback incorporated, @Ocramius :smile:

Bah, CS checks! Fixed and pushed.

Thanks @weierophinney!

Added a migration guide covering the BC breaks introduced, and updated the branch-alias for the develop branch to 3.0-dev.

Okay, merging. If anybody finds anything else wrong, please open an issue or PR and ping me. :smile:


HDDS-2072. Make StorageContainerLocationProtocolService message based

It depends on HDDS-2067

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
74
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ HDDS-2067 Compile Tests _

0
mvndep
77
Maven dependency ordering for branch

-1
mvninstall
37
hadoop-hdds in HDDS-2067 failed.

-1
mvninstall
31
hadoop-ozone in HDDS-2067 failed.

-1
compile
20
hadoop-hdds in HDDS-2067 failed.

-1
compile
15
hadoop-ozone in HDDS-2067 failed.

+1
checkstyle
64
HDDS-2067 passed

+1
mvnsite
0
HDDS-2067 passed

+1
shadedclient
881
branch has no errors when building and testing our client artifacts.

-1
javadoc
24
hadoop-hdds in HDDS-2067 failed.

-1
javadoc
19
hadoop-ozone in HDDS-2067 failed.

0
spotbugs
981
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
32
hadoop-hdds in HDDS-2067 failed.

-1
findbugs
20
hadoop-ozone in HDDS-2067 failed.

_ Patch Compile Tests _

0
mvndep
30
Maven dependency ordering for patch

-1
mvninstall
35
hadoop-hdds in the patch failed.

-1
mvninstall
29
hadoop-ozone in the patch failed.

-1
compile
25
hadoop-hdds in the patch failed.

-1
compile
19
hadoop-ozone in the patch failed.

-1
cc
25
hadoop-hdds in the patch failed.

-1
cc
19
hadoop-ozone in the patch failed.

-1
javac
25
hadoop-hdds in the patch failed.

-1
javac
19
hadoop-ozone in the patch failed.

+1
checkstyle
57
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
728
patch has no errors when building and testing our client artifacts.

-1
javadoc
22
hadoop-hdds in the patch failed.

-1
javadoc
20
hadoop-ozone in the patch failed.

-1
findbugs
31
hadoop-hdds in the patch failed.

-1
findbugs
21
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
30
hadoop-hdds in the patch failed.

-1
unit
23
hadoop-ozone in the patch failed.

+1
asflicense
34
The patch does not generate ASF License warnings.

2528

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1514

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle cc

uname
Linux c25bb08450ee 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
HDDS-2067 / 63c730a

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-compile-hadoop-ozone.txt

cc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-compile-hadoop-hdds.txt

cc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/testReport/

Max. process+thread count
400 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-hdds/server-scm hadoop-ozone/insight U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/2/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
1
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

0
mvndep
27
Maven dependency ordering for branch

-1
mvninstall
30
hadoop-hdds in trunk failed.

-1
mvninstall
24
hadoop-ozone in trunk failed.

-1
compile
20
hadoop-hdds in trunk failed.

-1
compile
16
hadoop-ozone in trunk failed.

+1
checkstyle
50
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
852
branch has no errors when building and testing our client artifacts.

-1
javadoc
22
hadoop-hdds in trunk failed.

-1
javadoc
19
hadoop-ozone in trunk failed.

0
spotbugs
950
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
31
hadoop-hdds in trunk failed.

-1
findbugs
20
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

0
mvndep
29
Maven dependency ordering for patch

-1
mvninstall
33
hadoop-hdds in the patch failed.

-1
mvninstall
29
hadoop-ozone in the patch failed.

-1
compile
24
hadoop-hdds in the patch failed.

-1
compile
19
hadoop-ozone in the patch failed.

-1
cc
24
hadoop-hdds in the patch failed.

-1
cc
19
hadoop-ozone in the patch failed.

-1
javac
24
hadoop-hdds in the patch failed.

-1
javac
19
hadoop-ozone in the patch failed.

+1
checkstyle
57
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
715
patch has no errors when building and testing our client artifacts.

-1
javadoc
21
hadoop-hdds in the patch failed.

-1
javadoc
20
hadoop-ozone in the patch failed.

-1
findbugs
31
hadoop-hdds in the patch failed.

-1
findbugs
20
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
27
hadoop-hdds in the patch failed.

-1
unit
24
hadoop-ozone in the patch failed.

+1
asflicense
34
The patch does not generate ASF License warnings.

2375

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1514

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle cc

uname
Linux 0f43c2168b06 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 1a2a352

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-compile-hadoop-ozone.txt

cc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-compile-hadoop-hdds.txt

cc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/testReport/

Max. process+thread count
438 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-hdds/server-scm hadoop-ozone/insight U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1514/3/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

I have rebased and committed this change. Thank you for the contribution.


Removed prometheus and certmanager crd's

Removed the obsolete Prometheus crd and replaced cert-manager crd copy with optional helm chart dependency.

This PR is great!
Please add helm dependency update into the installation guide and our e2e CI system.

@wonderflow Unfortunately this was not as straightforward as I thought. When using the cert-manager helm chart as dependency, the crd's are still missing, when kubevela tries to create the Issuer and it fails.
It seems, that's because the crd's from cert-manager are provided by normal helm templates instead in the crds folder.
We could just addthe manual install of the certmanager crds to the documentation? Or automate that with a Job and a helm pre-install hook, to install the certmanager crds?

Or automate that with a Job and a helm pre-install hook, to install the certmanager crds?

Is that possible? this would be the best solution. If one user try install kubevela helm chart with webhook enabled, we should check there MUST have a cert-manager installed. If not, we should fail the installation.

Unfortunately the idea with the helm pre-install hook didn't work neither. It feels all my changes made it worse, so I will close this PR, maybe there are better solutions in the future.

@hprotzek  It seems this PR is very important as we still conflict with the cluster which has the existing cert-manager CRD installed?

that's because the crd's from cert-manager are provided by normal helm templates instead in the crds folder.

Can I ask why ？ If the cert-manager is installed, the crd in its template will still be there and the vela-core shouldn't fail?

@wonderflow The problem is, when cert-manager is not installed and helm tries to install it as a dependency, the cert-manager crd's are not available when kubevela tries to render the Issuer and Certificate resources.
I had a look at the prometheus operator helm chart, as they also use cert-manager for the webhook. There they don't install cert-manager as a helm dependency, you need to install it before manually. But they are using kube-webhook-certgen as a default (if cert-manager is not installed) to generate the self signed certs. We could use the same mechanism also for kubevela?

@hprotzek  Sure I think that works for KubeVela.

issue refer to #1035

sorry it took so long, I will look into this today :-)

@wonderflow I have now a working version without the helm crd's from Prometheus and Certmanager.
If no Certmanager is installed, a helm hook will generate and setup a self signed cert (https://github.com/jet/kube-webhook-certgen).
If the Certmanager is installed, then the old setup is used, but the Certmanager must be installed manually before Kubevela.
But during the e2e tests I saw, that the cli is using the certmanager to create certs. Not sure about this functionality and if then the version without Certmanager makes sense at all?

@wonderflow I have now a working version without the helm crd's from Prometheus and Certmanager.
If no Certmanager is installed, a helm hook will generate and setup a self signed cert (https://github.com/jet/kube-webhook-certgen).
If the Certmanager is installed, then the old setup is used, but the Certmanager must be installed manually before Kubevela.
But during the e2e tests I saw, that the cli is using the certmanager to create certs. Not sure about this functionality and if then the version without Certmanager makes sense at all?

You can change the e2e test to use the self signed certificate instead of cert-manager

@hprotzek  Hi, can you help fix the final comment so we can merge this PR, thanks

Great Job


⚠ SOAP Platform has degraded performance

In aa1f51f, SOAP Platform (https://soap.six-group.com/healthcheck) experienced degraded performance:

HTTP code: 503
Response time: 20891 ms

Resolved: SOAP Platform performance has improved in 2e23b50.


Metadata and data loading checks documentation

Description:
As a developer, I want to have documentation for metadata and data loading check to ensure correct loading
Jira ticket PDXI-832
Acceptance criteria:

[ ] documentation agreed on and available on GDrive

to collectively define that the dataset loaded correctly

@Afollet @CsabaHalmagyi this sounds like validation checks to me? would you consider this a duplicate of https://github.com/PDXFinder/pdxfinder/issues/284?

No, this is for a document that guides an individual to the procedures of loading data. Like which steps a person should take to consider a data set successfully validated and loaded into the PdxFinder. The other document is for validation rules for the validation service. One document is for the human processes the other is for machine processes, IMO

I see, thanks @Afollet

this is now obsolete. closing


Probably incrorrect letter case in filenames make bundlers duplicating modules.

** I want report a some like bug **
Probably incrorrect letter case in filenames make bundlers duplicating modules and work all library is failed.
I faced with problem, when webpack and rollup duplicates modules.
I am working on Windows. She is not make it differece between low and up case letters in filenames. For she 'File.js' and 'file.js' are one entity. But Unix-like systems recognize they as two diffirent entities. And bundlers (webpack, rollup) also do. Let you are working on Windows, and you make two 'import' operations, in the one you write from 'File.js', in the second you write 'file.js'. Both are reffered to same file. However bunlers make two copy of this module.
I made all filenames and statement 'import from' to low case, and problem vanished. It is truth for Webpack. I don't try with rollup yet.
Probably could make some sort of option for show warning about possibily making duplicate modules or option for ignore case in filenames, i don't know.
Sorry for bothering you, if my issue happen usesless.

You need to make sure of case,..
This is not just a webpack issue, it would also be the case of Node.js on a windows machine.   It might appear it's working, but if you say did    require('config'); and require('Config');, node.js would load them twice, and in some cases this could be problematic.
For this reason, what most javascript / node.js developers do is always use lowercase, and dashes.
IOW: always avoid using require with any upper case characters.

Probably could make some sort of option for show warning about possibily making duplicate modules or option for ignore case in filenames, i don't know.

Are you using the latest webpack, I'm pretty sure it already shows a warning..

i don't used require, i used import directive from new lang standard. Bundler simple load and copy this module, and wrap it in some like function. In result, bundler create two copy of one module with different names, which it create appending dollar sign. And system breaks.
yes, webpack shows warning. But it message something like 'this may have problem on some operation system'. Not that thing, are i'm waiting.

This is not just a webpack issue, it would also be the case of Node.js on a windows machine.

yes, webpack shows warning.


[Impeller] Command::viewport and Command::scissor are only used in tests.

These objects are only ever set for the ImGui backend used in playgrounds:
https://github.com/flutter/engine/blob/9fae689d10a9fc7615b9b185172b1bed5c8d40a1/impeller/playground/imgui/imgui_impl_impeller.cc#L245-L246
They contribute sizeof(Rect) * 2 to the size of command objects. We should remove them if they're really only useful for ImGui, or use them if they'd be useful elsewhere.
@bdero WDYT?
@gaaclarke fyi

I raised this the other day and Jonah made the point that these are going to be surfaced in Dart GPU at some point?

That makes it sound like we should be using them in the actual implementations then because they're somehow useful.
I guess a third possibility is that they're only useful in some cases, and right now we only cover those cases in tests, but I'd like to better understand that if it's the case.

Both are ubiquitous features in graphics standards/HALs. The scissor test can be used for free rectangle clipping by many renderers (no stencil traffic!), and adjusting the viewport can absorb transform churn in some situations.
In multi-camera scenarios (like split screen multiplayer, VR, overhead maps, drone cameras, etc.) you can avoid burdening all of your vertex shaders with having to somehow apply the on-screen positioning transform -- which may or may not be a big ask, depending on the renderer! Stuff like baking static HUD geometry into NDC space becomes harder to wrangle without having control over the viewport.
It's unfortunately hard to pull value from these in Impeller's 2D renderer, though, since I don't think scissors can be used for subpixel clipping on multisample intermediates (which is a shame). There might still be places where we could leverage scissors or viewports in Impeller, but I haven't put much thought into it TBH.

If I'm understanding correctly, it sounds like it would be a mistake for developers to try to use them in the API currently and they wouldn't realize that until rendering looked wrong

No, the problem is that the scissor test takes integers, not that they'll behave in a surprising way or not work when binding multisample textures. We just can't use them as a full replacement of our rectangle clips because all of our clips need to be antialiased -- although it might still be useful for bounds hint scenarios...
I would prefer we don't remove them since Flutter GPU renderers will benefit from having these expected options available.
One example of a command encoding optimization that will survive with time would be to make command encoding more granular and reflect how the backends need to track state anyhow. The viewport and scissor don't have to be part of every command. Nor do bindings, etc. Our current command encoding setup isn't just wasteful in terms of memory: We also need to optimize graphics API traffic, and so we need to check every field of every command for changes and encode those changes accordingly.
For packing these smaller commands in a buffer, I would recommend reworking the RenderPass API to take simpler commands (like BindTexture, DrawIndices, SetViewport, etc.) and have these commands encode a discriminated union chunk into the internal encoding buffer. The discriminated union's enum can be used by the backend as an index into a per-backend dispatch table (ordered list of functions) that knows how to handle encoding each of the subcommands.
Added a bug to discuss this possible solution here: https://github.com/flutter/flutter/issues/133179

Closing this as working as intended per the discussion. https://github.com/flutter/flutter/issues/133179 seems like the followup discussing making the commands slimmer.


CLI:  Fix for broken fields counts in CLI.

Fix name clash between option name and function.

There’s a flake8 failure.


config_dp01lr2w1e12_trimmed30.py

Dear authors,
Where can I find config_dp01lr2w1e12_trimmed30.py in multi_modality/exp/finetuning/ret_didemo/b16_25m.sh?

Hi! It is multi_modality/exp/finetuning/ret_didemo/b16_25m.py, and I forget to change the file name.

Thanks.


Looks like 0.8.3 hasn't been released.

TL;DR
Looks like 0.8.2 and 0.8.3 hasn't been released.
https://github.com/marketplace/actions/authenticate-to-google-cloud

Expected behavior
No response
Observed behavior
No response
Action YAML
- name: Auth gcp
      uses<EMAIL_ADDRESS>      with:
        workload_identity_provider: asdf
        service_account: asdf

Log output
No response
Additional information
No response

Hi @Byeong-jun-Kim
Sorry - this is a known bug where you have to go click buttons in the UI. It's been fixed now.

Can you file issues against those repos? The only way to make something appear in the marketplace is to manually click buttons in the UI (there's no API), which is why it sometimes falls through the cracks.


To ensure guidance is correct, the README documentation should be reviewed and updated

It seems that the README is out of date and refers to obsolete code. The contents of the file should be reviewed and - where appropriate - updated.
Consider also, moving done of the docs to the wiki if there's enough of it.

Dupe of #7


Parser confused by in in valid positions

JSHint does not consider expression context when parsing the "in" operator, resulting in erroneous reports of syntax errors for valid code such as
for (0 ? x in {} : 0; false; false) {}

@jugglinmike would like to take this on if its cool with you.  This seems like a bit more of a challenge than the last few patches I have submitted.  A general direction would be much appreciated to get started and could hopefully have this out before next week.

@jugglinmike any new status on this?  Still would like to make a PR for this.
Thank You

This particular bug is deceptively complex. We're always happy to receive
patches from anyone, but I don't expect to be able to provide timely feedback
of the kind you may need.