Photo uploader doesn't upload cropped image

when an individual upload an image and then crops it using the cropper, instead of the cropped portion getting uploaded, the whole image is uploaded, as it is.
The upload

The image that gets saved

fixed in #358


Design document: resource prerequisites for package installation

Write a design document for a feature that prevents package installation if the target cluster does not meet the minimum resource requirements of a package.

This is completed:
https://docs.google.com/a/mesosphere.io/document/d/1LyaJZEcQakeRDmGSysV0CuZKQeLi02NXy6E4lC4wKx4/edit?usp=sharing


No need for 2 Readme files

This repo has now 2 Readme files:

one at the root (/), that is been keep up-to-date
second at addons/Rakugo, that is old and broken - this one we should remove

I think same this morning when I do pre release 1.0. I copy Readme and license from root into addon/Rakugo :)
Ok, remove readme and license from addon/Rakugo :)


Could not resolve "./PageTitle.js"

This error happened when click New features in v1 topic
The things I changed were just some parameters in siteMetadata.js the version of dependencies was preserved.
webpage

Server Error
Error: Build failed with 1 error:
components/_mdx_bundler_entry_point.mdx:11:22: error: Could not resolve "./PageTitle.js"
This error happened while generating the page. Any console logs will be displayed in the terminal window.
Call Stack
failureErrorWithLog
file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (1449:15)

file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (1131:28)
runOnEndCallbacks
file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (921:63)
buildResponseToResult
file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (1129:7)

file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (1236:14)

file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (609:9)
handleIncomingPacket
file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (706:9)
Socket.readFromStdout
file:///Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js (576:7)
Socket.emit
node:events (394:28)
addChunk
node:internal/streams/readable (312:12)

console

components/_mdx_bundler_entry_point.mdx:11:22: error: Could not resolve "./PageTitle.js"
11 │ import PageTitle from './PageTitle.js';
╵                       ~~~~~~~~~~~~~~~~
Error: Build failed with 1 error:
components/_mdx_bundler_entry_point.mdx:11:22: error: Could not resolve "./PageTitle.js"
at failureErrorWithLog (/Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:1449:15)
at /Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:1131:28
at runOnEndCallbacks (/Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:921:63)
at buildResponseToResult (/Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:1129:7)
at /Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:1236:14
at /Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:609:9
at handleIncomingPacket (/Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:706:9)
at Socket.readFromStdout (/Users/tattran22/Documents/tailwind-blog/node_modules/esbuild/lib/main.js:576:7)
at Socket.emit (node:events:394:28)
at addChunk (node:internal/streams/readable:312:12) {
errors: [
{
detail: undefined,
location: [Object],
notes: [],
pluginName: '',
text: 'Could not resolve "./PageTitle.js"'
}
],
warnings: []
}

so what were the siteMetadata.js parameters that you changed? And there's no problem with a fresh cloned repo?

You can see what I have changed here

Yes. There are no problems with fresh clone

Actually, there is a problem with a fresh clone, sorry about it. It's related to this issue: https://github.com/kentcdodds/mdx-bundler/issues/66
I have fixed it in the template by upgrading the dependencies. You can do the same in your repo by setting "mdx-bundler": "^5.1.2" and adding "esbuild": "^0.12.15" (it's now peer dependency).

the same error in branch typescript .

Fixed. The ts branch error was due to the example importing PageTitle.js but since it is ts, the example should have been PageTitle.tsx 😆


was it cached?

i had been resetting my IIS and kept pressing ctrl shift f5 to force load the controller.js but kept getting the old js file..   until I renamed the js file name and re-loaded manually in the browser then i see the updated js file..   any ideas ?

This seems like a local environment issue and/or browser caching issue.


Extract code snippets, move ISO references to snippets, update msdn links to learn.microsoft

closes #265

closes #264

closes #263

closes #299

closes #262

closes #301

closes #261

closes #239

closes #302

closes #304

@mikeebowen do a replace for all the learn.microsoft.com prefixes and just have a relative link


/settlements and /chequebook/cheque return []

Summary
I just pulled the latest master and built bee version 0.6.3-6d2b2709  However, upon running this new version I find that the /settlements and /chequebook/cheque now return empty arrays.  Going back to the previous version with the same node and data directory returns the information that is still apparently in the statestore.
Steps to reproduce
Do the following 2 Debug APIs then build version 0.6.3-6d2b2709 and do them again.  You'll see the difference.
curl http://localhost:1635/settlements
curl http://localhost:1635/chequebook/cheque
Expected behavior
I didn't expect the settlements and checks to disappear.
Actual behavior
[] was returned.
It seems that the change to wrap bigInts to avoid an integer overflow is broken on these two endpoints.  The /balances and /consumed endpoints are now returning quoted strings for the balances, but these other two APIs appear to be borked.
curl http://localhost:6060/chequebook/cheque
{"lastcheques":[]}
curl http://localhost:6060/settlements
{"totalReceived":"0","totalSent":"0","settlements":[]}

Same issue

The same problem reappears

@AuHau , any thoughts on this? This probably relates to https://github.com/ethersphere/bee/pull/1735

@ldeffenb which specific version were you using before upgrading to 0.6.3-6d2b2709?

This is done now?

fixed in v1.0.0


playing as germany issues

hi! love you mod, but have some issue. playing civ on mac 13''. here they are:

starting a game i have 1/6 of my display filled with map in corner. quitting and loading a quicksave fixes that;
after a while i'm starting to experience unavailability to build new districts. simply cannot build a new one after built 2 (holy site and science). i see an option to build one but when i choose another one to build i'm getting into placing display, but when picking a tile and clicking over it nothing happens =(

The map is larger in CQUI by default (it can be set to the old size by right-clicking). If you're experiencing inconsistent behavior between loads, I suspect you may be experiencing a mod conflict. Could you please provide the affected save file?

I'm closing this issue now since I've received no response in 48 hours. I'll reopen it if/when that happens

Hello. Sorry about delay. Here you go.
On Tue, Jan 24, 2017 at 1:22 PM, Chris<EMAIL_ADDRESS>wrote:

Closed #258 https://github.com/chaorace/cqui/issues/258.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaorace/cqui/issues/258#event-934251868, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYGwovBi9ybMDqa8ceN_EFIyOLTWVOnNks5rVdDxgaJpZM4LqTL2
.

--
С уважением, Сергей Романюк.

and another one with the same thing.
Note that the pic of mod settings is missing. in the begging it appeared,
but then when something gone wrong it started to be missing even after game
reload.
On Tue, Jan 24, 2017 at 4:38 PM, Sergey Romanyuk<EMAIL_ADDRESS>wrote:

Hello. Sorry about delay. Here you go.
On Tue, Jan 24, 2017 at 1:22 PM, Chris<EMAIL_ADDRESS>wrote:

Closed #258 https://github.com/chaorace/cqui/issues/258.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaorace/cqui/issues/258#event-934251868, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYGwovBi9ybMDqa8ceN_EFIyOLTWVOnNks5rVdDxgaJpZM4LqTL2
.

--
С уважением, Сергей Романюк.

--
С уважением, Сергей Романюк.

I'm afraid the issue tracker doesn't support email attachments in the reply-by-mail feature. You'll have to provide a link to a file host like dropbox, mediafire, or google drive

no problem.
https://drive.google.com/drive/folders/0B9T6xTVLOpUiTUJKeUFjR0RuQVE?usp=sharing
On Wed, Jan 25, 2017 at 4:48 AM, Chris<EMAIL_ADDRESS>wrote:

Reopened #258 https://github.com/chaorace/cqui/issues/258.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaorace/cqui/issues/258#event-935502314, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYGwomACp5t6UUQ89XODexEbVYwqApJ9ks5rVqnugaJpZM4LqTL2
.

--
С уважением, Сергей Романюк.

Based on your save data you are using three separate mods that are incompatible with CQUI.  All three of these mods have custom versions built to work with CQUI baked right in, so all you need to do in order to fix your issue and enjoy the exact same experience is to disable those three.

got it. thx for your support and awesome mod! =)
On Wed, Jan 25, 2017 at 12:14 PM, Chris<EMAIL_ADDRESS>wrote:

Closed #258 https://github.com/chaorace/cqui/issues/258.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaorace/cqui/issues/258#event-935817922, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AYGwotSKc8wV33L_qkE3Hn95RsQPoULBks5rVxKFgaJpZM4LqTL2
.

--
С уважением, Сергей Романюк.


RTL support

Wow sorry, only now I see this PR. Commented. Also what is the support of initial in new IE?


[Loc] update to SQL xlf for 1-11-2023

This PR fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.006%) to 42.068%

Files with Coverage Reduction
New Missed Lines
%

extensions/sql-database-projects/src/common/httpClient.ts
1
66.18%

extensions/machine-learning/src/common/processService.ts
2
81.48%

extensions/sql-database-projects/src/dialogs/publishDatabaseDialog.ts
2
52.53%

Totals

Change from base Build<PHONE_NUMBER>:
-0.006%

Covered Lines:
28603

Relevant Lines:
63159

💛  - Coveralls


Bottlepay support for BIP21 lightning payments

Bottlepay supports scanning BIP21 QR codes and takes users directly to the lightning payment screen.

Thanks for updating this @tom-smith8!
Also credit to @pete001 for testing the original one. I linked the credit on the site to this PR.


Import of declarative_base when SQLAlchemy <1.4

In pyproject.toml, the expectation is SQLAlchemy = "^1". But, the way declarative_base is imported in cache.py will only work with SQLAlchemy >=1.4. This PR makes sure Langchain can be run in environments with SQLAlchemy <1.4

In general, it feels like SQLAlchemy should be made to be an optional dependency. What do you think, @hwchase17?

In general, it feels like SQLAlchemy should be made to be an optional dependency. What do you think, @hwchase17?

yeah let me take a look into that
im also fine just bumping the requirements to be "^1.4" - thoughts on that?

im also fine just bumping the requirements to be "^1.4" - thoughts on that?

The move from 1.3 to 1.4 isn't trivial (i.e., it's not just a matter of upgrading, as I learnt earlier today). So, that'd possibly make life difficult for LangChain users —that's certainly the case for us.

I know you're busy with exciting stuff @hwchase17, but, thoughts on this? 😊

I know you're busy with exciting stuff @hwchase17 (💪), but, thoughts on this? 😊

sorry for delay - agree this should be fixed. will get into the next release


is it possible to add a new type support in falcosidekick output which can forward event to a rest endpoint (method, headers...)

Motivation

Feature

Alternatives

Additional context

Use case:  The rest endpoint is a Pre-Authenticated url which can upload the file to remote object storage, the curl command looks like:  curl -X PUT --data-binary  '<your_file>'  https://


[WIP] Refactor BYOC init to smaller functions

The account controller is cluttered, so this PR works to refactor the initialization of a BYOC account into small functions in the byoc.go file.

/lgtm


”Cosoba” is listed in the drop-down menu

Description:
"Cosoba" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Cosoba" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Cosoba, GIURGIU (Cosoba)".


Added extra field to stream Message

This adds a mechanism to transmit additional data through a stream Message. This allows us to pack additional information into the json payload instead of packing into Content.

Would you mind if we called it "Details"?

I'm good with that. Done.


Introduction to RSpec

Introduction to RSpec
Suggested by: Adam Wead
Presenter: Adam Wead
Format: Workshop (half-day)
Audience: Devs

Audience
Developers, new and old - geared towards current adopters or people who have just started working on an application.
Description
As in past Connects, this will be an updated workshop covering issues and strategies when testing Samvera-based applications using RSpec. The workshop will go over testing practices for each of the principle unit components of an application (models, controllers, views, jobs, services, etc.) and also contrast that with how feature tests and written. Takeaways will include some "boilerplate" examples for each kinds of test, test suite configuration, continuous integration, and if time permits, one-on-one help with individual questions or blockers that anyone might be currently having. Having a laptop and working Hydra application is a must, even if it's just the barebones. Ideally, this workshop is geared towards current Hydra adopters or people who have just started working on applications. Someone who has never used any of Samvera's principle applications such as Curation Concerns, Sufia, or Hyrax, might have difficulty.

@awead Do you want to require any equipment? Feel free to add directly to wiki page if so,  https://wiki.duraspace.org/display/samvera/Workshops+at+Samvera+Connect+2017
We'll also give you a list of attendees 2 weeks before to send out any info.


Adds the support for LPRM vod retrievals

This plugin adds the support for processing vegetation optical depth
retrievals from the Land Parameter Retrieval Model (LPRM). The data
was obtained from Dr. Richard de Jeu and vandersat.com
Resolves #172

Hi Sujay:  Do you have a test case for this new feature, so we can compare the output?

You can find a test case (and output) at:
/discover/nobackup/projects/lis_aist17/svkumar/SMAP_VOD_DA/procDA_CDF_LPRM_X

Thanks!
Now can you add read permissions for /discover/nobackup/projects/lis_aist17/svkumar/SMAP_VOD_DA/data?  It looks like a landmask file in that directory is needed for this test.

Done. Please try again.

I'm running a final test with the GNU compilers, and the results should be ready tomorrow morning.
One problem I notice:  You did not update ldt/configs/ldt.config_master to add the new config options for LPRM.  This should be corrected before the pull request is merged.


flip-link doesn't handle LENGTH in bytes

this linker script works:
MEMORY
{
  FLASH : ORIGIN = 0x00000000, LENGTH = 256K
  RAM : ORIGIN = 0x20000000, LENGTH = 64K
}

this linker script doesn't work with flip-link, but works with regular LLD
MEMORY
{
  FLASH : ORIGIN = 0x00000000, LENGTH = 262144
  RAM : ORIGIN = 0x20000000, LENGTH = 65536
}

$ cargo b --bin hello
(..)
  = note: rust-lld: error: section '.data' will not fit in region 'RAM': overflowed by 48 bytes

this is probably some issue in the linker script parser

Fixed by #38


chore(docs): reorder alphabetically list of components

This PR is a proposal to reorder alphabetically the list of components in the documentation. IMHO it is simpler to find the components in the list and more natural.
After the merge

[ ] If we agree on that, I'll create a PR for Bootstrap as well
[ ] Check if it can be backported to v4

Maybe the one in docs/5.1/getting-started/introduction.md > Quick start > JS > Components could be handled in this PR too ?

Yep ofc, I thought it was already good; haven't seen the last one 🙃 Thx!


Is this not working anymore?

I keep getting this error in the browser:
jquery.simpleWeather.min.js:3 Uncaught TypeError: $.simpleWeather is not a function
    at HTMLDocument.<anonymous> (jquery.simpleWeather.min.js:3)
    at i (jquery.min.js:2)
    at Object.fireWith [as resolveWith] (jquery.min.js:2)
    at Function.ready (jquery.min.js:2)
    at HTMLDocument.K (jquery.min.js:2)

I'm using the script without error on my site. If you're talking about the demos what looks like is going on is that GitHub is blocking hot linking to https://cdn.rawgit.com/monkeecreate/jquery.simpleWeather/master/jquery.simpleWeather.min.js so the SimpleWeather plugin isn't being loaded.
Instead you can update the links (under Settings in CodePen) to use a working CDN URL for example:
https:// cdnjs.cloudflare.com/ajax/libs/jquery.simpleWeather/3.1.0/jquery.simpleWeather.min.js
Here's a new URL with the updated link for the basic demo:
https://codepen.io/anon/pen/dVzMzJ
If you're having trouble on a live site then please provide more details :)

@seanvree I'm fairly certain it's not being supported anymore.

#281 has an update on the project's current status.
I took this question as "does it work" rather than "is it being maintained". The code is still working for me even with the latest jQuery version. It does currently rely on the Yahoo Weather API remaining live though.


Adding an SPFx Teams tab on the new Teams desktop client is not possible

Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
Windows
What browser(s) / client(s) have you tested

[ ] 💥 Internet Explorer
[ ] 💥 Microsoft Edge
[ ] 💥 Google Chrome
[ ] 💥 FireFox
[ ] 💥 Safari
[ ] mobile (iOS/iPadOS)
[ ] mobile (Android)
[ ] not applicable
[ ] other (enter in the "Additional environment details" area below)

Additional environment details
New Teams desktop client
Describe the bug / error
When I add my SPFx app as a new tab to a Team on the new Teams desktop client, the save button stays disabled so that I can't add the app to the Team.
The same works on the web client and also on the old Teams client without any problem.
I tried the same with different apps. I could not add any SPFx app as a new tab to teams on the new client.

The only error I can see on the console is:

Steps to reproduce

Add a SPFx app as a new tab in Teams
The save button stays disabled

Expected behavior
The save button becomes enabled (as it always does on the web and old desktop client) so that we can save the config and add the app/tab to the Team.

Just to clarify here, the Save button is staying disabled on Teams desktop, but this works correctly on Teams web?

Same Problem here, but i experienced this behavior starting with spfx 1.16 and the New Teams (startet my testing in late July/ beginning of August 2023). As it was neccessary to use own teams manifest back then (to use with outlook and so on), i thought I do something wrong in the manifests file. Somewhere End of August with spfx 1.17 the teams manifest could be generated automatically by the sharepoint backend again - but the behavioir stayed the same til this day (and spfx 1.18).
On top of this: You can add the Webpart tab in the legacy teams, switch to new teams and it will work BUT you can not open the property pane - it simply does nothing when clicking on "Settings". In SharePoint (and old Teams) everything works as expected.

Yes, I have also experienced the same issue with the property pane on the New Teams. It is good point to mention.

I can also confirm this behavior. This needs to be fixed asap as this is a big breaking issue! Otherwise people will switch from SPFx to native teams apps for development and SPFx will lose credibility. Sorry for @mentioning, but we need at least a statement on this @VesaJuvonen @AJIXuMuK

We're working with Teams partners to figure out the regression and address it.

The fix has been done and will be rolled out in the next couple of weeks.

Thanks for fixing this - i can confirm that i'm able to add spfx apps an configure them.
BUT there is a new issue that is (from my perspective) related to this one: After adding an configuring a Teams-Tab, I unable to alter the configuration, it get's resetted to the initial defaults as soon as i select "Settings" from the newly created Tab. To be more precise: I looks like I end up in the "you added a new Tab-Dialog". Can anyone else confirm this?


AzureSecurityBenchmarkSolution

Required items, please complete
Change(s):

See guidance below

Reason for Change(s):

See guidance below

Version Updated:

Required only for Detections/Analytic Rule templates
See guidance below

Testing Completed:

See guidance below

Checked that the validations are passing and have addressed any issues that are present:

See guidance below

Guidance <- remove section before submitting

Before submitting this PR please ensure that you have read the following sections and filled out the changes, reason for change and testing complete sections:
Thank you for your contribution to the Microsoft Sentinel Github repo.

Details of the code changes in your submitted PR.  Providing descriptions for pull requests ensures there is context to changes being made and greatly enhances the code review process.  Providing associated Issues that this resolves also easily connects the reason.

Change(s):

Updated syntax for XYZ.yaml

Reason for Change(s):

New schema used for XYZ.yaml
Resolves ISSUE #1234

Version updated:

Yes
Detections/Analytic Rule templates are required to have the version updated

The code should have been tested in a Microsoft Sentinel environment that does not have any custom parsers, functions or tables, so that you validate no incorrect syntax and execution functions properly.  If your submission requires a custom parser or function, it must be submitted with the PR.

Testing Completed:

Yes/No/Need Help

Note: If updating a detection, you must update the version field.

Before the submission has been made, please look at running the KQL and Yaml Validation Checks locally.
https://github.com/Azure/Azure-Sentinel#run-kql-validation-locally

Checked that the validations are passing and have addressed any issues that are present:

Yes/No/Need Help

Note: Let us know if you have tried fixing the validation error and need help.

References:

Guidance for Detection checks
General contribution guidance
PR validation troubleshooting

@aprakash13 Can you please review the Analytic Rules. thanks!!!

@aprakash13 Can you please review the Analytic Rules. thanks!!!

@anki-narravula Can you please review the play books. thanks!!!

@anki-narravula Can you please review the play books. thanks!!!

Work book looking good once we get approve for analytic Rules and playbooks we can merge. thanks!!!

Work book looking good once we get approve for analytic Rules and playbooks we can merge. thanks!!!

@anki-narravula Can you please approve the playbooks?

Team, would it be possible to provide an update on this solution? PR was submitted on 18APR22

@anki-narravula Can you please approve the playbooks.

@anki-narravula Can you please approve the playbooks.

@preetikr @ashishsyal, is there anything I can do to facilitate merge of this solution?


fix: Proxy UDP requests

Description
Tested and validated the guide.
The only sections that does not work is "Update the Gateway"
installed Gateway API and tested however, there is an error that reads: "Error from server (NotFound): gateways.gateway.networking.k8s.io "kong" not found" step3 of Expose additional ports section
steps to reproduce: start the cluster, install the CRD "kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.8.1/experimental-install.yaml", then enable the feature " kubectl set env -n kong deployment/ingress-kong CONTROLLER_FEATURE_GATES="GatewayAlpha=true" -c ingress-controller" only change the is the name of the deployment 'kong-controller'
Testing instructions
Preview link:
Checklist

[x] Review label added
[x] PR pointed to correct branch (main for immediate publishing, or a release branch: e.g. release/gateway-3.2, release/deck-1.17)

Closing this PR because it was raised against the main branch.


Ensure error boundary errors are getting posted to new relic.

Issue Description
Currently terra-application provides an error boundary, but when errors are caught they are suppressed from new relic.  New relic provides an API to log errors which could be used to forward errors if newrelic is present on the window.
https://docs.newrelic.com/docs/browser/new-relic-browser/browser-agent-spa-api/notice-error

I cleared the milestone so that we could discuss if this is a bug (yes) :P

I'm curious if there should also be a callback that applications or other components that build on top of terra-application can use to post errors to other sources other than New Relic.

This way we are not locking everyone into New Relic support since the choice of observability framework changes like the wind.

I updated the title of this to more accurately describe what we want to do (provide a mechanism for consumers to provide a global error handler that gets executed on error boundaries).


Weapon with Runes not being Imported

Describe the bug
When I try to import a weapon that has runes, it gets stuck on the weapon importation phase.
To Reproduce
Steps to reproduce the behavior:

Go to (https://pathbuilder2e.com/launch.html?build=590205)
Click on Export to Json
Insert the specified number into the import
See failed import.

Expected behavior
The weapon should be imported with the runes.
Screenshots
If applicable, add screenshots to help explain your problem.
https://i.imgur.com/gh5kIf9.png
Environment:

Chrome
Foundry Version 11 Stable 315
Pathfinder System Version 5.9.1
Module Version 0.11.1
Does this behaviour occur with other modules disabled: Yes

Additional context
I'm sorry to put this up so near an already released patch.

In Pathbuilder please got to Export -> "Share Copy of Character" and provide the link. (https://pathbuilder2e.com/launch.html?build=590205)
Details of any errors in the browser console (press F12).
Foundry VTT | Rendering PathmuncherImporter
commons.js:8807 Foundry VTT | Created Actor with id [9clZaEqOvn3uA2j2]
commons.js:8807 Foundry VTT | Created 3 Item documents with ids: [jae29CIJG2Qg20B1,Z7QY2lKVjVlKXvLW,eKvRFu9TDyHaNrHn] in parent Actor [9clZaEqOvn3uA2j2]
commons.js:8807 Foundry VTT | Deleted Actor with id [9clZaEqOvn3uA2j2]
commons.js:8807 Foundry VTT | Created Actor with id [ZUDKUBCpuTp4P7m6]
commons.js:8807 Foundry VTT | Created 5 Item documents with ids: [jae29CIJG2Qg20B1,Z7QY2lKVjVlKXvLW,0tVy8ovaZZPbYgcv,eKvRFu9TDyHaNrHn,t02b2bnpvgQtHZrV] in parent Actor [ZUDKUBCpuTp4P7m6]
commons.js:8807 Foundry VTT | Deleted Actor with id [ZUDKUBCpuTp4P7m6]
logger.js:53 pathmuncher | WARN > Unable to find parsed feature match for granted feature Reactive Strike. This might not be an issue, but might indicate feature duplication. Object
log @ logger.js:53
warn @ logger.js:79
#createGrantedItem @ Pathmuncher.js:666
#addGrantedItems @ Pathmuncher.js:1174
commons.js:8807 Foundry VTT | Created Actor with id [WJIVo3iJcshHVpVJ]
commons.js:8807 Foundry VTT | Created 10 Item documents in parent Actor [WJIVo3iJcshHVpVJ]
commons.js:8807 Foundry VTT | Deleted Actor with id [WJIVo3iJcshHVpVJ]
commons.js:8807 Foundry VTT | Created Actor with id [U8SqbZ1NZ7lIU4V1]
commons.js:8807 Foundry VTT | Created 12 Item documents in parent Actor [U8SqbZ1NZ7lIU4V1]
commons.js:8807 Foundry VTT | Deleted Actor with id [U8SqbZ1NZ7lIU4V1]
logger.js:53 pathmuncher | WARN > Unable to find parsed feature match for granted feature Shield Block. This might not be an issue, but might indicate feature duplication. Object
log @ logger.js:53
warn @ logger.js:79
#createGrantedItem @ Pathmuncher.js:666
#addGrantedRules @ Pathmuncher.js:1083
logger.js:53 pathmuncher | WARN > Unable to find parsed feature match for granted feature Fighter Weapon Mastery. This might not be an issue, but might indicate feature duplication. Object
log @ logger.js:53
warn @ logger.js:79
#createGrantedItem @ Pathmuncher.js:666
#addGrantedItems @ Pathmuncher.js:1174
commons.js:8807 Foundry VTT | Created Actor with id [VuQCl22J3LiYmaTq]
commons.js:8807 Foundry VTT | Created 15 Item documents in parent Actor [VuQCl22J3LiYmaTq]
commons.js:8807 Foundry VTT | Deleted Actor with id [VuQCl22J3LiYmaTq]
logger.js:53 pathmuncher | WARN > Unable to find parsed feature match for granted feature Battle Hardened. This might not be an issue, but might indicate feature duplication. Object
log @ logger.js:53
warn @ logger.js:79
#createGrantedItem @ Pathmuncher.js:666
#addGrantedItems @ Pathmuncher.js:1174
logger.js:53 pathmuncher | WARN > Unable to find parsed feature match for granted feature Weapon Legend. This might not be an issue, but might indicate feature duplication. Object
log @ logger.js:53
warn @ logger.js:79
#createGrantedItem @ Pathmuncher.js:666
#addGrantedItems @ Pathmuncher.js:1174
commons.js:8807 Foundry VTT | Created Actor with id [8KgdrZKG5mtyZkKm]
commons.js:8807 Foundry VTT | Created 22 Item documents in parent Actor [8KgdrZKG5mtyZkKm]
commons.js:8807 Foundry VTT | Deleted Actor with id [8KgdrZKG5mtyZkKm]
logger.js:53 pathmuncher | WARN > Unable to find parsed feature match for granted feature Tempered Reflexes. This might not be an issue, but might indicate feature duplication. Object
log @ logger.js:53
warn @ logger.js:79
#createGrantedItem @ Pathmuncher.js:666
#addGrantedItems @ Pathmuncher.js:1174
foundry.js:6629 TypeError: Cannot set properties of undefined (setting 'value')
at Pathmuncher.applyRunes (Pathmuncher.js:1643:1)
at #generateWeaponItems (Pathmuncher.js:1670:1)
at async #processEquipment (Pathmuncher.js:2151:1)
at async Pathmuncher.processCharacter (Pathmuncher.js:2353:1)
at async PathmuncherImporter._updateObject (PathmuncherImporter.js:104:1)
at async PathmuncherImporter._onSubmit (foundry.js:6626:7)
_

Thanks for the report, fixed in v0.11.2, out now.


Refactor EntryPointDriver to not compile against a specific simulator

Currently the EntryPointDriver is compiled against the default QuantumSimulator in a way that makes it necessary to create a new entry point driver project for each variant of the quantum simulator (like those built with different target packages). The entry point infrastructure already supports dynamically choosing an alternate simulator at runtime, so instead the explicit references to the default could be removed and the infrastructure reworked slightly to treat the built-in simulator the same was as a custom simulator, thus removing the linking between the two dlls and allowing any simulator variant to be used with the single entry point driver.
See #249 for the original context of this ask.

yes please 👏

After finishing the infrastructure for #249, we now compile the simulators without a direct dependency on a specific target package; that is to say, the Microsoft.Quantum.Simulators package no longer depends on Microsoft.Quantum.QSharp.Core nor does it assume the presence of a specific Q# intrinsic gate set. That should allow any simulator using any gate set to be built along with the entry point or loaded dynamically without requiring that simulator to use the QSharp.Core target package.


Update docker cmd help

https://github.com/rancher/rancher/issues/5716

https://github.com/rancher/rancher/issues/5659
https://github.com/rancher/rancher/issues/5662


Add KeybindText

SpongeAPI | SpongeCommon

Is an empty keybind text valid? Otherwise we should check this and eventually make the parameter required for the builder already (this is how it seems to be for the other text classes).

Maybe there should be a CatalogType for the supported keys? There is also a key.invalid key that can be used in cases that the key binding is unknown.

What's the status of this PR? With the way that the Text implementation is currently setup, we can't properly handle mods using TextComponentKeybind, since we can't represent it as a Text.

LGTM as-is (havn't checked it out and tested locally)
Is there something blocking this from being merged? @gabizou Your complaint earlier about the JD is just, but I don't think it should hold this up from merging.

@gabizou note, it's needed for stable as well, due to "What's the status of this PR? With the way that the Text implementation is currently setup, we can't properly handle mods using TextComponentKeybind, since we can't represent it as a Text."
It caused aaron various issues.

@kashike Is this complete? Or do you plan to work on this anymore?

Closing as we're going in a slightly different direction in api-8 and won't be adding major changes to api-7 at this point.


Upgrade syn and quote, rename component attrib to storage

Not meant to merge yet.

This change is

Thanks @Rhuagh
bors r+


Custom summary table in Snakemake report for virologist

Use the

existing analyse_contigs.py script and
the rbt csv-report subcommand

to generate an interactive summary report of the following structure:

For information about the mutations, the subclonal .bcf file (in results/calls/ref~main/) can be used.
Necessary information from this file is:

[ ] HGVSp from the ANN field

Additional, useful information we could to virologists are:

[ ] IMPACT from the ANN field
[ ] Allele frequency (AF) from the ANN field

The output from the rbt output should be integrated into the Snakemake report.
Moreover, a rule to produce the Snakemake report (for the current run) should be added.

Generate csv file for table displayed above.
Use RBT csv-report
Integrate csv-report in Snakemake report

#88


Please upgrade minimist

Sails version (sails): 1.2.3

A minimist vulnerability was found, is it possible to upgrade minimist to the latest version?

@ebaynaud minimist is a library we use for parsing command-line options, so I don't think this vulnerability has a material impact.  That said we want to keep things clean when Sails is installed, so thank you for bringing this to our attention!
What changed in minimist between 0.0.10 and 1.2.5?

No changelog, no release notes, no breaking changes in readme.
Browsing commits seems to show incremental changes with a v1 as soon as the maintainer considered it to be stable.
Your tests are still passing so I guess this is not risky to upgrade.

Tested out my local sails with upgraded minimist, to make sure it was properly parsing command-line arguments:

generated new app with --no-frontend
generated new app with --caviar --fast
lifted app with --redis

Everything's looking good 👍


Add a Fortissimo Composition spell effect

I hope this is up to snuff. This is my attempt at consolidating Fortissimo Composition (Inspire Heroics) into a single effect. It will address #10305 by way of granting Rallying Anthem's effect itself, too. The Grant Item is not really necessary, but it does make the workflow easier for the user.

I don't know that this is how we want to go about it, will need to think if there's some cleaner way to do it.

Yeah, it is a bit sloppy but I couldn't think of a cleaner way. I figured it'd be an improvement over the current way. Cheers!


[RFC] performance improvements

On volkszaehler (https://github.com/volkszaehler/vzlogger/pull/272#issuecomment-391827131) it was mentioned that reading registers one by one is much slower than reading blockwise.
This leads to the following ideas for improving readout performance or lowering load:

group device registers into groups that can be read at once
refactor the mqtt rate parameter (or add another one) to not limit pushing readings to mqtt but instead defer reading from device if rate is too high (NOTE: this would affect all consumers, not only mqtt)

This is actually more complex than expected:

meter reads are of variable size (i.e. ALE3 reads mostly but not only single registers)
some meters only support reading up to a certain number of registers en bloc (at least ALE3)

#83 provides a basis from implementing this. Closing here.


Updating https:// references in schema links

Using https:// references in schema links results in failed MFA processing on ADFS side (referenced from https://habr.com/ru/post/508804/)
Updating links to reflect http://references

Checking with engineering.

#sign-off


(PUP-10021) Allow password change for disabled users

This commit enables puppet to change the passwords of disabled, locked
out and expired users.
Before this commit puppet will not change the password of
disabled,locked or expired users, even is this operation is supported in
windows.

commited to wrong branch


Turbomind prefix caching

Motivation
https://github.com/InternLM/lmdeploy/issues/1407
Modification

[x] Turbomind change
[ ] Add cli option after https://github.com/InternLM/lmdeploy/pull/1429 merged
[x] Benchmark and evaluation
[x] Compatibility testing with AWQ, online KV Cache Int4/Int8 and tp

TODO: need to add compatibility testing with AWQ, online KV Cache Int4 and Int8 @ispobock

TODO: need to add compatibility testing with AWQ, online KV Cache Int4 and Int8 @ispobock

Also need to test the case when TP is turned on.

 Thanks so much.
We plan to release v0.4.0 next Tuesday, mainly focusing on new VLMs support and kv4/8 quantization and inference.
Regarding the prefix caching of both engines, I would like to highlight it in v0.5.0, which is planned to be published around May 20th

Fantastic job! Thanks so much. We plan to release v0.4.0 next Tuesday, mainly focusing on new VLMs support and kv4/8 quantization and inference. Regarding the prefix caching of both engines, I would like to highlight it in v0.5.0, which is planned to be published around May 20th

ok

And may you help review the code and give some suggestions? Thanks. @lvhan028 @lzhangzz @grimoire

We plan to release v0.4.0 next Tuesday, mainly focusing on new VLMs support and kv4/8 quantization and inference.
Regarding the prefix caching of both engines, I would like to highlight it in v0.5.0, which is planned to be published around May 20th

@lvhan028 Is there any planned features on Turbomind engine in the next month? Hopefully there won't be too many code conflicts.

There are definitely conflicts due to #1458

There are definitely conflicts due to #1458

There is almost no impact, as long as the refactoring of LlamaBatch, decoupling batch and model will be after v0.5.0, there will not be any major impact.

Fantastic job! Thanks so much. We plan to release v0.4.0 next Tuesday, mainly focusing on new VLMs support and kv4/8 quantization and inference. Regarding the prefix caching of both engines, I would like to highlight it in v0.5.0, which is planned to be published around May 20th

We need to regularly merge the main branch before approving to avoid conflicts.

Also, in the current implementation, (re)-computation of shared blocks are not shared (even though the memory blocks are shared and may be re-written multiple times)

@lzhangzz In current implementation, the blocks in block trie are computed and read-only. We only cache and match computed blocks. So shared blocks will not be re-written multiple times.

In current implementation, the blocks in block trie are computed and read-only. We only cache and match computed blocks. So shared blocks will not be re-written multiple times.

I see.
However, once a cache block is evicted, the sharing that block seems problematic.

once a cache block is evicted, the sharing that block seems problematic.

@lzhangzz In the current setting, only blocks with use_count = 1 (only block trie holds the use_count) can be evicted. That means no sequence is using this block. After eviction, the block will be freed and reallocated.

In the current setting, only blocks with use_count = 1 (only block trie holds the use_count) can be evicted. That means no sequence is using this block. After eviction, the block will be freed and reallocated.

This is also a problem. The idea of "occupied blocks can't be evicted" breaks the relaxed FCFS scheduling and may lead to starvation. It makes the ownership of shared blocks transferrable between requests (in an uncontrollable way).
Imagine the following request order.
As more of A_x comes, C may never get a chance to run because [b] is always occupied.

And use_count is for active sequences, sequences in interactive mode can still reference the same invalid block. When re-computation happens later, the sequences will allocate & refill the blocks indenpendently.

The idea of "occupied blocks can't be evicted" breaks the relaxed FCFS scheduling and may lead to starvation.

@lzhangzz preempt logic can be applied to solve the starvation problem. C with higher priority, so the blocks in later A_x will be preempted.

preempt logic can be applied to solve the starvation problem. C with higher priority, so the blocks in later A_x will be preempted.

Preemption won't work because BlockTrie holds a dummy reference and BlockTrie::evict operates directly on the actual use_count while preemption logic operates on a snapshot of use_count.

@lzhangzz

The first one is expected. Now we only cache and reuse the computed blocks to avoid write conflict. In this design, the blocks reuse may have one iteration delay. If a new request want to match prefix blocks, the blocks should be cached in the previous iterations. I don't think it will affect overall performance too much.
For the second one, I am not sure I fully understand. Blocks in the prefix cache will not be evicted when use_count=0.  They will only be evicted when they are re-allocated (indicated by unique_id mismatch during verification). Before the re-allocation, they still can be reused. If a block is re-allocated, we don't need to get it back to cache.

We still have some un-closed issues

With a batch of sequences sharing previously unseen (or evicted) prefixes, neither computation nor cache blocks are shared.

When something in the prefix cache gets evicted, it can't get into the cache again until a request with the same prefix as prompt comes.

@lzhangzz The original intention of this feature design is to solve the problem of system prefix cache. Especially for search scenarios in Internet companies, the current classic practice is to conduct SFT based on a SOTA chat model and use prompt engineering to make it a question and answer assistant in the vertical field. This usually means that in the request, there will usually be one or more common, similar system prefix caches. The current implementation is compatible with the existing designs and implementations of LMDeploy, and meets the requirements mentioned above. We currently believe it meets expectations. What you are discussing is a more universal cache. And we could also discuss your suggestion again. Regarding the first point, I also agree with what @ispobock said, as it does not have a significant impact on performance.

Hi @irexyc May you help review the PR? Thanks.

@irexyc Pls help to check this will not break VLM when embedding inputs are present.

Please add cc to the extensions and fix the format issue.


Question about aggregation method

Hi,
I was reading the paper and taking some notes and I have a question about one of the formulas used to describe the "Aggregation Method 2". If I understand correctly, rows of Z^l matrix are scaled by dividing by the sum of the same row, which makes sense to me. But the formula displayed show a term where the denominator iterates over N, the number of images. That could also make some sense, but the objective of this aggregation is to determine the importance of the layer for a single image/row.
I left an example to make my question more clear, showing possible values to divide for. Do I need to divide each value in the matrix as shown in the top or the bottom of the figure? In that case, maybe the formula is wrong or am I reading it incorrectly?

Thanks,
PS: Loved this work 👌 Congrats 🎉

Hi @aaossa,
Thank you for the kind words and reaching out! I think you're right, we have a small bug in our equation notation... but all the text is accurate! tl;dr: use the green version in your graphic above that matches the paper text. I'll explain a bit more below.
One row of this Z^l matrix represents the maximum activation per channel for a single image (your matrix on the left-hand-side above).
We want a way to choose the top activated channels. Aggregation Method 1 from the paper simply picks the top k, say k=3 or k=5 channels. Aggregation Method 2 is adaptive in that it'll pick the top k% of channels based on converting the activations of a row (per image) to probability mass function (integral should sum to 1), in other words, trying to find the "knee" of the distribution (if you were to sort it). This is because one image may have 2 channels that are super important, but another image could have 4 channels that are super important. So finding this knee could be more accurate than the static k threshold from Method 1.
To do this, we divide each row by its row sum so that each row (image) is now a probability distribution. So this is the green version of figure that matches the text. The equation fix should be summing over j not i in that denominator summation term. You'll find this matches the code too in this notebook:
# METHOD 2: prob mass
working_acts_max = imgs_acts_max[i]/np.sum(imgs_acts_max[i])     <-- divide by row sum

Thank you for find this notation error! Hopefully this helps.

That was a perfect explanation, really useful 👌 Also, now I manage to understand better your Method 2, which makes more sense to me now 🙌 Thanks!

You bet!


Versioning

Awesome stuff BH,
New updates pushed! awesome.
Just an issue with github dep, which version should we use for the latest ?
is it 2.1? what should I add on my gradle file dep?

compile 'com.beardedhen:androidbootstrap:2.0.0' should allow you to use the latest updates. Maven Central will take a while to sync, which is why the badge is currently displaying 1.2.3.

Ah got it, now onto fixing all my layouts with the buttons in em!
thanks


Refactor tab-indentation as a token-based rule

Summary
This PR updates the W191 (tab-indentation) rule from a line-based to a
token-based rule.
Earlier, the rule used the triple_quoted_string_ranges from the indexer to
skip over any lines inside a triple-quoted string. This was the only use of
the ranges. These ranges were extracted through the tokens, so instead we can
directly use the newline tokens to perform the check.
This would also mean that we can remove the triple_quoted_string_ranges from
the indexer but I'll hold that off until we have a better idea on #7326 but I
don't think it would be a problem to remove it.
This will also fix #7379 once PEP 701 changes are merged.
Test Plan
cargo test

Current dependencies on/for this PR:

main

PR #7435   👈

This comment was auto-generated by Graphite.


Add developer guide for local development

Also set up basic testing infrastructure for React frontend.
Signed-off-by: Antonin Bas<EMAIL_ADDRESS>

Depends on #1


Update pull_request_template.md

Description
Some more small changes to the formating:

[x] Brief reminder text that's easy to read.
[x] Order by what occurs more often in development.
[x] Add ticket number on the PR name so it's visible in the list of open PRs.

🙌


Use spf13/cobra for docker build

Moves the build command to api/client/image/build.go and use cobra  🐍.
/cc @dnephin @thaJeztah @LK4D4 @cpuguy83
🐸
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

LGTM

LGTM


bugfixes for Agent Based Installer

Cherry picking bug fix from crucible.

@arjuhe Can you check this for me.

I think I see the issue. XDG_RUNTIME_DIR: "{{ config_file_path }}" also needs to change to XDG_RUNTIME_DIR: "{{ generated_dir }}". I guess config_file_path wasn't cleaned up when we tested.

I haven't been able to recreate the issue. However I have a suspicion that is the issue so I'll add a commit to change that an see if that corrects the issue.

Looks like I was right. I'll get that fix merged back into crucible (for while we still haven't converted over to the collection).


cmd/internal/src: XPos.After doesn't necessarily match Pos.After

XPos.After (and XPos.Before) compares XPoses with different bases according to their base index, which is determined by the order they're added to the PosTable. I think this is worrying because we don't currently have any code in the compiler to ensure PosBase are registered in order.
Possible solutions I see:

Change XPos.After's signature to take a *PosTable parameter and return the result of comparing the corresponding Pos values.
Change package syntax's parser to register PosBase with the PosTable during parsing. (Will require locking.)
Change package syntax's parser to collect all PosBase into a slice which we can register serially once parsing is done.

/cc @griesemer

I'd rather not tie more information about positions into the syntax package (in fact, I've been trying to see if I can come up with an approach that takes that dependency on the pos package out again). I'm still hoping we can keep this package pretty clean, so that at some point we can expose it outside.
Regarding the issue: What is the actual problem? Is it that we want to the base indices be representative somehow of the order in which files were presented to the compiler?

The motivating issue is I was working on reviewing CL 40095, which has an API like (simplify):
func openScope(start, end src.XPos)
func closeScope()

So this API requires converting the { and } token positions to src.XPos before actually processing the contents within. I.e., it can register PosBases out of order.
This is problematic in practice for cgo, because it very heavily uses //line annotations. (To paraphrase Obi-Wan, "It's more pragma now, than code.")
I'm leaning towards changing the API to "openScope(start)" and "closeScope(end)" separately, which hopefully avoids the issue, but I worry there could still be other places where we Pos->XPos transform out of order.

Discussed with @griesemer: not important for Go 1.9 (we can workaround it), but something to think about for 1.10.


Document ability of [sync] entry methods to return any type that supports PUP

Original issue: https://charm.cs.illinois.edu/redmine/issues/1136

No body.

Original date: 2016-07-11 21:49:50

The manual still says that [sync] entry methods can only return messages

Original date: 2016-09-02 20:23:31

~~https://charm.cs.illinois.edu/gerrit/#/c/1822/~~ https://github.com/UIUC-PPL/charm/commit/57f414efb5f9d7ac5209c3e6ce242665b2781404


Popup of a ComboBox doesn't show on MacOS

Describe the bug
Popup of a ComboBox doesn't show on MacOS
To Reproduce
Add a ComboBox to a window and add a ItemSource
Expected behavior
the popup is shown with the items in the item source
Screenshots
Desktop (please complete the following information):

OS: Mac
Version 11.0.1

Additional context

Also, can be related to https://github.com/AvaloniaCommunity/Material.Avalonia/issues/128

I've tried it with the fluent theme and it doesn't work either.

@JanTamis please provide a minimal sample to reproduce

@timunie How would you like the sample (zip or as GitHub project)

GitHub link is preferred as one can file a PR if a simple fix is there, but zip also works for us.

sample: https://github.com/JanTamis/DropDownTest

Works here.

Works here.

It's about opening the combo box that doesn't work.

Could it be because im using the Sonoma beta?

@JanTamis maybe you can do the following:

clone Avalonia source (mind build instructions)
add your sample to samples/Sandbox for testing
Try to debug it on your machine. If you find anything that fixes your issue, a PR is welcome.

Got similar issue when I tested on MacOS, not only with ComboBox, but with all popups and flyouts in my app... I don't know how it happened and what manipulation I've done, but 30s or a minute after I've noticed the issue, it get back to normal in the same testing session. It was with Rc1 may be...
I do not have a Mac to run new tests.

I'll take a look if i can find in which version of Avalonia is begun happening.

On my end, this issue occurs when I run the app and have its window over the current full-screen Rider window. However, if I move the app window to the desktop or switch it to full screen, the ComboBox items show up.

On my end, this issue occurs when I run the app and have its window over the current full-screen Rider window. However, if I move the app window to the desktop or switch it to full screen, the ComboBox items show up.

Exactly what I encounter too on a M2 MacBook

I have the same issue using Avalonia 11.0.7 on Mac OS 14.2.1 (23C71). Both latest version.

Seems really be related to Rider i  Fullscreen mode. Has anybody reported it to Rider and could share a link?


Module refactoring and pipeline support

This is not a serious PR; I saw your post on reddit and had some ideas for how this could be refactored and made similar to built-in powershell commands.
The main change is refactoring the whole thing into one module, and merging the public scripts into the private module functions such that the private ones were useful on their own.

ProbeCert became Get-RemoteCertificate, with elements of Subject lifted to the first level of results so it can be piped into other functions.
CreateNewCSR/CreateCsr became New-CertificateSigningRequest, which can take its input from the properties of objects piped to it.
ProbeCerts is largely the same, but I've left notes at the top of the file detailing how it's superfluous and can be replaced with 1-3 lines directly combining the other two scripts.

I do not have OpenSSL, so I can't completely test these, but the following examples should work:

Get the certificates from multiple remote hosts using a comma-separated string, array, or file, and dump it to JSON.
Get-RemoteCertificate "google.com, reddit.com" | ConvertTo-Json > $JsonPath
Get-RemoteCertificate google.com, reddit.com | ConvertTo-Json > $JsonPath
Get-Content $HostFile | Get-RemoteCertificate | ConvertTo-Json > $JsonPath

Create new CSRs in the default directory (relative to the current working directory) for all hosts listed in a file with expiration dates in the next 30 days.
# "30.0:0" == "30 days. 0 hours : 0 minutes"
Get-Content $HostsFile |
    Get-RemoteCertificate |
    Where-Object ExpiresIn -lt '30.0:0' |
    New-CertificateSigningRequest

Get certs, dump them to JSON, and generate new CSRs for about-to-expire certs.
$Certs = Get-RemoteCertificate $Domains
$Certs | ConvertTo-Json > $JsonPath
$Certs | Where-Object ExpiresIn -lt '30.0:0' | New-CertificateSigningRequest

If this were to be built and installed (for example using PSDeploy), you could import the module by name, or because there is a PSD1 file listing the exported function PowerShell would know to import this module automatically.

Following advice from commenters, perhaps you were one of them, I've been refactoring this today myself by changing the scripts to to function, placing each function into its own ps1 file in a Scripts folder (ModuleName/Scripts), and then having the module import each ps1 from the Scripts folder. I've also been making a number of other changes that were recommended. I've created a new "develop" branch, and moved the commit there, Thank you for participating.


Memory Leak

I'm researching a memory leak with App. At this point I assume it's in the Renderer based on this:
When I load the TV Grid I have an equal number of ElementNodes (my solid nodes) as Renderer Nodes (Core + Text)

As I navigate a TV grid, creating and removing dozens of nodes per row I end up with roughly the same element nodes as I started with, but the Renderer Nodes are in the thousands. I am calling node.destroy() on the parent node...

PS - I disabled animations and inspector so I don't think those are affecting things. This is with Nodes with children SDF text nodes as well.

I've tested on the solid demo app - went back to version 0.6 and still have a leak with calling destroy() on the lng node.

Way more Renderer nodes than ElementNodes from Solid

I've tracked down a related issue. The emit events are not being cleaned up on all the children nodes. I'm not sure if they are in coreNode. But all textNodes have an on('loaded') listener. When I delete the tree those are still there and not being cleaned up. I see MainCoreNodes is removing listeners but I'm not sure if they also exist on CoreNode?


TypeError: 'type' object is not subscriptable on Running an instance

I am running the test app and run the following issue on app start
class FileMetadata(BaseModel):
  File "/Users/elijahmwangi/Library/Python/3.8/lib/python/site-packages/tusserver/metadata.py", line 8, in FileMetadata
    metadata: dict[Any, str]
TypeError: 'type' object is not subscriptable

The major issue its running it with python3 i believe

Can you share the library version you are using?

@ElijahGM you can try a fix with the latest version: https://pypi.org/project/tuspyserver/1.3.1/


502 Bad Gateway

Across all images, homepage is up but reading 0 images served etc.

Yea, it's been like this for at least 2 days.

And today again...


Serializing Timestamps/Dates embedded in a "$date" field

First thanks for implementing this SMT!
Have just tried to use it for serializing an Avro message to an Oracle table as JSON and timestmap as well as time and date types are serialized embedded in a $date field as shown here (I'm using the default RELAXED output mode:
{"order":
  { "guid": "cd38f167-37bd-494a-b065-fb35133b1e7b",
    "id": 0, "orderDate": {"$date": "2022-12-03T10:22:28.614Z"},
    "localOrderDate":<PHONE_NUMBER>616, "customerId": 2,
    "orderLines": [{"lineId": 1, "productId": 12, "quantity": 10}, {"lineId": 2, "productId": 20, "quantity": 5}, {"lineId": 3, "productId": 10, "quantity": 1}],
    "createdDate": {"$date": "2022-12-03T00:00:00Z"},
    "createdTime": {"$date": "1970-01-01T11:22:28.616Z"}
 }
}

The problem with that is, that I couldn't figure out a way to access it in Oracle using the JSON_TABLE function. It would be better to have it serialized as "orderDate": "2022-12-03T10:22:28.614Z".
Found a way to change the conversion to date by specifying a custom converter: https://www.baeldung.com/java-convert-bson-to-json#custom-bson-to-json-date-conversion.
Have implemented it as a proof-of-concept locally and it works.
Would you be interested to include it in your SMT? If yes, I can provide it as a pull request.

FYI: just realized that the $date embedding is related to using the logical types in Avro for dates and timestamps. Will create a separate Pull Request with the Record2JsonStringConverterTest unit test enhanced with logical types.

Hi!
I never faced this issue before but I think it's because we didn't use the logical Types in Avro we just used epoch timestamps without any further metadata and therefore it was also written to the JSON as INT64.
One alternative might be to chain the TimestampConverter (https://docs.confluent.io/platform/current/connect/transforms/timestampconverter.html#properties)  before the tojsonstring smt.  So you can transform the avro epoch to a datetime string before the transformation to JSON is done and it is transformed to json as normal string.
If you have a PR that adds this configurable to the SMT I'm happy to merge it.

Hi
Thanks for your repsonse. You are right, using the TimestampConverter before your SMT should work. Will try that as well and then decide if it would still make sense to include similar functionality in your SMT.
Have just created a PR for the enhancement of the unit test to include the logical types.

Thanks for the PR with the unit test enhancement. I'll close this issue. If you have more PRs feel free ;)

@an0r0c  thanks for merging, just sent you a PR with the changes to support handling the logical types. Tried to use the TimestampConverter yesterday, but it does not work for me, as my date fields are nested inside a nested Avro record (nested object) and using SMT for nested fields are not yet supported (found that there is KIP-821 to support that in the future). That's why I decided to add the logic to your SMT. Just let me know if you have any questions or comments on the implementation.


ps:restartall not a valid replacement for deploy:all

Loosely related to https://github.com/progrium/dokku/issues/82 etc.
deploy:all is marked as deprecated and just calls out to ps:restartall, however as far as I can tell deploy:all (i.e. the old implementation that literally called deploy for each app) was necessary functionality.
ps:restartall doesn't setup $APP/IP and $APP/PORT etc.
In my case, I've just tried to upgrade from v0.3.9-33-gf1bfb3e. Ramblings: My fifth attempt actually - as pretty much anything that could have broken, has broken e.g DOCKER_OPTIONS has become DOCKER_OPTIONS_$PHASE and been officially integrated, so I had to copy my files manually. The old dokku-logging-supervisord plugin I had installed forks processes infinitely against the new buildstep etc. To be fair, these are/were all third-party plugins, but it does highlight the need to stabilise the plugin API etc. (I think my dokku-graduate plugin may have broken as well).
Anyway, this particular issue seems to be with Dokku itself, as opposed to a plugin. Upon upgrading all my containers were shut down - fair enough. But they didn't start back up (3 of 8 did...?). This is when I attempted to perform:
sudo dokku deploy:all

Which didn't work, but yet specifically calling:
sudo dokku deploy <app>

for each app some apps allows them to deploy (well, sort of - the docker containers haven't had their ports exposed/mapped, still looking into that).
Anyway, dokku ps:restartall wasn't sufficient because it doesn't create $APP/IP etc. Which in my case don't exist at all because that file wasn't around in v0.3.9-33-gf1bfb3e.
It would seem to me that deploy:all should stick around (and in its previous form, where it actually deploys) - unless I'm totally missing something (very possible).

Hmm, interesting.
dokku ps:restartall:(https://github.com/progrium/dokku/blob/713a8d4f312d03f3c7ef0a7dc0c08eeaab917150/plugins/ps/commands#L92-L97)
calls dokku ps:restart: (https://github.com/progrium/dokku/blob/713a8d4f312d03f3c7ef0a7dc0c08eeaab917150/plugins/ps/commands#L82-L90)
on all apps that have been deployed. (i.e. have a CONTAINER file)
which then calls release_and_deploy(): https://github.com/progrium/dokku/blob/713a8d4f312d03f3c7ef0a7dc0c08eeaab917150/plugins/ps/commands#L5-L24
that runs dokku release $APP and dokku deploy $APP
This will subsequently yield running apps and the aforementioned $APP/IP etc.
root@dokku:~/dokku# dokku apps
=====> My Apps
node-js-app
static-rails-app

root@dokku:~/dokku# dokku ps:stop node-js-app
Stopping node-js-app ...
root@dokku:~/dokku# dokku ps:stop static-rails-app
Stopping static-rails-app ...

root@dokku:~/dokku# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

root@dokku:~/dokku# rm /home/dokku/*/IP
root@dokku:~/dokku# ls -l /home/dokku/*/IP
ls: cannot access /home/dokku/*/IP: No such file or directory

root@dokku:~/dokku# dokku ps:restartall
-----> Releasing node-js-app ...
-----> Deploying node-js-app ...
...
=====> Application deployed:
       http://node-js-app.dokku.me

-----> Releasing static-rails-app ...
-----> Deploying static-rails-app ...
...
=====> Application deployed:
       http://static-rails-app.dokku.me

root@dokku:~/dokku# docker ps
CONTAINER ID        IMAGE                           COMMAND             CREATED             STATUS              PORTS               NAMES
9735cdc18946        dokku/static-rails-app:latest   "/start web"        3 minutes ago       Up 3 minutes                            agitated_ptolemy
b3ede1fba432        dokku/node-js-app:latest        "/start web"        4 minutes ago       Up 4 minutes                            dreamy_hypatia

root@dokku:~/dokku# ls -l /home/dokku/*/IP
-rw-r--r-- 1 dokku dokku 12 Apr 29 17:47 /home/dokku/node-js-app/IP
-rw-r--r-- 1 dokku dokku 12 Apr 29 17:48 /home/dokku/static-rails-app/IP

Point being that deploy:all and ps:restartall are actually doing the same thing and I can't replicate the issue. Any additional info is welcome.

Okay, I've found the real problem. It's related.
I killed all the docker containers than ran:
$ sudo dokku ps:restartall
-----> Releasing analytics ...
-----> Injecting Logging Supervisor ...
supervisor is already installed (skipping apt-get update/install)
-----> Deploying analytics ...
-----> Running pre-flight checks
-----> Running post-deploy
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   131    0   104  100    27    186     48 --:--:-- --:--:-- --:--:--   187
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    17  100    17    0     0     45      0 --:--:-- --:--:-- --:--:--    45
-----> Configuring analytics.snaploader.com...
-----> Configuring analytics.snaploaderdev.com...
DOKKU_APP_LISTEN_PORT: 5000
DOKKU_APP_LISTEN_IP: <IP_ADDRESS>
-----> Creating http nginx.conf
-----> Running nginx-pre-reload
       Reloading nginx
nginx: [emerg] host not found in upstream "renet-monitor" in /home/dokku/renet-monitor/nginx.conf:6
nginx: configuration file /etc/nginx/nginx.conf test failed

Which results in:
$ sudo docker ps
CONTAINER ID        IMAGE                    COMMAND             CREATED             STATUS              PORTS               NAMES

Where renet-monitor's nginx.conf looks like:
server {
  listen      [::]:80;
  listen      80;
  server_name renet-monitor.snaploader.com ;
  location    / {
    proxy_pass  http://renet-monitor;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection upgrade;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Request-Start $msec;
  }
  include /home/dokku/renet-monitor/nginx.conf.d/*.conf;
}

It is missing an upstream definition. After debugging this because DOKKU_APP_LISTEN_IP is undefined due to /home/dokku/renet-monitor/IP not existing - hence my original assessment.
Calling dokku deploy renet-monitor actually does resolve the problem (for this particular app anyway).
The real issue is that $APP/IP, $APP/PORT etc. are populated for one app, then that app is deployed, then we repeat for the next app. However, the nginx config is left in a bad state so ps:restartall fail to deploy and bails out. As such it would seem we need to generate all these files first in one go, before actually deploying any instances.
Strangely, at the moment most my $APP/IP files have the same value, 5000, in them... probably which my containers port binding isn't working. I'll continue looking into that, it's quite possibly related.

What version are you on?

$ dokku version
v0.3.17-55-g713a8d4

Oh, to clarify the:
DOKKU_APP_LISTEN_PORT: 5000
DOKKU_APP_LISTEN_IP: <IP_ADDRESS>

was some logging I added. Everything else is stock v0.3.17-55-g713a8d4

Oh I see, validate_nginx is bombing on the nginx config for renet-monitor when deploying analytics. The question is how did the renet-monitor nginx config get hosed....
Now that you have them both working, does a ps:restartall work for you?

It got hosed on reboot, the nginx conf was invalid. We need to generate them all before reloading/restarting nginx.

But how did it get hosed on reboot? Also :+1: on validate & restart after all configs are built.

Docker doesnt persist the bound ports when it starts up again, so containers get new ones.

But nginx -t would have passed, no?

Oh hmm probably right. How did they get hosed?

They're not hosed in-so-far as they are old. I've just attempted to update from an old version of dokku, where nginx.conf didn't have (or require) an upstream definition (or $APP/IP files).

Wait no, that can't be right, well not entirely. upstream was already required.
I must have nginx:build-config ran at some stage (which would have stripped upstream due to $APP/IP not existing)  when I realised my containers (the few that started) ports weren't binding. ps:restartall does seem a bit fragile in its current form.
I'm still going to have to look into what is going on with the port binding. I've got snapshots of this server (it's a non-production environment). So I'm going to roll-back and nail-down this upgrade process exactly before I do it in production.

Alright, so the reason my ports weren't being exposed is because I have a VHOST file, basically I didn't realise the behaviour had changed to use internal IP addresses for upstream instead of ports (as was made the case in https://github.com/progrium/dokku/commit/948d7902f22c60dd9ba952306f8a6d75a7efe729) when a VHOST file is specified.
Of course I should have just been able to visit any of my apps URLs and I would have seen they were accessible... but, they weren't. For some reason nginx was in some wacky state where it kept taking me to default host (nginx default webpage). I tried restarting nginx, but my apps still weren't accessible. I noticed when I stopped nginx its worker processes kept running. So I killed those manually then started nginx again and everything was then accessible as it should be.
Heading to bed now. But when I get up I'm going to rollback my server and run through the upgrade process again keeping in mind what I've learnt and hopefully report back specifically what is breaking during the upgrade.

Alright, finally got around to running the upgrade again from scratch. Something funky is definitely happening.
After the upgrade only 3 of my 8/9 containers are running. So I try dokku ps:restartall and one of my apps fails on pre-flight checks (and ps:restartall bails out). Specifically tracked it down to the PORT env var not being specified (which causes my app to fail because it doesn't have a port to bind to).
Then, the really peculiar thing is if I then run dokku ps:restart renet-monitor (the app that failed), the app boots up just fine.
So, then I try run dokku ps:restartall again (because a few apps still weren't running yet), then BAM! The exact same error with PORT being undefined for renet-monitor again.
I've put up an annotated gist that contains the exact commands I entered:
https://gist.github.com/Benjamin-Dobell/47ed874bacd00172183c

What version are you upgrading from?

@josegonzalez It's all in the gist:
$ dokku version
v0.3.9-33-gf1bfb3e

Can you gist some specs on your apps? Which buildpacks, config files, etc.?

Is there something specifically that you're after. There's 8 apps but every one of them is ruby. I think some of them have multiple buildpacks. However, the one that failed above (renet-monitor) is just ruby:
$ cat buildpack_version
v129
$ cat buildpack_ruby_version
ruby-2.1.2

However, I just ran ps:restartall`` again, and it proceeded past renet-monitoronly to fail on another app,tiles```. Again plain ruby, has the exact same build-pack and ruby version (out of date ruby is actually my primary reason for updating dokku/buildstep). Both apps are actually among the simplest of the apps deployed, just simple Sinatra apps.
With regards to the renet-monitor failures, It's almost like there is some sort of obscure race condition happening within docker itself. Like there is a possibility the processes are launched before the environment (specifically env vars) have been set.
Oh, I put some logging in dokku before the most recent ps:restartall where renet-monitor started but tiles failed; tiles was executed like:
docker run -d -e PORT=5000  -v /var/log/dokku/tiles:/var/log/app --env-file=/home/dokku/tiles/DOCKERFILE_ENV_FILE dokku/tiles

But, I can't look at the logs, I go:
$ sudo docker logs `cat /home/dokku/tiles/CONTAINER`
/bin/bash: /start: Permission denied

Inspecting the container shows a blank log file path :confused:
https://gist.github.com/Benjamin-Dobell/ec48a9b06c7133bc101f
I'm really lost as to how everything gets so broken. This is reproducible though, I just roll-back my snapshot and repeat the process and I end up in the same spot.
I can probably rebuild my apps, and hopefully they launch then. However, this is UAT, I'm trying to come up with a bullet-proof 100% understood upgrade-path so I can do this in production with minimal downtime.

Wait, hrm...
I just realised, the command I logged that launched the tiles docker container, it doesn't have a /start command. How strange.

Is there a Dockerfile in that repo?

No, just a Ruby Procfile like all the other apps I'm running. I'm going to insert a bit more logging in dokku and see why START_CMD ends up blank.

Alright, for ```tiles``:
sudo docker run --entrypoint="/bin/bash" --rm "dokku/tiles" -c "[[ -f /exec ]]"

This returns 1. Presumably because tiles was built with an old buildstep, it has /start and no /exec.
So it would seem this particular functionality of dokku is tightly coupled with a particular buildstep version. Is that intended?

Does an upgrade not rebuild buildstep? I know when you do deb-based installs, it pulls the absolute latest buildstep code and rebuilds the docker image for it.

@josegonzalez I saw buildstep pull down and I believe it updates the base Dokku docker image, however it doesn't rebuild the apps. I assumed this was an intentional choice in order to minimise down-time when upgrading.
By the way guys, thank you so much for your help so far, and of course for Dokku itself.
Only time I've had problems with Dokku is when it comes to upgrading (in the past and now). Last time I just more or less muddled around rebuilding, deploying, upgrading plugins etc. until I got things working. However, this time I'm trying to be a bit more analytical about the process in hope I can identify the pain points and hopefully improve the experience for others.

Maybe our upgrade instructions should have a ps:rebuildall instead of ps:restartall?

I imagine tightly coupled breaking changes between the containers and Dokku don't happen too often.
However, I guess now that Dokku is coming down from apt-get you'd want to automate the rebuilding (rather than requiring a user action at all). Otherwise, users will go to update their whole system and perhaps their dokku apps will suddenly fail to boot.

Probably worth placing in here under both abort-upgrade and configure?

I think there might be more to it actually...
My apps are rebuilding now I'll report back shortly. However, I believe there is a potential issue regarding Ubuntu deb packages no longer being available if you update the docker base image.

What do you mean?

Woh, unrelated, apparently PORT for lots of my apps at the moment. They just weren't failing pre-checks like renet-monitor was. Although I still think it's some sort of weird race condition, because renet-monitor's PORT was defined and it's up and running just fine.

What do you mean?

I have a real-world example because I ran into it a couple of days ago with my last update attempt (I mostly got things working in the end but wasn't sure exactly what I did due to all the messing around).
Anyway, one of my apps has a dependency on libavcodec.53, which was available in the Ubuntu 14.04 package repository. However, it's now marked as deleted.
I could deploy all I wanted and deploy and rebuild my app just fine using the old buildstep version. However, when I updated buildstep is must have pulled down the latest 14.04 repository, where libavcodec53 no longer exists (instead there's only libavcodec54).
Of course this proved to be a royal pain in the arse so I had to rebuild my native code libraries to utilise libavcodec54 instead of libavcodec53 so that I could deploy them to the updated Dokku (with the updated buildstep docker image). But the point is that my app was 100% stable and safely redeployable until I updated buildstep and rebuilt - which is precisely what we're talking about automating.
If we automate that then people may have the same problem as before (except it's even more confusing), whereby all they did was update Dokku and suddenly their containers went down and aren't coming back up.
Ideally I think it would be best to not rebuild people's apps automatically, as you're changing the underlying system, and their app may suddenly break. So rebuilding should be an explicit task. But then again, updating Dokku from apt-get also shouldn't cause their containers to go down and not come back up.
The best solution I can think of is simply to ensure Dokku is not tightly coupled with a particular buildstep container version. That means two things:

We can't make assumptions about files like /exec existing, we need an abstraction/API.
When the abstraction/API inevitably does need to change to support new functionality, then you'll need to release a different dokku package (so that system updates don't ever pull down breaking changes). e.g. dokku2, dokku3 etc.

That's a lot of work, but unfortunately I think it's the only truly safe way to handle the situation.

Buildstep is unfortunately not versioned, so I can't be like "we need at least X version" or similar (which would help with our own versioning). I'm curious to see where we broke bc between 0.3.9 and 0.3.17 (we've been pretty good about that) regarding /exec existing.

I'm not at all very familiar with how buildstep, cedarish etc. work. Is it possible to tie each Dokku version to a particular commit in buildstep?

Probably. Not sure how that would help you in this case though.

Oh, I'm pretty screwed for now... I've come to accept that :stuck_out_tongue: The fact a package can be completely removed from a repository seems pretty crazy to me, ah well.
I'm more thinking long-term; just a way to formalise any tight coupling between dokku and buildstep, so dokku doesn't ever end up with a version of buildstep it's incompatible with etc.
Rebuilding the apps did at least resolve the /exec issue. I've now got the dependency problem I described (which is not really anything to do with Dokku, so that's fine). However, in addition to that I've still got this really obscure PORT env var undefined issue in most of my apps. This actually looks more like a weird Docker issue than anything else, but I'll keep digging.
So I guess the only confirmed "Dokku issue" at this point is that there was a breaking change with regards to the assumption that /exec should exist in buildstep based containers. Which we've established can be fixed with a rebuild, so "resolving the issue" might be as simple as making a note in the documentation.

Hmm, I have no idea how to debug this PORT issue, whenever I push a new app with some logging it seems to resolve the problem.
Is ps:rebuildall different in any significant ways than pushing a new build (deploying)?

ps:rebuildall just pushes the git repo on the dokku server back through the build/deploy process for all known apps.

Ugh, finally found out why my apps are complaining about undefined $PORT variables:
[supervisord]
logfile=/var/log/app/supervisor.log
loglevel=info
nodaemon=true

[program:web]
command=/exec bundle exec rackup -p $PORT
process_name:%(program_name)s
numprocs=1
autostart=true
autorestart=true
stopsignal=TERM
redirect_stderr=true
stdout_logfile=/var/log/app/genghis.%(program_name)s.%(process_num)02d.log

The supervisord plugin is trying to setup the processes in my Procfile, but the problem is the user of $PORT. It should already be substituted for 5000 at this point, or we should call through to a shell, because supervisord does not perform shell expansion on $PORT.
Some of my apps work because they don't directly use the $PORT variable in this command, instead they run shell scripts that then use the $PORT variable, where shell variable expansion works just fine.

I just use a different variable name. (ex. $NODE_PORT)

@michaelshobbs It's not new to Dokku, I do specifically want to use $PORT. The issue is dokku-logging-supervisord (which I updated along with Dokku) changed its syntax from:
/exec sh -c "${COMMAND}"
to:
/exec ${COMMAND}
The latter is incorrect.

Yeah I was involved in that testing. Something changed in buildstep that seemed to necessitate this change...

Yeah, I see the commit:
https://github.com/sehrope/dokku-logging-supervisord/commit/70f5ea273ec6dc5d2f809315fed6985779ecd913
Including "sh -c" works for me though. Although I do definitely know that something in that commit was necessary, because without updating I encountered the endless forking problem - took me a good while to work out what was happening.

It's probably worth noting that dokku-supervisord calls out to a shell, and that plugin does seem to be well maintained (recent commits) - never used it though:
https://github.com/statianzo/dokku-supervisord/blob/master/post-build-buildstep#L46

Just in case anyone runs into similar problems, my final upgrade process was exactly the following:
sudo su

cd /var/lib/dokku/plugins

# Remove docker-options, because it's now part of Dokku
rm -rf docker-options

# Unnecessary plugin
rm -rf dokku-rebuild

# Need to update dokku-logging-supervisord or it will cause in infinite loop with the latest buildstep/cedar
# Using a fork because Procfile ENV variable expansion is broken on master, also have
# one other tweak regarding log naming so the logs play nice with services like papertrail
cd dokku-logging-supervisord
git remote set-url origin https://github.com/glassechidna/dokku-logging-supervisord.git
git fetch origin
git reset --hard origin/master
cd ..

# Can't remember why exactly, but needed to update dokku-apt, again forked to meet out needs
cd dokku-apt
git remote set-url origin https://github.com/glassechidna/dokku-apt.git
git fetch origin
git reset --hard origin/master
cd ..

# Latest docker-options has a DOCKER_OPTIONS file for each phase (we want RUN & DEPLOY)
sudo -u dokku bash
cd /home/dokku
for D in *; do
  if [ -d "${D}" ]; then
    pushd "${D}"
    if [ -f "DOCKER_OPTIONS" ]; then
      mv DOCKER_OPTIONS DOCKER_OPTIONS_RUN
      cp DOCKER_OPTIONS_RUN DOCKER_OPTIONS_DEPLOY
    fi
    popd
  fi
done
exit

# Update Dokku
cd /root/dokku/
git pull --tags origin master
make install

# dokku ps:rebuildall won't work straight away because each app depends on every other
# app having a valid nginx.conf before it will launch. When one app fails, ps:rebuildall
# just gives up, so we manually fix the nginx.conf of each app (even though only the last
# app will end up deploying correctly)

cd /home/dokku
for D in *; do
  if [ -d "${D}" ]; then
    dokku deploy ${D}
  fi
done

# Now we have valid nginx.conf for all apps, we need to rebuild the apps using latest
# buildstep and launch them.
dokku ps:rebuildall

# Not sure why but orphaned nginx worker processes stick around when dokku restarted
# nginx. We need to specifically kill them:
# NOTE: Perhaps I ran ```sudo service start nginx``` instead of init.d and that causes
# problems... but I can't remember.

/etc/init.d/nginx stop
ps aux | grep nginx | cut -d " " -f 2 | xargs kill -kill
/etc/init.d/nginx start

docker ps

##
# Then manually kill any stray containers with:
# docker stop <container-id>
##

exit

There were a few little hiccups I ran into, nginx.conf issues etc. However, I'll close this issue (as it's pretty large) - if there's anything specific that came from this issue I guess someone can create a new issue about it in particular.

NOTE: Whilst the process above upgraded dokku, it did not update my buildstep docker image - or install from a deb package like the documentation indicated it would, see issue https://github.com/progrium/dokku/issues/1165


Add from_clients for use directly from redis clients.

Partly addresses #7, but this works with a client directly rather than a connection.

Thanks again @FireMasterK


TR dnschallenges: exception when regexp doesn't match the xmlId

This Bug Report affects these Traffic Control components:

Traffic Router

Current behavior:
Exception when DS regexp doesn't match the xmlId. Certificate not created.
WARN  2021-08-10T15:37:49.750 [pool-2-thread-1] com.comcast.cdn.traffic_control.traffic_router.core.ds.LetsEncryptDnsChallengeWatcher - Failed updating dns challenge txt record with data from https://${toHostname}/api/2.0/letsencrypt/dnsrecords/:
java.lang.NullPointerException
	at com.comcast.cdn.traffic_control.traffic_router.core.ds.LetsEncryptDnsChallengeWatcher.updateStaticEntries(LetsEncryptDnsChallengeWatcher.java:152)
	at com.comcast.cdn.traffic_control.traffic_router.core.ds.LetsEncryptDnsChallengeWatcher.lambda$useData$0(LetsEncryptDnsChallengeWatcher.java:85)
	at java.util.ArrayList.forEach(ArrayList.java:1259)
	at com.comcast.cdn.traffic_control.traffic_router.core.ds.LetsEncryptDnsChallengeWatcher.useData(LetsEncryptDnsChallengeWatcher.java:59)
	at com.comcast.cdn.traffic_control.traffic_router.core.util.AbstractResourceWatcher.loadDatabase(AbstractResourceWatcher.java:108)
	at com.comcast.cdn.traffic_control.traffic_router.core.loc.AbstractServiceUpdater.updateDatabase(AbstractServiceUpdater.java:117)
	at com.comcast.cdn.traffic_control.traffic_router.core.loc.AbstractServiceUpdater$1.run(AbstractServiceUpdater.java:86)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

Expected behavior:
Let's Encrypt certificate created
Steps to reproduce:

Create a new DS
Change the Regexp so it doesn't match the xmlId
Snapshot, verify DS is working
Add a Let's Encrypt SSL certificate
Watch for Exceptions in the log

@smalenfant can you make sure to add component labels as well to your issues?


Gelf logging driver never passes newlines ('\n)

Description
In case of using gelf as the logging driver, it will never get newlines which makes it not usable because you can't show the logs formatted correctly to users.
Steps to reproduce the issue:
I am using this as my gelf server: https://github.com/wavded/graygelf
var gelfserver = require('graygelf/server');
var gelfServer = gelfserver();
gelfServer.on('message', (gelf) => {
    console.log('received message', gelf.short_message);
});
gelfServer.listen(5001);

Run this on your localhost
Create a new container and attach the gelf server above as the logging driver:
docker run --log-driver=gelf --log-opt gelf-address=udp://localhost:5001 ubuntu bash
Run a command that generates multiple lines:
bash -c "for i in {1..5}; do echo hello; done"
Debug the gelf server and see that every short_message will only contain \r but never a \n.
for example: "hello\r".

Output of docker version:
Client:
 Version:      1.12.0
 API version:  1.24

This is because a log entry is generated for each line, delimited by \n. The \n is stripped when sending those log entries. You can get the original output back again by joining the log entries with a \n

You are right. Every time a message is received i should address is as a newline.
The other problem this generates is that i don't receive anything until a newline is reached.
For example if i do 'docker pull' then i will only get an event to the gelf server after the layer has finished. This means that gelf is not a good choice if you want to live stream the output from your containers.

The same applies to all logging drivers in Docker. There's no way for docker to decide when to send a new log entry, other than using a newline for that. Afaik, that's how most logging systems work, but perhaps @cpuguy83 can fill me in on that one

If that's how all the logging drivers work, than how does the cli knows how to show a docker pull command correctly?
It must read the messages from the json driver, this means that messages that only contain '\r' must be in the file before an end of a line.
Am i wrong?

Docker pull is not sent over the logging driver (unless you're running docker-in-docker); the logging drivers only send stderr/stdout from the container's process. Docker pull information is sent back to the client through the remote API
To get "real time" output  from a container, you can always run the container in the foreground, and attach to it.

See this endpoint for pulling an image: https://docs.docker.com/engine/reference/api/docker_remote_api_v1.24/#/create-an-image

You are right @thaJeztah.
Thanks a lot for clarifying this for me.
I am closing this.


Can't create retina sprite

I'm trying to create a retina sprite with this gulp task:

gulp.task('t_sprite', function () {
  var spriteData = gulp.src(imgDir+'*.png')
  .pipe(debug({title:"png : "}))
    .pipe(spritesmith({
      retinaSrcFilter<EMAIL_ADDRESS>      imgName: 'sprite.png',
      retinaImgName<EMAIL_ADDRESS>      cssName: 'sprite.styl'
    }));
  return spriteData.pipe(gulp.dest(Sprite_Styl));
});

When I run the task, it gives me this error:

[02:09:16] "t_sprite" errored after 37 ms
[02:09:16] Error: Retina settings detected but 0 retina images were found. We have 17 normal images and expect these numbers to line up. Please double check "retinaSrcFilter".
    at DestroyableTransform.onEnd [as _flush] (/var/www/node_modules/gulp.spritesmith/lib/gulp-spritesmith.js:145:19)
    at DestroyableTransform.<anonymous> (/var/www/node_modules/readable-stream/lib/_stream_transform.js:115:49)
    at DestroyableTransform.g (events.js:291:16)
    at emitNone (events.js:86:13)
    at DestroyableTransform.emit (events.js:185:7)
    at prefinish (/var/www/node_modules/readable-stream/lib/_stream_writable.js:503:12)
    at finishMaybe (/var/www/node_modules/readable-stream/lib/_stream_writable.js:511:7)
    at endWritable (/var/www/node_modules/readable-stream/lib/_stream_writable.js:523:3)
    at DestroyableTransform.Writable.end (/var/www/node_modules/readable-stream/lib/_stream_writable.js:493:41)
    at DestroyableTransform.onend (/var/www/node_modules/readable-stream/lib/_stream_readable.js:504:10)

Process finished with exit code 1

This is a duplicate of #64. The issue in the configuration is retinaSrcFilter is an array when it should be a string. The following config should work:
gulp.task('t_sprite', function () {
  var spriteData = gulp.src(imgDir+'*.png')
  .pipe(debug({title:"png : "}))
    .pipe(spritesmith({
      retinaSrcFilter<EMAIL_ADDRESS>      imgName: 'sprite.png',
      retinaImgName<EMAIL_ADDRESS>      cssName: 'sprite.styl'
    }));
  return spriteData.pipe(gulp.dest(Sprite_Styl));
});

#64 , #121  -  no, it's not working
here is my test file, please look at the files
https://github.com/SnisarOnline/examples

sorry for bad English
can I get a working example.
I tried a lot more options than what is indicated in the files and not one worked

Sure thing, I will rephrase my explanation as well. Retina spritesheets, also known as 2x spritesheets, are for showing better image quality on devices that support it. For example, a Macbook Pro and iPhone have retina displays which can show better image quality.
We support generating retina spritesheets in gulp.spritesmith via parameters like retinaSrcFilter and retinaImgName. Currently, the example you provided has these parameters set so it is attempting to generate retina spritesheets. However, it's not finding any retina images to generate the retina spritesheet with.
As a result, I'm assuming you are accidentally using these parameters and only want to generate a normal spritesheet at this time. To correct our gulpfile.js, we should have the following configuration:
gulp.task('t_sprite', function () {
  var spriteData = gulp.src(imgDir+'*.png')
  .pipe(debug({title:"png : "}))
    .pipe(spritesmith({
      imgName: 'sprite.png',
      cssName: 'sprite.styl'
    }));
  return spriteData.pipe(gulp.dest(Sprite_Styl));
});

This configuration doesn't include the retina parameters retinaSrcFilter and retinaImgName. As a result, it will not attempt to generate a retina spritesheet.

so, the software does not Create "retina image".
the software USE the ALREADY Created "retina images". and create "sprites"
I right understand ?

That is partially correct. The concept is correct but the terminology is incorrect. The software uses already created "sprites" (small images) and then creates "spritesheets" (all images in one image).
To create retina images, you must generate those from your source (e.g. Photoshop, Illustrator). If you would like to automate creating normal images from retina images, then this can be done via other plugins such as:

https://www.npmjs.com/package/gulp-unretina/
https://www.npmjs.com/package/gulp-image-resize/

thanks for the clear explanation.
And I am sorry for the trouble


Make warnings fatal in CI

Closes #1064
This setting is controlled via the environment variable
APALACHE_FATAL_WARNINGS, making it possible for developers to opt in
or out of having compiler warnings fail their builds locally.
Instructions on configuration have been added to CONTRIBUTING.md

[x] Ran make fmt-fix (or had formatting run automatically on all files edited)
[x] Documentation added for any new functionality

Here's proof that the new settings will cause CI to fail on compiler warnings:

Codecov Report

Merging #1542 (02bff18) into unstable (3099a3d) will increase coverage by 0.01%.
The diff coverage is n/a.

:exclamation: Current head 02bff18 differs from pull request most recent head 41bfd03. Consider uploading reports for the commit 41bfd03 to get more accurate results

@@             Coverage Diff              @@
##           unstable    #1542      +/-   ##
============================================
+ Coverage     74.96%   74.98%   +0.01%
============================================
  Files           359      359
  Lines         11514    11514
  Branches        540      540
============================================
+ Hits           8632     8634       +2
+ Misses         2882     2880       -2

Impacted Files
Coverage Δ

...he/io/annotations/parser/CommentPreprocessor.scala
96.70% <0.00%> (+1.09%)
:arrow_up:

.../forsyte/apalache/tla/pp/ConstSimplifierBase.scala
97.64% <0.00%> (+1.17%)
:arrow_up:

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 3099a3d...41bfd03. Read the comment docs.


Missing locked specs should not block installation.

Hey @indirect,
I finally got around to reproducing this issue ( https://github.com/bundler/bundler/pull/4172#issuecomment-185566638 ) in a minimal ruby project ( https://github.com/drn/bundler-locals-issue-project ). There are instructions in the README.
Basically both bundle install and bundle update gem raise the exception:
https://github.com/drn/bundler-locals-issue-gem (at TA-1000@d8a205d) is not yet checked
out. Run `bundle install` first.

I dug into the bundler source code and traced the exception to this line:
https://github.com/bundler/bundler/blob/master/lib/bundler/definition.rb#L483
The issue arises if there are no other dependencies in the project that are unlocking. All the other conditions are false, so source.specs != locked.specs triggers. source.specs returns a Bundler::Index instance. However, locked.specs raises an exception.
The exception that's raised is in https://github.com/bundler/bundler/blob/master/lib/bundler/source/git.rb#L192. The error message is:
The path/Users/darrencheng/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/bundler/gems/bundler-locals-issue-gem-d8a205d072a3does not exist., which in turn raises a GitError which isn't handled in the specs_changed? method.
The changes in this pull request patches the issue, but maybe there is a better fix for the issue? Potentially ensuring unlocking = true if a GitError is raised?

Please add a spec for this change?

Sure, I'll add one tonight

@segiddins - I've updated the commit to include specs that cover this issue. Let me know if you need anything else!

@indirect r?

I completely agree that "git repo is not checked out" is a bug, but I'm not sure that "git locals can be locked to non-existent branches and shas" should be the solution?
Why can't we get the gemspec from the locals repo, and validate against a branch or sha in the locals repo?

Hmm, maybe this is too broad of a patch.
To give you some background, my original use case is actually slightly different, though it's not reflected in the specs. I reproduced this error by having a lockfile that was pointing to an existent branch / sha. The install gemfile branch was then updated to another branch on a different sha in the git local.
I assumed that after I ran bundle install or bundle update gem-name, it would update the locked sha / branch to whatever the new branch was pointing to locally. However, I ran into the Run 'bundle install' first exception using both of the commands.
This pull solves my use case as well as the more general use case of when a lockfile is pointing to an invalid sha / branch.
I'm happy to help out with some code, but I'm not entirely sure what the desired behavior is. Can you clarify what the intended behavior is for these two commands:

bundle install

Having a more descriptive exception raised that indicates that the locked sha / branch don't exist or are different than the current branch / head sha makes sense. Is that what you mean by adding validations?

bundle update gem-name

Even if the lockfile sha is missing or the locked branch is different than the install gemfile branch, shouldn't the lockfile be updated to whatever the current head sha of the git local is?

:umbrella: The latest upstream changes (presumably #4618) made this pull request unmergeable. Please resolve the merge conflicts.

I think your usecase is now fixed by #4840! Thanks for reporting this.


minimum SceneView scale is smaller than minimum loadable scale

deserialization logic "corrects" the scale if it's too small, even though that size is allowed by SceneView itself. it might be worth finding a way to make sure these don't get out of sync with each other

resolved by https://github.com/HeladoDeBrownie/Nexus/commit/11ad75649fa48dd7fe75139ee8529f9f8d493d5d