Muilt-arch doesn't seem to work

Version
redhat-action/buildah-build@v2
Describe the bug
Using archs: amd64,arm64 I expect it to build amd64 & arm64 images (like the docs state), but the command that is run is incorrect according to the buildah docs (--arch takes only one argument but it is given two)
Steps to reproduce, workflow links, screenshots
https://github.com/vilgotf/voice-pruner/runs/3013577143

I think this is the same issue as https://github.com/redhat-actions/buildah-build/issues/24#issuecomment-792000579
Can you try pulling the image ahead of time?

Using matrix build doesn't work since that builds & pushes amd64 and then builds & pushes arm64 (overwriting amd64 instead of adding to it). Pulling the base images before issuing buildah bud ... resulted in the same error when running locally (F34, buildah 1.21.0)

OK, I see what you mean. I know we had some users in the past doing the comma-separated archs, but maybe it wasn't working and we/they just "thought" it was.
Try passing just one arch at a time, like you say the buildah docs specify, while I ask around.

So, it seems to me there are two issues here.

Passing multiple comma-separated arguments to arch.
As far as I can tell, you can pass anything to arch you like. It does not actually affect what architecture the image uses. You have to use the FROM clause to do that.

I used the following Containerfile for testing:
ARG ARCH=amd64
FROM ${ARCH}/alpine:3.14

RUN echo "hello world"

ENTRYPOINT [ "sh", "-c", "uname -a && echo -n 'Bits: ' && getconf LONG_BIT && echo 'goodbye world'" ]

then:
export ARCH=arm64v8
export TAG=quay.io/tetchell/buildah-multiarch:latest
buildah bud -t $TAG --arch $ARCH --build-arg ARCH=$ARCH -f Containerfile

[ /src/tetchel/buildah-multiarch ] 26 (main) $ podman run quay.io/tetchell/buildah-multiarch:latest
Linux 98c394deb27b 5.12.11-200.fc33.x86_64 #1 SMP Wed Jun 16 16:10:53 UTC 2021 aarch64 Linux
64
goodbye world

https://github.com/docker-library/official-images#architectures-other-than-amd64
I definitely agree with you that the README is terribly misleading and I will remove the comma-separated example, and replace "archs" with "arch" but leave the plural input intact (but undocumented) so as not to break existing users.

"overwriting amd64 instead of adding to it"

If you want multiple images referred to by the same tag, you have to use buildah's manifest feature. This is presently not supported by this action, so you would have to write a script for those steps yourself after building the images.
https://github.com/containers/buildah/blob/main/docs/buildah-manifest.md
There is a great breakdown of multi-arch support in this issue.
https://github.com/containers/buildah/issues/1590

Would be great if manifest could be added to this action! (I worked around this here)

Done in https://github.com/redhat-actions/buildah-build/pull/62


PRINTER_NOTIFY_INFO_DATA not documented correctly for 64bit

🛑 IMPORTANT: You can get your feedback addressed faster if you use the comment section for the article in which you encountered a problem.
Article does not contain comments section!
Link to article:
https://docs.microsoft.com/en-us/windows/desktop/printdocs/printer-notify-info-data
Tell us where exactly a problem occurs.
Problem:
Big error in documentation:
union {
    DWORD  adwData[2];
    struct {
      DWORD  cbBuf;
      union {
    DWORD  adwData[2];
    struct {
      DWORD  cbBuf;
      LPVOID pBuf;
    } Data;
  } NotifyData;pBuf;
    } Data;
  } NotifyData;

Explanation: LPVOID is an pointer to void. = IntPtr => is 64 bits in 64bit and 32bit in 32bit windows.
DWORD is an 32 integer. => THus DWord[2] => 64 bit, But LPVOID + DWORD = 96 bits.
In 64bit windows: Its actually a IntPtr[2] Array. (with space left over at the end i think, for data-alignment?)
Also some other property seems to take up 4 extra bytes (id or the reserverd property?) otherwise the marshaling of the data goes wrong.
No where on the internet a could find a proper 64bit example toi do this?!.

Hi @joelharkes --thank you so much for bringing this to our attention! We'll investigate and get back to you.

@ginami Wonder if this was ever picked up?


Create AWS CDK Script

Currently the functions are manually maintained. A proper CDK script should be made from the skeleton to allow easy deployment by everyone.

Done


Player scav never has red flares on their person

In live, player can find red flares in their scav inventory.

Originally written by chomp

Fixed with: https://dev.sp-tarkov.com/SPT-AKI/Server/commit/7bc867a8f74f96c6da7889a3f274bd55347ee386

Originally written by chomp

Ran back to back scavs off CD today testing and spawned with a labs keycard twice with a fence rep of 3
Drakia mentioned spawning with a red flare in discord as well

Attachments

image.png (17 KiB)
scavspwan.png (12 KiB)

Originally written by acidphantasm


Add integration tests

A lot of developers have problems with broken prisma-clients sometimes because there are no integration tests which will check if the generated prisma-client actually works.
We created this ticket because we had some problems and discussed possibilities to prevent those problems in the future.
The solution
The best solution would be to add integration test. These tests should include generating a prisma-client based on a more complex schema.graphql like in this project. After that the prisma-client should be successfully compiled. The test should fail when the compilation fails.
@divyenduz also recommended one thing we can also do:

we should add executing operations against a live Prisma service in the test suite to test prisma-client-lib part

Thanks a lot for bringing this up @sapkra ! We're sorry about this and are not happy with the quality, that we put up with the client right now. We're working on better tests for the Client in the coming week. Stay tuned. We'll keep this issue open for now until we have a substantially better test setup than now and have fixed the major issues in the client.

Added feature label to avoid stalebot


Request: Add support for pathlib.Path paths in type hints

The following code currently results in a hype hinting error:
from pathlib import Path

from markdown_pdf import MarkdownPdf, Section  # type: ignore reportMissingTypeStubs

pdf = MarkdownPdf()
section = Section('\# Hello World')
pdf.add_section(section)

file_path = Path('./output.pdf')
pdf.save(file_path)

Pathlib is the standard for path management in Python, and should be supported.

Added in version 1.3.2, please update your installation.

Looks great, thanks!


Create filtering for Orders page v1

Issue Goal: 📈 Make it easy to see different items and what items are selling
Create the following filters

[ ] Sort by highest and lowest order
[ ] By items

I can't do this issue because of the way I set up the Firestore data. This impacted my Orders page layout.
Instead, I added the total sales of each category at the top of the page.


Fix Schema should be updated when update_tmp_rowset in cloud mode

In cloud mode the updated rowset meta after rowset->merge_rowset_meta in BaseTablet::update_delete_bitmap will be lost in update_tmp_rowset.So in order to keep the latest schema we should keep schema in update_tmp_rowset

cloud tablet should also do copy_without_variant_extracted_columns

Proposed changes
Issue Number: close #xxx

run buildall

run buildall


Fix website horizontal scroll

Website has a horizontal scrollbar on operating systems (Windows etc.) that have permanent scrollbars.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@MattheousDT Where are you seeing this? Can you post a screenshot?

Firefox

Chromium

Note the horizontal scrollbar at the bottom. Happens regardless of window size

Thanks. This seems to be happening because of the width: 100vw on the canvas for particle.js.
@josh-collinsworth PTAL

Thanks. This seems to be happening because of the width: 100vw on the canvas for particle.js.
@josh-collinsworth PTAL

Will do. This looks good at a glance but I want to take some time to thoroughly test to make sure there aren't other side effects.

I have what I think is a more preferable implementation here: https://github.com/jsr-io/jsr/pull/134
It's the same fix/CSS, but just applied only to the homepage, just so we avoid any unforeseen side effects, or situations where we might want horizontal overflow.
Thanks for reporting and opening this!


Need a Wiki for what each script can do

some tweaks are confusing, dont know what they will remove or tweak . For ex. ownership and essential
Pls create a wiki about what does essential tweaks do.

Hey @pratyush-1327,
Thank you for suggesting that, i'll certainly try to add Wiki to this project!

For ex. ownership and essential

Take Ownership adds context menu item, that allows you to basically delete any system files you'd ever want to!

@teeotsa welcome!
For the mean time , i can just see the files what they do.
Thanks for taking this in consideration.


Add more languages

Add Slovak & Czech languages as it's my preference

Thanks for the contribution! I don't know if I will be able to make and release the build until next week though.

That's cool. thank you for the tool


switch out mgov details

👷 Deploy Preview for fancy-puffpuff-df775f processing.

Name
Link

🔨 Latest commit
51b678e52549f0769a22be77c4510bf7522ea825

🔍 Latest deploy log
https://app.netlify.com/sites/fancy-puffpuff-df775f/deploys/65a69d4673e0320008940eda


feat/pdf-page-limit-in-hi-res

Description:
Passing max_pages argument allows rejecting pdf files which exceeds this page number limit while high_res strategy is chosen. By default it will allow parsing pdf files with unlimited number of pages.
Testing:
from unstructured.partition.auto import partition

elements = partition(filename="unstructured/example-docs/pdf/reliance.pdf", strategy='hi_res')  # should pass
elements = partition(filename="unstructured/example-docs/pdf/reliance.pdf", strategy='hi_res', max_pages=4)  # should pass
elements = partition(filename="unstructured/example-docs/pdf/reliance.pdf", strategy='hi_res', max_pages=2)  # should raise PdfMaxPagesExceededError

This feels better suited for the API to me. A library user probably doesn't need this param, and if they do want to self limit their page count, they can implement this logic before in the caller. IMO this is breaking the abstraction that partition accepts a file input and just processes it.

This feels better suited for the API to me. A library user probably doesn't need this param, and if they do want to self limit their page count, they can implement this logic before in the caller. IMO this is breaking the abstraction that partition accepts a file input and just processes it.

But then we'd need to duplicate the logic that resolves auto strategy in the API code and load the PDF file (including the big ones) twice - in API and inside unstructured.

That's fair, and I guess it would be nice for each filetype to have its own page counting logic.

This feels better suited for the API to me. A library user probably doesn't need this param, and if they do want to self limit their page count, they can implement this logic before in the caller. IMO this is breaking the abstraction that partition accepts a file input and just processes it.

But then we'd need to duplicate the logic that resolves auto strategy in the API code and load the PDF file (including the big ones) twice - in API and inside unstructured - just to count the pages.
Additionally - this can serve as a "memory-and-time-keeper", not letting loading too big files.

I'm inclined to think Austin's initial thought here is quite right. This belongs in the API and not the open-source library.
We are already doing PDF file detection in the API for page-splitting purposes. File-type detection, at least of that type (like is it a PDF or TIFF) is trivial and may very well be required in the API, as it already is.
The big thing that partition() does is the dispatch of the partition call. No one is suggesting that be moved to the API. File-type detection is provided by detect_filetype() which can easily be called from there if absolutely necessary and in fact may need to be for other purposes.
But identifying a PDF is very easy to do very reliably.

@pawel-kmiecik can you provide a link to the "auto-strategy-resolver" code you're talking about?

Re: loading twice argument, we're already loading PDFs in the API to split pages, not sure I see the problem there.

Correct me, if I'm wrong @pawel-kmiecik, but the issue here is that we want to reject pdfs that exceeds page limit only when hi_res strategy is chosen at the end. Ofc if api calls provides hi_res as the strategy we can easily take care of potential rejection on api level, but if the auto strategy have been provided  unstructured deals with determining which strategy to choose, so to check it on api level we need to duplicate determine_pdf_or_image_strategy from unstructured/partition/strategies.py in api.

@pawel-kmiecik can you provide a link to the "auto-strategy-resolver" code you're talking about?

Here the strategy is resolved:
https://github.com/Unstructured-IO/unstructured/blob/main/unstructured/partition/pdf.py#L290

What's the rest of the plan for adding a new parameter? It would need to go in API (form-model), SDK, and documentation for both as well.
I'm less concerned with any performance impact for two reasons:

We can implement it such that there is no performance impact unless the API caller specifies a max_pages argument.
Counting pages, even in a large PDF is in the tens of milliseconds range. example-docs/DA-1p.pdf for example counts 619 in 0.071 seconds.

I expect the logic would look something like this:
def reject_for_too_many_pages() -> None:
    """Raises when PDF document exceeds caller-specified `max_pages` in non-fast mode."""
    # -- no limit when no max_pages not specified --
    if max_pages_arg is None:
        return
    # -- no limit on fast strategy --
    if strategy == "fast":
        return
    # -- only applies to PDFs --
    if not is_pdf:
        return
    # -- shorter PDFs are just fine --
    if pdf_page_count <= max_pages:
        return
    # -- non-fast strategy that resolves to fast is okay too --
    if detect_strategy() == "fast":
        strategy = "fast"
        return

    raise PdfTooLongError( ... )

Thinking through this you can see that the strategy-determination logic would never be invoked twice because:

it is only invoked here when the page-count is exceeded
test will fail if strategy resolves to non-fast
if it does resolve to fast we can change the strategy to fast and then detection logic won't be re-executed.

Just so you know where I'm coming from:

I'm strongly inclined to avoid adding new parameters to the open-source unless they clearly apply there. We already have a large number (50+) and that degrades the new-developer experience.
Violating responsibility boundaries for short-term optimization benefits is very expensive in the long run. It produces couplings across system boundaries that make reasoning about the assembled system, an already challenging job, more difficult, and in this case would add new concepts to partitioning as a whole, which are unnecessary for most partitioners. Those new concepts make partitioning incrementally more complex and we pay that incrementally increased maintenance cost indefinitely.

What's the rest of the plan for adding a new parameter? It would need to go in API (form-model), SDK, and documentation for both as well.
I'm less concerned with any performance impact for two reasons:

We can implement it such that there is no performance impact unless the API caller specifies a max_pages argument.
Counting pages, even in a large PDF is in the tens of milliseconds range. example-docs/DA-1p.pdf for example counts 619 in 0.071 seconds.

I expect the logic would look something like this:
def reject_for_too_many_pages() -> None:
    """Raises when PDF document exceeds caller-specified `max_pages` in non-fast mode."""
    # -- no limit when no max_pages not specified --
    if max_pages_arg is None:
        return
    # -- no limit on fast strategy --
    if strategy == "fast":
        return
    # -- only applies to PDFs --
    if not is_pdf:
        return
    # -- shorter PDFs are just fine --
    if pdf_page_count <= max_pages:
        return
    # -- non-fast strategy that resolves to fast is okay too --
    if detect_strategy() == "fast":
        strategy = "fast"
        return

    raise PdfTooLongError( ... )

Thinking through this you can see that the strategy-determination logic would never be invoked twice because:

it is only invoked here when the page-count is exceeded
test will fail if strategy resolves to non-fast
if it does resolve to fast we can change the strategy to fast and then detection logic won't be re-executed.

Just so you know where I'm coming from:

I'm strongly inclined to avoid adding new parameters to the open-source unless they clearly apply there. We already have a large number (50+) and that degrades the new-developer experience.
Violating responsibility boundaries for short-term optimization benefits is very expensive in the long run. It produces couplings across system boundaries that make reasoning about the assembled system, an already challenging job, more difficult, and in this case would add new concepts to partitioning as a whole, which are unnecessary for most partitioners. Those new concepts make partitioning incrementally more complex and we pay that incrementally increased maintenance cost indefinitely.

That was ofc the initial design - to add it just in API. And I agree that's more API responsibility to "protect" its instance :)
I just don't agree with that:

Thinking through this you can see that the strategy-determination logic would never be invoked twice because:
If the strategy will resolve to hi_res and page count will not be exceeded, then will do the same operations (open with pdfminer) twice - but if it's an acceptable overhead then let's reject this PR and open a new one in unstructured-api @mackurzawa

Thank you @scanny for your suggestions, but I still don't fully agree with you.
Just to make sure we're on the same page - we want to reject a pdf, when number of pages exceeds some limit and exactly hi_res strategy is chosen - no matter if the user provides it when calling API (here we could easily handle it in API) or user provides auto strategy which transforms to hi_res.
Regarding your solution, I still can see a potential issue here:

if detect_strategy() == "fast":

(As I said before it should be checked if hi_res is chosen, but it doesn't matter now)
Your detect_strategy function here should work just like determine_pdf_or_image_strategy from unstructured/partition/strategies.py, but calling this function outside of unstructured is cumbersome:
determine_pdf_or_image_strategy  have few parameters:
def determine_pdf_or_image_strategy(
    strategy: str,
    is_image: bool = False,
    pdf_text_extractable: bool = False,
    infer_table_structure: bool = False,
    extract_images_in_pdf: bool = False,
    extract_image_block_types: Optional[List[str]] = None,
):

To get the same results as in unstructured for code running in API I should pass all the arguments as it is done in unstructured/partition/pdf.py. The problem is the complexity of the arguments passed - they are the result of other functions in unstructured, whose arguments are also the result of other functions, and so on, e.g. pdf_text_extractable depends on extracted_elements, which is the result of the function extractable_elements, whose arguments also depend on others...
This means that I would have to copy all the logic behind the arguments of the determine_pdf_or_image_strategy function including all the functions that ultimately decide what those arguments look like, which in my opinion will add huge amounts of duplicate code.
I think making unstructured a little bit developer friendly here will result in making unstrutured-api a lot less readable. So, at the end my question is should I still duplicate all the logic that decides on ultimate strategy from unstructured to unstructured-api?

Thank you @scanny for your suggestions, but I still don't fully agree with you.
Just to make sure we're on the same page - we want to reject a pdf, when number of pages exceeds some limit and exactly hi_res strategy is chosen - no matter if the user provides it when calling API (here we could easily handle it in API) or user provides auto strategy which transforms to hi_res.
Regarding your solution, I still can see a potential issue here:

if detect_strategy() == "fast":

(As I said before it should be checked if hi_res is chosen, but it doesn't matter now)
Your detect_strategy function here should work just like determine_pdf_or_image_strategy from unstructured/partition/strategies.py, but calling this function outside of unstructured is cumbersome:
determine_pdf_or_image_strategy have few parameters:
def determine_pdf_or_image_strategy(
    strategy: str,
    is_image: bool = False,
    pdf_text_extractable: bool = False,
    infer_table_structure: bool = False,
    extract_images_in_pdf: bool = False,
    extract_image_block_types: Optional[List[str]] = None,
):

To get the same results as in unstructured for code running in API I should pass all the arguments as it is done in unstructured/partition/pdf.py. The problem is the complexity of the arguments passed - they are the result of other functions in unstructured, whose arguments are also the result of other functions, and so on, e.g. pdf_text_extractable depends on extracted_elements, which is the result of the function extractable_elements, whose arguments also depend on others...
This means that I would have to copy all the logic behind the arguments of the determine_pdf_or_image_strategy function including all the functions that ultimately decide what those arguments look like, which in my opinion will add huge amounts of duplicate code.
I think making unstructured a little bit developer friendly here will result in making unstrutured-api a lot less readable. So, at the end my question is should I still duplicate all the logic that decides on ultimate strategy from unstructured to unstructured-api?

@scanny I must agree with @mackurzawa - the effort to introduce it in API only is too huge for me (which maybe wasn't visible on the first look).
And well - we are not exposing this new parameter - it's only added to a protected (hidden) _partition_pdf_or_image_local function, like many other parameters - so it's not explicitly set in main public functions.
And I find it useful for users of the library as well - PDF and hi_res are not like other file types and may introduce various issues for very big files, so users can start protecting their applications with this parameter from timeouts, hangs, etc.
Maybe one thing I would change to be more precise is renaming max_pages param to hi_res_max_pages

Ahh, okay, now I think I understand better why you wanted to put it inside the PDF partitioning boundary.
One solution to the tangly relocation problem would be to add a simpler function inside unstructured.partition.pdf that encapsulated whatever calls were necessary to work out is_image and pdf_text_extractable. That would keep the tangly parts inside the boundary but expose a simple interface to the outside.
But whatever, I don't want to delay progress further. I drop my opposition to implementing it inside open-source.


Firefox 45 GET or HEAD has content body

Firefox 45 treats body === null differently from body === undefined
ms-rest-js setting the body to null leads to ta TypeError for GET and HEAD requests as it has to be undefined for firefox.
TypeError: HEAD or GET Request cannot have a body.
Stack trace:
zoneify/<@webpack-internal:///../../../../zone.js/dist/zone.js:1022:33
dispatchRequest/</<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:335:42
step@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:34:18
verb/<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:15:53
__awaiter</<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:9:15
ZoneAwarePromise@webpack-internal:///../../../../zone.js/dist/zone.js:875:29
__awaiter<@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:5:1
dispatchRequest@webpack-internal:///../../../../ms-rest-js/dist/lib/util/utils.js:293:1
RequestPipeline.prototype.requestSink@webpack-internal:///../../../../ms-rest-js/dist/lib/requestPipeline.js:47:16

I think fixing it in the runtime (ms-rest-js) is not the right way of doing it. We set the request body to null in the generator over here. That would be a better place to change.
Request.body has any type. So not initializing requestContent to null and simply declaring it should be ok.

However, the major issue that I would want to check is that, is it ok for request body to be set to undefined as the default instead of null?

@thecodejedi Can you make that change in the current PR in the autorest.typescript codegenerator?


edupont04 from OPS portal: Merge from master to live

Docs Build status updates of commit 9e6870f:
:warning: Validation status: warnings

File
Status
Preview URL
Details

dynamics-gp/whats-new/version-october-2019.md
:warning:Warning
View
Details

dynamics-gp/terms/lifecycle.md
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_ApplySalesDoc.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_Attach.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_BuildPayrollChecks.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_ClassID.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_EFTVendor.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_FiscalPeriodsSetup.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_JournalEntryInquiry.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_LongDescription.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_LongDescription2.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_PayrollVendorSetup.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/media/2019_Finance_QuickCodeAssignment.png
:white_check_mark:Succeeded
View

dynamics-gp/whats-new/version-october-2019.md

Line 0: [Warning] Missing required attribute: 'author'. Add the current author's GitHub ID.
Line 0: [Warning] Missing required attribute: 'title'. Add a title string to show in search engine results.
Line 14: [Warning] While scanning a simple key, could not find expected ':'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Darkness Enthroned

Support for Darkness Enthroned would be great, thanks!

The unique itself will be coming in the next update, however it will not (and cannot) function until I add support for socketing Abyss Jewels in items.


Export was not found while working with yarn berry workspaces

Bug report

What is the current behavior?
Hi, I am working with webpack 4 and yarn berry workspaces.
whenever I try to import a "package (workspace)" the browser console gives me a warning:
"export 'IAppError' was not found in './src/reduce_request_error'
The app however works, and no other places throw this warning. It happens to all of the packages that we import and export in our index files index.ts
Thanks,
Best regards.
TC
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
No warnings... because app works.

Do you think its an issue on your side?
Thanks in advance,
best regards,
TC
Other relevant information:
webpack version:  "^4.43.0",
Node.js version: 12.10
Operating System:  macos
Additional tools: yarn berry

Duplicate of #7378


The level crashes shortly after loading the textures for objects

So I was working on this project for days now and suddenly it began crashing without a stop when being launched again and finishes the texture loading phase/sometimes not even till that.
Here's the crashlog info:
Sun Jul 30 18:31:39 2017
Application has crashed: access violation

Callstack:
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     ???
     payday2_win32_release  (???)     zip_get_name
     payday2_win32_release  (???)     zip_get_name
                  KERNEL32  (???)     ???
                     ntdll  (???)     ???
                     ntdll  (???)     ???

Current thread: FileStreamer

Please send me the map I'll check what's wrong with the level.
Sent from my Lge LG-D855 using FastHub

Sure, here it is :
Infiltration project.zip

The level seems to work fine now, as another day has come, however, the crash reason remains mysterious, wonder if it could occur again, and whether or not I'd be as fortunate to have it magically disappeared a day later :D

Your map has many many packages, I tried to load different ones and it seems to work sadly we don't have any better method of loading units but if it happens again just remove the packages inside the main.xml, load into safe mode and load packages, try to choose the smallest ones and look at their size.
replace your main.xml with this: https://www.dropbox.com/s/xnx2ifxrqsh05oy/main.xml?dl=0


Add use instructions (or link to) on README

Please add some usage instructions to the README. It's currently unclear how the user will determine if he's been crossing paths with an infected person. Also some screenshots describing how to mark yourself as either infected, or healthy etc.

These refer to future features, which will be explained from within the app. The README will continue to be for potential project contributors.


Implement OrderedSet.update()

It would be nice if OrderedSet had an update() function like OrderedMap, to support changing value without changing order.
let os = Immutable.OrderedSet.of(1,2,3); // [1, 2, 3]
os = os.update(2, 7); // [1, 7, 3]

This can't be achieved currently because delete() followed by set() changes order.

Unfortunately this is beyond the current abilities of OrderedSet to do in a performant way.

Could this be achieved in a performant way by doing a concat and a sort?


Contributing link case-sensitivity fix

Old "Want to hack on IPFS?" link 404'd cause CONTRIBUTING.md was written in all lowers. It's fixed now.

Thanks @DTV96Calibre!! Good catch.


removed exerimental gmsh flag Mesh.CharacteristicLengthFromCurvature

I like your project.  I used to contribute to CalculiX and used it with Gmsh often.  They are great tools.
I was playing around with pycalculix and noticed that the mesh.CharacteristicLengthFromCurvature flag that you are adding to the GEO files fails in the current version of Gmsh (4.3.0) with the example problem hole-in-plate-full.py.  This is an experimental option according to the Gmsh docs, so it may be good to try to work without it.

Thanks for this PR @jeffbaylor. Can you please rev roll the pycalculix library minor version in setup.py and add a description of your update to the changes file?

Thanks for the PR Jeff. I will merge this into master with some other fixes.


Update DomRect

int is changed to float b/c it's unrestricted double in specs:
https://www.w3.org/TR/geometry-1/#DOMRect
https://drafts.fxtf.org/geometry/#DOMRect

Dang, you right. Thanks!


Switch _get_instructions() function to use a circuit

Summary
The _get_instructions() helper function was operating a level too low,
it should take a circuit in and return the iterators needed for drawing
the circuit. Each of the drawer backends deal with a circuit and
converting to a dag prior to getting the instructions adds unnecessary
complexity to the circuit_drawers. We also can isolate handling that in
one place in the helper function so if/when we change our relationship
between dags and circuits we have a single place to fix.
Details and comments

oh, I forgot about all the unit tests, I'll have to update them to pass a circuit and not a dag

Ok, the tests are updated now

@ajavadia yeah, that was the idea. To just isolate our usage of the dag to a single place so we didn't need to even know it was there in the circuit drawers.


Failed to construct nozzle consumer: Failed To Fetch Token

Kafka Version: 2.1.0
CF Version: 6.41.0+dd4c76cdd.2018-11-28
Go Version: go1.10.3 linux/amd64
OS: RHEL 7
I have confirmed that the username and password in the toml file will authenticate against the UAA endpoint, however, I am getting the following errors
[ERROR] Failed to construct nozzle consumer: failed to fetch token: Received a status code 401 Unauthorized
Followed by:
2019-01-02T17:26:53.628-08:00 [APP/PROC/WEB/2] [OUT] Exit status 2 2019-01-02T17:26:53.631-08:00 [CELL/SSHD/2] [OUT] Exit status 0
Note that I have Username and Password in the .toml file and do not have UAA_PASSWORD in the manifest. I have tried adding to manifest, but got the same results. Is there something I am not configuring correctly? Many thanks in advance for your help.

nozzle client has to be given doppler.firehose authority, e.g.
uaa:
  clients:
...
    kafka-nozzle:
      authorities: oauth.login,doppler.firehose
      authorized-grant-types: client_credentials
      override: true
      secret: SUPERSECRET
...

Turns out that a user was not needed at all. Instead, a client is required. After reading the source, I determined that the code wants a client_id and secret, of which a user does not have... only a client. After I created a client using the following:
uaac client create kafka-nozzle --authorized_grant_types client_credentials --authorities oauth.login,doppler.firehose --secret SomeSecretPwd
and set the username and password accordingly in the .toml file, all was well with the world! Cheers...hope this helps someone.


Responses should always have a non-empty body

Responses without any body fields should be serialized as {} (though deserialization can still be skipped).
This is not explicity noted in the spec, but all the relevant examples show it.

Fixed in 0238a72.


Array returning nil when selected

What did you do?
I am attempting to parse an array from a sample JSON file. From the same file (pasted below) I can parse other items using json["domain"].string! for instance. The nil return I'm receiving is when I attempt to do json["_gallery"].array
What did you expect to happen?
I expected SwiftyJSON to return a the contents of the selected element.
What actually happened instead?
SwiftyJSON returned with a nil value.
Environment
List the software versions you're using:

SwiftyJSON: 3.1.4
Xcode Version: Version 8.3.3 (8E3004b)
Swift Version: 3.0

Please also mention which package manager you used and its version. Delete the
other package managers in this list:

Cocoapods: 3.0

Project that demonstrates the issue
{     "id": 2450,     "domain": "http://website.com",     "_gallery": [         "image1",         "image2",         "image3"     ], }

Further troubleshooting I determined that the issue is not with SwiftyJSON.


SW-4881 Implement the internal deliverables list, using the new SearchFiltersWrapperV2

SW-4881 Implement the internal deliverables list, using the new SearchFiltersWrapperV2
Fix deliverable state types

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

#2199  👈
#2198
#2197
main

This stack of pull requests is managed by Graphite.


alpakatest and alpaka fail to build

From https://github.com/cms-patatrack/pixeltrack-standalone/pull/120#issuecomment-724907150

The alpaka and alpakatest fail to build with
.../pixeltrack-standalone/external/alpaka/include/alpaka/core/Concepts.hpp:81:33: error: '__T0' was not declared in this scope
                 static_assert(std::is_base_of<type, TDerived>::value, "The type implementing the concept has to be a publicly accessible base class!");
                                 ^~~~
.../pixeltrack-standalone/external/alpaka/include/alpaka/core/Concepts.hpp:81:33: note: suggested alternative: '__y0'
                 static_assert(std::is_base_of<type, TDerived>::value, "The type implementing the concept has to be a publicly accessible base class!");
                                 ^~~~
                                 __y0
.../pixeltrack-standalone/external/alpaka/include/alpaka/core/Concepts.hpp:81:47: error: template argument 1 is invalid
                 static_assert(std::is_base_of<type, TDerived>::value, "The type implementing the concept has to be a publicly accessible base class!");

Updating Alpaka to 0.5.0 changed the error to
.../pixeltrack-standalone/external/alpaka/include/alpaka/core/UniformCudaHip.hpp: In instantiation of 'void alpaka::uniform_cuda_hip::detail::rtCheckIgnore(const Error_t&, const char*, const char*, const int&, TErrors&& ...) [with TErrors = {cudaError}; alpaka
::uniform_cuda_hip::detail::Error_t = cudaError]':
.../pixeltrack-standalone/external/alpaka/include/alpaka/queue/cuda_hip/QueueUniformCudaHipRtBase.hpp:196:342:   required from here
.../pixeltrack-standalone/external/alpaka/include/alpaka/core/UniformCudaHip.hpp:86:61: error: missing braces around initializer for 'std::__array_traits<cudaError, 1>::_Type' {aka 'cudaError [1]'} [-Werror=missing-braces]
                     std::array<Error_t, sizeof...(ignoredErrorCodes)> const aIgnoredErrorCodes{ignoredErrorCodes...};
                                                             ^~~~~~~~~~~~~~~~~~

which can be worked around.

Yes with Cuda 11.1, I still get an issue with cudauvm, but alpaka and alpakatest build was working on my local.
These were just few changes to do in the Makefile (sorry here in temporary, debug style, also including change to Maxwell as in my local): https://github.com/ghugo83/pixeltrack-standalone/commit/769d8cc38f457f15251236f2a02b48c1f2914bf5

Should we include more proper support for Maxwell then?
(from your Makefile changes setting export CUDA_ARCH := 35 50 60 70 and adding
else ifeq ($(KOKKOS_CUDA_ARCH),50)
  KOKKOS_CMAKE_CUDA_ARCH := -DKokkos_ARCH_MAXWELL50=On

should be sufficient)

With cudauvm I still get this issue though (but was already there with CUDA 10.2):
Found 1 devices
terminate called after throwing an instance of 'std::runtime_error'
  what():
/home/ghugo/CMSSW/Portability/pixeltrack-standalone/src/cudauvm/CondFormats/SiPixelFedCablingMapGPUWrapper.cc, line 32:
cudaCheck(cudaMemPrefetchAsync(cablingMap_, sizeof(SiPixelFedCablingMapGPU), device, stream.get()));
cudaErrorInvalidDevice: invalid device ordinal
Aborted (core dumped)

Should we include more proper support for Maxwell then?
Ok yes will just add that

With cudauvm I still get this issue though (but was already there with CUDA 10.2):
Found 1 devices
terminate called after throwing an instance of 'std::runtime_error'
  what():
/home/ghugo/CMSSW/Portability/pixeltrack-standalone/src/cudauvm/CondFormats/SiPixelFedCablingMapGPUWrapper.cc, line 32:
cudaCheck(cudaMemPrefetchAsync(cablingMap_, sizeof(SiPixelFedCablingMapGPU), device, stream.get()));
cudaErrorInvalidDevice: invalid device ordinal
Aborted (core dumped)

Interesting. Could this be specific to Maxwell? I have tested cudauvm in Volta and Turing.


Adds docs publication to Jenkins

Jenkins job istio.github.io/presubmit passed

@mandarjog  Please cherry pick this into the release as well as everything that is needed for the firebase thing to work.

where is it pushing to ?
is it pushing only release branches ? master too ? other branches ?
(tiny bit of "description" would help)

seems it's not working:
java.lang.IllegalArgumentException: Expected named arguments but got [PROJECT_ID=istiodocs-v01, RELEASE=0.1]
https://testing.istio.io/job/istio.github.io/job/release-0.1/lastBuild/console
I manually pushed 0.1 so it's not urgent


Handling of CMSE_Lib.o with TrustZone projects

A secure project generates in the output directory a file with the format: _CMSE_Lib.o.  This issue describes how this file could be handled in the non-secure part of the project.
Assumption: suggested ./out directory structure of #821 is implemented; the example ./solution-examples/SimpleTrustZone would then generate the following files:
./out/AVH/CM33_s.axf
./out/AVH/CM33_s.axf.map
./out/AVH/CM33_s.hex
./out/AVH/CM33_s.bin/ER_CMSE_VENEER     // FromElf splits large bin files into regions
./out/AVH/CM33_s.bin/ER_ROM
./out/AVH/CM33_s_CMSE_Lib.o                      // question: does GCC and IAR generate the same file?
./out/AVH/CM33_ns.axf
./out/AVH/CM33_ns.axf.map
./out/AVH/CM33_ns.hex
./out/AVH/CM33_ns.bin

To include the CMSE_Lib.o into the CM33_ns.cproject.yml could include the following file:
   - group: CMSE Library
      files:
       - file: $OutDir(CM33s)$\CM33_s_CMSE_Lib.o

Assumptions:

By default, the $OutDir(CM33s)$ syntax uses the same target-type and the build-type of the current build.  It could be however explicitly specified.
$OutDir(<project-name>)$ creates a dependency on , the tools can verify build order to ensure that  is created before.
The build order or projects could be simply the order specified in the projects: nodes the csolution.yml file.

To make it even more intuitive for the user, $OutDir()$ could be renamed to just $out()$
The tool and the manual would need clarifications in the section access sequences as the <project-name> is not optional in the context.  Resolving a empty <project-name> with the current project might bypass dependency checking.
I suggest to deprecate $Output$ as it is unclear what exactly is referenced.

Instead of deprecating the $Output$ access sequence I would suggest to add cmse-lib into the known output types as proposed in https://github.com/Open-CMSIS-Pack/devtools/issues/801 and extend it with the type argument like this $Output(context, type)$, for example:
- group: CMSE Library
      files:
       - file: $Output(CM33s, cmse-lib)$

Instead of deprecating the $Output$ access sequence I would suggest to add cmse-lib into the known output types as proposed in #801 and extend it with the type argument like this $Output(context, type)$, for example:
- group: CMSE Library
      files:
       - file: $Output(CM33s, cmse-lib)$

I agree with @brondani , I posted something similar in https://github.com/Open-CMSIS-Pack/devtools/issues/821#issuecomment-1508527317

I believe the next version of the tool will give us enough flexibility to experiment.  The output directory can be configured in the way described above by using:
  output-dirs:
    outdir: ./out/$TargetType$/

I suggest to consider the following scenarios with https://github.com/Open-CMSIS-Pack/csolution-examples/tree/main/SimpleTrustZone:

Build 'ns' part with .debug, 's' part with .release and load it to target
Build both with the same build-type
Add a new build-type .test that has an additional global define test=1, then build 'ns' part with .test, 's' part with .debug
Then build 'ns' part with .test, 's' part with .release

How would you access the cmse-lib in these scenarios with the current default out directory?

Instead of deprecating the $Output$ access sequence I would suggest to add cmse-lib into the known output types as proposed in #801 and extend it with the type argument like this $Output(context, type)$, for example:
- group: CMSE Library
      files:
       - file: $Output(CM33s, cmse-lib)$

I like

Instead of deprecating the $Output$ access sequence I would suggest to add cmse-lib into the known output types as proposed in #801 and extend it with the type argument like this $Output(context, type)$, for example:
- group: CMSE Library
      files:
       - file: $Output(CM33s, cmse-lib)$

I like that idea, let me work on it.

How would you access the cmse-lib in these scenarios with the current default out directory?

In this scenario the goal would be to produce 5 different ns artifacts, so in SimpleTZ.csolution.yml there would be 5 build types, for example:
  build-types:
    - type: Debug
      debug: on
      optimize: none
    - type: Release
      debug: off
      optimize: balanced
    - type: NSDebug-SRelease
      debug: on
      optimize: none
    - type: NSTest-SDebug
      define:
       - test=1
    - type: NSTest-SRelease
      define:
       - test=1

While the s part only needs to be built as Debug or Release so it can be filtered like this:
  projects:
    - project: ./CM33_s/CM33_s.cproject.yml
      for-type: [.Debug, .Release]
    - project: ./CM33_ns/CM33_ns.cproject.yml

Finally in CM33_ns.cproject.yml the cmse-lib would be added as a dependency in this way:
  groups:
    - group: CMSE Library
      files:
        - file: $Output(CM33_s.Debug)$_CMSE_Lib.o
          for-type: [.Debug, .NSTest-SDebug]
        - file: $Output(CM33_s.Release)$_CMSE_Lib.o
          for-type: [.Release, .NSDebug-SRelease, .NSTest-SRelease]

Resulting in the following contexts:
CM33_s.Debug+AVH
CM33_s.Release+AVH
CM33_ns.Debug+AVH
CM33_ns.Release+AVH
CM33_ns.NSDebug-SRelease+AVH
CM33_ns.NSTest-SDebug+AVH
CM33_ns.NSTest-SRelease+AVH

With this approach the build artifacts do not get overwritten and the s part is only built once for Debug and once for Release.

@brondani yes this is a working solution and shows the flexibility of the tool.
Here is an easier way that uses the propose features in:

#831: build context manager removes inconsistent artifacts.
#821: simplified ./out directory can be configured today already
#823: enables various build types at command-line

  build-types:
    - type: Debug
      debug: on
      optimize: none
    - type: Release
      debug: off
      optimize: balanced
    - type: test
      debug: on
      optimize: none
      define:
         - test = 1

  projects:
    - project: ./CM33_s/CM33_s.cproject.yml
    - project: ./CM33_ns/CM33_ns.cproject.yml

Adding the cmse-lib to the CM33_ns project with the proposed access sequence:
groups:
    - group: CMSE Library
      files:
        - file: $cmse-lib(CM33_s)     # note the old sequence above would work too, this is just simpler

When cbuild is extended to build any combination, the command line is like this:
/* Build 'ns' part with .debug, 's' part with .release */
cbuild SimpleTZ.csolution.yml -c CM33s.Release - c CM33ns.Debug

/* Build both with the same build-type */
cbuild SimpleTZ.csolution.yml -c CM33s.Release - c CM33ns.Release

/* Build 'ns' part with .test, 's' part with .debug */
cbuild SimpleTZ.csolution.yml -c CM33s.Debug - c CM33ns.test

/* Build 'ns' part with .test, 's' part with .release */
cbuild SimpleTZ.csolution.yml -c CM33s.Release - c CM33ns.test

/* Now a new combination that does not require any change in the project file */
cbuild SimpleTZ.csolution.yml -c CM33s.test - c CM33ns.Release

What do you think?
@tcsunhao would this be an alternative to context-map:.  NOTE: I am not proposing to remove context-map but I would like to get your view on that.

Replaced by #894

I suggest to close this issue in favor of #894 -> Access Sequence: $cmse-lib(context)$


Unnecessary IntelliJ directories get created when configuring outputDir

I noticed that when I specify a custom outputDir for a GenerateAvroJavaTask, the plugin still creates generated-main-avro-java and generated-test-avro-java when I run the idea task.
I believe this comes from the following code within AvroPlugin:
                final File mainGeneratedOutputDir = getGeneratedOutputDir(project, mainSourceSet, JAVA_EXTENSION);
                final File testGeneratedOutputDir = getGeneratedOutputDir(project, testSourceSet, JAVA_EXTENSION);
                project.getTasks().withType(GenerateIdeaModule.class).all(new Action<GenerateIdeaModule>() {
                    @Override
                    public void execute(GenerateIdeaModule generateIdeaModule) {
                        generateIdeaModule.doFirst(new Action<Task>() {
                            @Override
                            public void execute(Task task) {
                                project.mkdir(mainGeneratedOutputDir);
                                project.mkdir(testGeneratedOutputDir);
                            }
                        });
                    }
                });

Here, the output of the getGeneratedOutputDir method is used directly, whereas other places that this method is used (e.g. in configureJavaGenerationTask), a convention mapping is instead used. My understanding on this is not very deep but I believe that the convention mapping will respect when I override the value in my task, whereas the above snippet clearly will not.
I'm not entirely sure why, but these extra directories cause IntelliJ to complain like:

Source root "/path/to/project/build/subproject/generated-main-avro-java" cannot be defined
in module "subproject" because it belongs to content of nested module "project".

Manually deleting the directories fixes the problem, but they shouldn't be created in the first place.

Thank you for the report, @xkrogen.  I believe I've pushed a commit that should fix this.  If it looks like the new test appropriately captures the problem you encountered, I'll roll this into a release.

Wow, that was an incredible turnaround time. The fix LGTM. Thanks @davidmc24 !

Thanks, I try to be responsive.

Hey @davidmc24 , I just tried this using version 0.14.2 on Gradle 4.6 and the directories were still generated. Here's a minimal build.gradle which reproduces the problem:
apply plugin: 'java'
apply plugin: 'idea'

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "com.commercehub.gradle.plugin:gradle-avro-plugin:0.14.2"
    }
}
apply plugin: "com.commercehub.gradle.plugin.avro"

task generateJava(type: com.commercehub.gradle.plugin.avro.GenerateAvroJavaTask) {
  source("src/main/resources/schema")
  outputDir = file("src/generated/java")
}

> ./gradlew idea
BUILD SUCCESSFUL in 0s
> ls build
generated-main-avro-java generated-test-avro-java

Any thoughts on what might be wrong?

So, the way the logic works now, for each task of type com.commercehub.gradle.plugin.avro.GenerateAvroJavaTask, the plugin adds an action to create the output directory.  In your example, you're adding an additional task that meets this criteria, without re-configuring the existing tasks generateAvroJava and generateTestAvroJava (as demonstrated in the test here).  Thus, it will create the new output directory src/generated/java as well as the defaults.

Ah, understood, thank you for the clarification!
On Fri, Jun 29, 2018 at 7:12 PM David M. Carr<EMAIL_ADDRESS>wrote:

So, the way the logic works now, for each task of type
com.commercehub.gradle.plugin.avro.GenerateAvroJavaTask, the plugin adds
an action to create the output directory. In your example, you're adding an
additional task that meets this criteria, without re-configuring the
existing tasks generateAvroJava and generateTestAvroJava (as demonstrated
in the test here
https://github.com/commercehub-oss/gradle-avro-plugin/blob/master/src/test/groovy/com/commercehub/gradle/plugin/avro/IntellijFunctionalSpec.groovy#L61).
Thus, it will create the new output directory src/generated/java as well
as the defaults.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/commercehub-oss/gradle-avro-plugin/issues/52#issuecomment-401357881,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGRBoTRlV-7PSVWuArzghSMfhu8QNAySks5uBi66gaJpZM4UVtYZ
.

Hi, @xkrogen. The way the logic works now, for each task of type com.commercehub.gradle.plugin.avro.GenerateAvroJavaTask, the plugin adds an action to create the output directory. In your example, you're adding an additional task that meets this criteria, without re-configuring the existing tasks generateAvroJava and generateTestAvroJava (as demonstrated in the test here). Thus, it will create the new output directory src/generated/java as well as the defaults.

This link is not working, please share.


Displaying autocomplete options with values

I am developing an auto-completion provider and I would like to show available option-values for command options that require values. For example, if a user enters "git commit --cleanup=" the auto-complete ideally suggests the options "strip, whitespace, verbatim, scissors & default".
In an older version of black-screen there was an optionWithValue class that provided this feature. Unfortunately I couldn't work out how to implement since the auto-complete functionality has been updated.
Is there a way to do this?

Hi. There is con convenient way because --cleanup=strip is one token, but you can check if the token starts with --cleanup= and then return suggestions with value like --cleanup=strip and displayValue like strip. This way you'll see only the word after the equal sign in the autocompletion popover, but when you press tab, the whole token will get replaced properly.

Thanks @shockone - I think I follow what you mean. It looks like the "branchAlias" suggestion provider does something similar:
https://github.com/shockone/blackscreen/blob/master/src/plugins/autocompletion_providers/Git.ts#121
I will try and implement this.

You're welcome. Don't hesitate to ask, if you have any issues. Also, maybe a more appropriate channel of communication would be https://gitter.im/shockone/black-screen


ERROR decrypt unable to find a PGP decryption key for this message

System Info:
5.4.0-40-generic
Ubuntu 20.04.1 LTS focal
keybase version 5.5.1-20200527202541+39ca0071e5
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5
Application Error:
ERROR decrypt unable to find a PGP decryption key for this message
Additional info:
I add my own PGP key with passphrase with keybase pgp select command
I don't get request for type passphrase  when I use keybase
How to reproduce:
keybase pgp list

Keybase Key ID:  01019906
PGP Fingerprint: 85720229
PGP Identities:
   Vladimir Samoylov (cageyv<EMAIL_ADDRESS>
keybase pgp encrypt -m "foobar" > testmessage.txt

cat testmessage.txt

-----BEGIN PGP MESSAGE-----
Comment: https://keybase.io/download
Version: Keybase Go 5.5.1 (linux)

wcFMA4vYUBIL+GyiARAAXPdge8CeXlhjMne32C8SteJuLz/A4rzajo7hXipE7nIa
BVI+s7tmZCRDU9lTkQutH7FJ1cwI60m6Ig3cBTRtDxKDX/W7ZU0OLD35bBIB0+Wj
kzj3HMqHNfWzx+hiLWtQNW7U61XZry8CP4WdWNyPGWnz0uHcHnJZ2di1TMJxgq2e
HD//w6Y5mwWFslA6vAVvvNtZyWFYkJ7G+yoNRSnyMZxjWOcwb8rg3HsfCYW4nLDG
ET5/zRcVVsekhGmwd5jsGBxRMzPqCwDR3YlDAnzzf15JbpaqDiQ7b1XcQacdLB2b
WBGnxIYF09PI/Ef6thsQINuCiJHPb7NxDvV0JuWmGN6Va0QhdH+lwHIMNU1XMQdW
hvlk539Y4ee+MGtNqnSt5RGOS0HdpkZvA4zNaMzxMTFZOIWz5YTRT9xWLRQtuCON
Bdxn9+qPUxyPtw2qp6rfAtFHKdzZLMMpLvJ3i9J8A/0+z3KOlNikIZ1+UDLI7Ta1
3BrAvFHuPMiFKbDmP9wZ+5RPTdlmcaW68m/PQjr9E0fw/OyTMFY5OydzoSPdTmEf
9luseUa8cCLvGFs9i/StY+NqglnvYttmwczj8dW0JTNGrOYglNfDtNVt4yHj9S8Q
VCTM26bCblkPnq7xQncvVFUUVTKiSnIuDemgNp9XpJWmEDLPz3ePwAQdj+LWMa7S
4AHkTqKTa//UOUj8VkFMPTifJOEYZeAa4O7hZZvgFuIELlNc4F/iMs5oE+Al4VsS
4O3kC9J0syzdPvKib7fSN1wgEOJksiiX4WMtAA==
=Isrr
-----END PGP MESSAGE-----

gpg2 --decrypt testmessage.txt
"Entering passphrase..."

gpg: encrypted with 4096-bit RSA key, ID 8BD850120BF86CA2, created 2020-02-02
      "Vladimir Samoylov (cageyv<EMAIL_ADDRESS>foobar%

gpg --decrypt testmessage.txt
"Entering passphrase..."

gpg: encrypted with 4096-bit RSA key, ID 8BD850120BF86CA2, created 2020-02-02
      "Vladimir Samoylov (cageyv<EMAIL_ADDRESS>foobar%

keybase pgp decrypt -i testmessage.txt

ERROR decrypt error: unable to find a PGP decryption key for this message

Any help on this.  I am facing a similar issue

Same here

A year passes - Did anyone sort this out? I have this issue as well.

This comment worked for me (as long as you are comfortable storing your private key in keybase): https://github.com/keybase/client/pull/17307#issuecomment-558860752

@deybhayden I moved to another system now and can't help to reproduce this anymore :(


added demo manifest with new resources

Executed build pipeline:
https://github.com/OfficeDev/Microsoft-Teams-Samples/actions/runs/10234945626


DEP: remove ftol/xtol from neldermead

Reference issue

Closes #15751
What does this implement/fix?

Removes depricated ftol/xtol from neldermead as they have had a deprecation warning for 5+ years
Additional information

thanks


i18n(es): Translated statamic.mdx

What kind of changes does this PR include?

New or updated content
Translated content

Description

What does this PR change? Give us a brief description.
Translated statamic.mdx to spanish 😄

Gracias por el review @Waxer59 😁


Test suite

We need to have some basic tests to make sure that the plots we're creating at least run.
We could do this by storing a few small example tsinfer output files (in tests/data) and running the various plots on these.

@benjeffery would you mind picking this up please?
We just want something super basic that runs each of the plots on a few toy tsinfer produced trees files. All we're testing is that the plots run initially (might get a bit more sophisticated later)
Would be nice to have files from a few versions of tsinfer, just to check that older files work (or at least be aware if they don't). Don't need to go way back, just versions associated with files we've made available on zenodo through the tsinfer and unified genealogy papers.
We can check the binaries into a tests/data directory.
Hopefully we can do something nice with pytest then to automate parameterizing over these?

Partially addressed in #37 where we start off the test suite. We'll still want to get small examples of different types of trees files in there, which we run the data export stuff on (at a minimum)


Bare metal environment substitution to with IP and starting etcd in docker?

I'm trying to set up a bare metal setup of CoreOS and using the following script.  Unfortunately, it doesn't work despite EnvironmentFile being specified, the IP doesn't come through yet it is in /etc/environment.
Running the script shows /etc/environment being written successfully.  The other problem is that although I tried creating this file as etcd.service rather than etcd2.service.  It would seem that fleet kicks off etcd (old version) instead of the new one provided through docker.
How can I make this work?  I'm wanting to keep everything in one place if possible.
#!/bin/sh

workdir=$(mktemp --directory)
trap "rm --force --recursive ${workdir}" SIGINT SIGTERM EXIT

cat << EOF > ${workdir}/cloud-config.yml
#cloud-config

ssh_authorized_keys:
  - ssh-rsa [rsa-key...]
coreos:
  units:
    - name: etcd2.service
      command: start
      content: |
        [Unit]
        Description=etcd2 container
        After=docker.service

        [Service]
        EnvironmentFile=/etc/environment
        ExecStartPre=-/usr/bin/docker kill etcd2
        ExecStartPre=-/usr/bin/docker rm etcd2
        ExecStartPre=/usr/bin/docker pull quay.io/coreos/etcd:v2.0.8
        ExecStart=/usr/bin/docker run -p 4001:4001 -p 2380:2380 -p 2379:2379 --name etcd2 quay.io/coreos/etcd:v2.0.8 \
          -name \${ETCD_NAME} \
          -advertise-client-urls http://\${private_ipv4}:2379,http://\${private_ipv4}:4001 \
          -listen-client-urls http://<IP_ADDRESS>:2379,http://<IP_ADDRESS>:4001 \
          -initial-advertise-peer-urls http://\${private_ipv4}:2380 \
          -listen-peer-urls http://<IP_ADDRESS>:2380 \
          -initial-cluster-token etcd-cluster-1 \
          -initial-cluster \${ETCD_PEERS} \
          -initial-cluster-state new
        ExecStop=/usr/bin/docker stop etcd2
    - name: fleet.service
      command: start
EOF

get_ipv4() {
    IFACE="${1}"

    local ip
    while [ -z "${ip}" ]; do
        ip=$(ip -4 -o addr show dev "${IFACE}" scope global | gawk '{split ($4, out, "/"); print out[1]}')
        sleep .1
    done

    echo "${ip}"
}

export COREOS_PRIVATE_IPV4=$(get_ipv4 enp2s0)
coreos-cloudinit --from-file="${workdir}/cloud-config.yml"

${private_ipv4} and ${public_ipv4} templating is not supported for bare metal deployment


Fix leaks and crashes in OAHashMap (3.2)

This changes the way the lifespan of items is managed to be consistent.
Bonus: Simplify cases of destroy-then-emplace.
Version of this PR for master: #38827

This code is generously donated by IMVU.

Thanks!


Add no-build-isolation feature

Adds a feature to enable the pip / pip-compile argument --no-build-isolation. Also updates a unit test to call this feature.
I have a use case that requires disabling build isolation that I'd like to use pip-compile-multi for.

Looks good. I'll make a few changes mostly for docs before releasing.

Thanks, enjoy release 2.4.4

Thanks!


Tutorial

Thank you for your work. The only thing missing is a step by step tutorial and this will be the most perfect Godot monetization plugin ever.

Thanks for your feedback! I will consider adding more detailed docs in the upcoming release.

Can you please help me with a short step by step list on how to implement rewarded ads with consent forms and everything.
Just the steps not entire paragraphs. I really need your help. It's urgent.
Thank you very much. Appreciate it 👍🏼.

@Momo90k, have you seen the demo project? If not, I recommend you look into that project first. Let me know if something is not clear there.


Language Friend - Conversation Improver GPT

Here is my language GPT. I use it every day to help me learn Swedish and it has been a massive help. Hopefully someone else will find it useful. I've also included a Spanish version, which might have  more application.
https://chat.openai.com/g/g-xsnkbBK5n-swedish-friend-language-conversation-improver
https://chat.openai.com/g/g-p5dJAcoT8-spanish-friend-language-conversation-improver
Hopefully those links work ok.

Merged


Export-PSGraph does not find graphviz on Ubuntu in default location

On Ubuntu, the default install location is /usr/bin/dot I feel this should be added to the default search list
        $GraphVizPath = (
            'C:\Program Files\NuGet\Packages\Graphviz*\dot.exe',
            'C:\program files*\GraphViz*\bin\dot.exe',
            '/usr/local/bin/dot'
        ),

If you agree, I can do a PR if you like.

Absolutely. That looks like a good path to add to the list.

PR submitted. I know you have login in Install-GraphViz for Windows and MacOS. For Linux, because of the variability in distos and package managers, I'm not sure of the best options for this command.
For ubuntu (and other debian distros), you would use sudo apt install graphviz for REHL and other similar distros, it would probably be a yum command.

I wasn't sure how to handle all those possibilities either and I'm not sure that command belongs in this module.

I was thinking more displaying the command but not executing it

I would be good with that solution. That lets the user make the call.
I guess I we should also include a link to the graphviz documentation on how to download it. https://www.graphviz.org/download

hi, guys,
I think it would be too bad to have the user usability be diffferent for linux then for macosx and windows.
I perhaps have a small suggestion. Please let me know if this is something that could be acceptable:
    <#
        .Description
        Installs GraphViz package using online provider
        .Example
        Install-GraphViz
    #>
    [cmdletbinding( SupportsShouldProcess = $true, ConfirmImpact = "High" )]
    param()

    process
    {
        try
        {
            if ( $IsOSX )
            {
                if ( $PSCmdlet.ShouldProcess( 'Install graphviz' ) )
                {
                    brew install graphviz
                }
            }Elseif($IsLinux){
                #Get the version, with something like this:
                #https://www.cyberciti.biz/faq/how-to-check-os-version-in-linux-command-line/
                $LinuxOs = ""

                switch($LinuxOs){
                    "RHEL" {yum graphviz;break}
                    "Ubuntu"{sudo apt install graphviz;break}
                    "Default"{throw "Os not supported yet. please open an issue here: https://github.com/KevinMarquette/PSGraph/issues"}

                }

            }
            else
            {
                if ( $PSCmdlet.ShouldProcess('Register Chocolatey provider and install graphviz' ) )
                {
                    if ( -Not ( Get-PackageProvider | Where-Object ProviderName -eq 'Chocolatey' ) )
                    {
                        Register-PackageSource -Name Chocolatey -ProviderName Chocolatey -Location http://chocolatey.org/api/v2/
                    }

                    Find-Package graphviz | Install-Package -Verbose -ForceBootstrap
                }
            }
        }
        catch
        {
            $PSCmdlet.ThrowTerminatingError( $PSitem )
        }
    }

I have no linux machine to test this one unfortunatley. perhaps @tigerfansga could give it a shot?

One option to look at these is WSL on Windows 10.
I can do some checking on a few different distributions, but the variability in the Linux world will create gaps.
I can't confirm, but you will most likely need to use sudo for REHL with yum.


Postgres and redis volumes should be localised to app

in the docker-compose file volumes are set like this:
- 'postgres:/var/lib/postgresql/data'
But I think they should be set like this:
- './postgres:/var/lib/postgresql/data'
This localizes the folder to the project itself, and it should be ignored in the git file

I think it's best to use named volumes for these. Typically these aren't files you would interact with on a regular basis, so by using named volumes, you just let Docker manage them without worrying about where they live on your file system.
The volumes will be automatically name spaced by the project's name. You can verify that by running docker volume ls.


[BUG] Missing Content-Length for PDF behind Cloudflare

📝 Describe the Bug
PDF behind Cloudflare does not work because Content-Length is not available. Library logs java.io.IOException: Incomplete download.
Cloudflare removes information about Content-Length when Accept-Encoding have gzip value.
Maybe you can remove gzip value from that header?
📖 Library Version

Since 2.1.0

+1

+1

+1

I'm in a similar situation where the content length is unavailable from my file server.


kubectl delete should fail if a non namespaced resource is about to get deleted with --all

What happened:
An admin accidentally deleted all pv-s with the following command:
kubectl delete pv -n <some_namespace> --all
What you expected to happen:
Based on kubectl help, the expected behavior would be the following:
kubectl delete pv --all   ->  return an error        / alternative behavior is to delete all pv, but in that case the help text for --all should be changed/
kubectl delete pv -n <namespace> --all   -> return an error / or delete nothing, as we've scoped the request to a specific namespace
kubectl delete pv --all-namespaces --all   -> delete all pv
kubectl delete pv -n <namespace> --all --all-namespaces   -> delete all pv ( since --all-namespaces overrides -n according to the help)
Reasoning:
Cluster scoped resources are not namespaced.
The help for kubectl delete --help says the following about the --all , -A and -n parameters:
--all=false: Delete all resources, including uninitialized ones, in the namespace of the specified resource types.
-A, --all-namespaces=false: If present, list the requested object(s) across all namespaces. Namespace in current
context is ignored even if specified with --namespace.
-n, --namespace='': If present, the namespace scope for this CLI request
Therefore:
--all option alone shall not delete cluster scoped resources, as the help says that it deletes resources in a namespace, and cluster scoped resources are not namespaced.
Also, -n shall filter out all resources that are not in a given namespace. Cluster scoped resource is not in a namespace, so it should be filtered.
I know that kubectl delete is a GA command, and changing the behavior is a serious thing, but my proposal does not break valid scenarios, as a user is never supposed to scope to a namespace when deleting cluster scoped resources.
This proposal is valid for similar scenarios, like this similar issue that mentions accidental delete of namespace: https://github.com/kubernetes/kubectl/issues/1056
How to reproduce it (as minimally and precisely as possible):
Example:
kubectl delete pv -n <namespace> --all
Anything else we need to know?:
Environment:

Kubernetes client and server versions (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:51:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.9", GitCommit:"b631974d68ac5045e076c86a5c66fba6f128dc72", GitTreeState:"clean", BuildDate:"2022-01-19T17:45:53Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}

We're hoping to address this via https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3104-introduce-kuberc. You can see that and this thread for the history https://groups.google.com/g/kubernetes-dev/c/y4Q20V3dyOk.
/close


Add ReactNext 2019

Add ReactNext 2019 conference to list of conferences. Thanks

Thanks!
Do we need to sign the CLA?

Wouldn't hurt. It's a technicality with this kind of change and not strictly necessary but it would probably make our internal systems happier.

If your internal systems are happier then I'm happier. We'll sign


GRPCTransport should support arbitrary dial options

When dialing a gRPC endpoint, normally a client can provide arbitrary dial options. Ondatra currently has a use case for providing a custom unary and stream interceptor, for example. GRPCTransport could in theory provide setters for all DialOptions that currently exist but that would bloat the API and would incur the burden of keeping it up to date when new dial options are added. I'd suggest a simple SetDialOptions(...grpc.DialOption) method be added. Whether or not you still want to keep SetDialTimeout or leave it up to the user to set it via a dial option is up to you. If both SetDialTimeout and SetDialOptions are available, then some reasonable semantics for when both are set would need to be decided.

@greg-dennis could you please let us know if this works for you ?
https://github.com/open-traffic-generator/openapiart/issues/328

@ashutshkumr, I confirmed that this is sufficient for my use case, thank you.


Convert to SQLite instead of PostGres

Change the background database type to SQLite, to aid simple backup options in future

May revisit in future, seems a non-issue for now


GH-40029: [Packaging][Ubuntu] Drop support for Ubuntu 23.10 Mantic Minotaur

Rationale for this change
We already have Ubuntu 24.04 LTS support. So Ubuntu 23.10 non-LTS support is needless.
What changes are included in this PR?
Remove Ubuntu 23.10 Mantic Minotaur related codes.
Are these changes tested?
Yes.
Are there any user-facing changes?
Yes.

@github-actions crossbow submit -g linux

+1


ln -s /Applications /Volume/..  fails: No such file or directory

When app bundle is 100MB (a minimal UI I used for testing), create-dmg does not have any problem
When app bundle is 2GB, ln -s /Applications fails with this error  message:
Making link to Applications dir...
/Volumes/dmg.Czwp56
ln:
/Volumes/dmg.Czwp56/Applications: No such file or directory
After the script fails, ls /Volumes/dmg.Czwp56 shows only app bundle,
ln -s /Applications /Volumes/dmg.Czwp56/Applications works without problem
I edited create-dmg script directly, and replace the ln with ln -s /Applications /Users/XXX/test_app
this command fails as well
So is this problem with Mac?
or because of large file?

I did some more investigation:

If I remove significant part of contents to make the total package under 2GB, create-dmg succeeds
in the same run, ln -s /Applications /tmp/test_app works, but ln -s /Applications $MOUNT_DIR/Applications fails

create-dmg is under /opt/homebrew
so I suspect it's because the script and the volume are in different partition when .dmg is too large

by adding --sandbox-safe, and make changes from ln -s /Applications /private/tmp/dmg.XXXX/Applications to ln -s /Applications /tmp/dmg.XXXX/Applications, this error passes
and next error cp: /tmp/dmg.YnIA53/.VolumeIcon.icns: No such file or directory
This should be the same root reason as the earlier one.

ok. figure it out, it's because $MOUNT_DIR somehow has a heading '\n' that breaks all filepaths.

When trying to build my DMG, I'm getting the following error:
Mounting disk image...
Device name:  /dev/disk2
Searching for mounted interstitial disk image using /dev/doisk2s...
Moint dir:
/Volumes/dmg.OGcdL1
Making link to Applications dir...
/Volumes/dmg.OGcdL1
ln:
/Volumes/dmg.OGcdL1/Applications: No such file or directory```

I'm not totally sure, but I'm guessing that this is the same issue? Right?

When trying to build my DMG, I'm getting the following error:
Mounting disk image...
Device name:  /dev/disk2
Searching for mounted interstitial disk image using /dev/doisk2s...
Moint dir:
/Volumes/dmg.OGcdL1
Making link to Applications dir...
/Volumes/dmg.OGcdL1
ln:
/Volumes/dmg.OGcdL1/Applications: No such file or directory

I'm not totally sure, but I'm guessing that this is the same issue? Right?
If so, is there a way for me to get the fix? I've only ever installed this via brew, and am not too familiar with how I'd go about building/installing my own version.

exactly,
ln: /Volumes/dmg.OGcdL1/Applications:
should be:
ln: /Volumes/dmg.OGcdL1/Applications:

Fall into this error too.. the thing I am trying to pack is 4.8gb.
Should I change something on the executable myself?

@silicooon I've just merged the fix from @aaronyuai #170, can you update your create-dmg script with the one in the repo and check if your issue is fixed:
https://github.com/create-dmg/create-dmg/blob/master/create-dmg

@aonez THANK YOU! that was really fast.
Can you please check my oneliner here and let me know if something is wrong? I need to only point to an app?
create-dmg --volname "MyGreat App v1.1.0" --volicon "/Volumes/falcon/upload/MyGreat App v1.1.0/MyGreat App.app/Contents/Resources/Icon.icns" --icon "/Volumes/falcon/upload/MyGreat App v1.1.0/MyGreat App.app" 182 190 --icon-size 100 --app-drop-link 462 190 --hdiutil-quiet --window-pos 200 120 --window-size 660 453 --background /Users/user/Documents/bgs/a14d52sc1e970.png --no-internet-enable /Volumes/falcon/upload/MyGreatApp.v1.1.0.dmg /Volumes/falcon/upload/MyGreat\ App\ v1.1.0

Okay! It seems when I am using the script with full paths it always errors like this:
Creating disk image... Mounting disk image... Device name:     /dev/disk26 Searching for mounted interstitial disk image using /dev/disk26s... Mount dir:       /Volumes/dmg.uqtqYY Copying background file '/Volumes/falcon/upload/BigAppv1.1.0/bigapp.png'... Copying volume icon file '/Volumes/falcon/upload/BigAppv1.1.0/bigapp.icns'... Unknown regexp modifier "/V" at -e line 1, at end of line Regexp modifiers "/l" and "/u" are mutually exclusive at -e line 1, at end of line Can't find string terminator '"' anywhere before EOF at -e line 1.
But if I run it into my current directory all is fine.
create-dmg --volname "BigApp_v110" --icon "BigApp.app" 182 190 --icon-size 100 --hdiutil-quiet --background BigApp_1521970.png --no-internet-enable BigApp.dmg BigApp.app

@silicooon does using " in all the paths fix the issue for you?
create-dmg --volname "MyGreat App v1.1.0" --volicon "/Volumes/falcon/upload/MyGreat App v1.1.0/MyGreat App.app/Contents/Resources/Icon.icns" --icon "/Volumes/falcon/upload/MyGreat App v1.1.0/MyGreat App.app" 182 190 --icon-size 100 --app-drop-link 462 190 --hdiutil-quiet --window-pos 200 120 --window-size 660 453 --background "/Users/user/Documents/bgs/a14d52sc1e970.png" --no-internet-enable "/Volumes/falcon/upload/MyGreatApp.v1.1.0.dmg" "/Volumes/falcon/upload/MyGreat App v1.1.0"

No, i have tried that too. :( Thank you!

Had this same issue, modifying the script directly resolved it for me as well.

Please check the new release: https://github.com/create-dmg/create-dmg/releases/tag/v1.2.2


Weird problem - no upstream

I am running nginx-proxy the following way
docker run -d --name vhost-proxy -p  80:80 -p  443:443 -v /var/run/docker.sock:/tmp/docker.sock:ro \
-v /ssl_certs:/etc/nginx/certs \
jwilder/nginx-proxy > /dev/null

After this I experience problem with proxing to container. When I log in to vhost-proxy conainer
and cat /etc/nginx/conf.d/default.conf I get this:
server {
        server_name v3.myhost.lan;
        listen 80 ;
        return 301 https://$host$request_uri;
}

server {
        server_name v3.myhost.lan;
        listen 443 ssl spdy ;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;

        ssl_prefer_server_ciphers on;
        ssl_session_timeout 5m;
        ssl_session_cache shared:SSL:50m;

        ssl_certificate /etc/nginx/certs/v3.myhost.lan.crt;
        ssl_certificate_key /etc/nginx/certs/v3.myhost.lan.key;

        add_header Strict-Transport-Security "max-age=31536000";

        location / {
                proxy_pass https://v3.myhost.lan;

        }
}

The upstream part is completely missing, so v3.myhost.lan cannot be reached (I get 502 Bad Gateway from nginx-proxy).

Found the issue - I needed to set VIRTUAL_PORT=443 in my docker container.
Pls make this requirement more obvious in docs. Especially when you use try to proxy to 443, you het these problems.

@rivaros Are you sure you have the current version of the image?
In the scenario you describe, you should always get an upstream block. If your backend container exposes only port 443, it should work. If it exposes more than one port and none of them are port 80, you should see server {{ .Container.IP }} down; and get a 502 error. Otherwise, you should see it try to connect to port 80.
Also, be aware that VIRTUAL_PROTO=https will be needed if you're connecting to an HTTPS backend.
All of this seems sufficiently documented to me in the "Multiple Ports" and "SSL Backends" sections of the README.md, but feel free to offer some concrete suggestions of how you thing the docs could be improved (or better yet, create a PR for discussion).

@md5, Thank you for the answer. VIRTUAL_PROTO=https was set. Yes, my container had multiple ports exposed (443,3306), but not 80. And what was needed was VIRTUAL_PORT=443.
Really the upstream block existsed, but docker-gen inserted so many spaces into nginx.tmpl, so when I did docker exec vhost-proxy cat /etc/nginx/conf.d/default.conf, it was simply somewhere lost far in the top, stupid of me not to notice it immediately.

Actually, I spoke too soon. The docker-gen changes to omit blank lines by default are in an unmerged PR: https://github.com/jwilder/docker-gen/pull/104


Custom workflow validation & conversion

Support an arbitrary flow of nodes/edges and validate it + be able to convert it to a use case template.

Refactoring into clearer meta issues.


Auto Dial on android

Does this plugin bypass the user having to still dial the number on android?

That's something I need to know too.
Clearly the App has to request additional permission from the user to be able to achieve this.

hi, need to know too.

it does auto dial and works like a charm


Uber’s Journey Toward Better Data Culture From First Principles / Uber

URL:
https://eng.uber.com/ubers-journey-toward-better-data-culture-from-first-principles/
Review (1-2 sentences):
I lot of appliable ideas on how processes around data at scale can look like, areas of responsibility, and metrics of quality.

Published in the Digest #1


Switch rust overlay

https://github.com/oxalica/rust-overlay  Said to be a better Rust overlay.  Does seem more focused on a flake-centric world, and flake adoption is being developed in #176  and elsewhere
Tossing this into CI to see what happens

@onsails  you may find this PR interesting.   Let's reflect on #161  @trha @ebkalderon

shanesveller — 01/22/2021
@psionik  I made an extremely casual adaption of your upstream docs to package rust-analyzer in a flake with tunable flake inputs and a fixed version of rust toolchain: https://github.com/shanesveller/flake-rust-analyzer/blob/d8d2b2e8c6137f328edd9021bb0d4011d139762e/flake.nix#L35-L53. while it's perhaps verbose I actually appreciated each opportunity to have full control over the inputs and would hope to see those continue to work (with any reasonable adjustments needed) after any efforts to streamline.

And let's think about how to handle #176
The big question I have is what behavior do we want Rust projects to be able to use when they switch to flakes?  Building cargo2nix via flakes will just make a few toolchain installations more convenient.  The downstream projects should have a lot more consideration.  The question is what are the downstream projects' likely concerns?
In the discussion to streamline Cargo.nix to include some default pins through some mechanism, it should be expected that these pins are listed as a flake input and therefore can be overridden via flakes mechanism by a project consuming the cargo2nix overlay.  A more monolithic Cargo.nix then would also have to provide some flake information or API hooks


lucy node-offline recovery

Often, nodes on a lucy testnet will go down for random reasons.  Usually, it's because the pod was pre-empted or evicted.  On the infrastructure side we've had various tweaks over the years to try to make this happen less, but it still happens.
The solution here is to make Lucy itself more resilient to failure.  This PR makes it so that the lucy test executive detects when nodes go down, and when they do, then the lucy test executive invokes some recovery logic so that the test can keep going along.  Thanks to the graphql polling log engine, we already can quickly detect when nodes go down, and emit an event, specifically node_down.
Technical note on the implementation: The node_down event is distinct from the node_stopped event.  node_down means that the node is not responding for whatever reason, versus node_stopped means that Lucy just deliberately stopped the event.  Previously there was just a single event for both which was called node_offline; in other words I've split node_offline into 2 separate events-- node_stopped and node_down.
Once the node_down is detected, the very simplest thing would be to simply crash the test immediately, this way we are at least failing-fast and not wasting time running a doomed test that's going to fail eventually anyways.  This is what a previous un-landed PR (https://github.com/MinaProtocol/mina/pull/13864) did, although in a more manual way.
In this PR, Lucy will attempt to restart the node.  When a pod goes down, kubernetes automatically starts the pod anew, so we don't need to worry about that.  We simply need to find the new pod, and start the mina daemon inside the pod.  Everything else will hook up just fine as is.  Graphql relies on a DNS url, and kubernetes will automatically map the DNS to the new pod.

Implementation details:
network_state data structures
--node_on : <node_id, bool> Map
--node_initialization: <node_id, bool> Map
events
--node_started.  set node_on to true for the node_id
--node_initialized.  set node_initialization to true for node_id
--node_stopped.  set both node_on and node_initialization to false for node_id
--node_down.  action to be taken depends on the state of node_on and node_initialization, see below
Node has gone DOWN, check the node state variables node_on and node_initialized
--on is true, initialization is true: crash happened!!! see the subsequent sections regarding recovery logic
--on is true, initialization is false: it's still initializing and the graphql server is not up yet, do nothing and just wait
--off, initialization is false: it was turned off deliberately so don't worry, just do nothing
--off, initialization is true: this state makes no sense ontologically.  in the event handler for node_stopped, the when the node is turned off it's also de-initialized so in the "finite state machine" tracking the node state, the state of the node being off and also initialized will never be entered.
Note: Logically speaking, the node_on data structure is superfluous to node_initialized, since we're not using it in a meaningful way right now, but I'm keeping it in just in case in the future we need to differentiate between when the node is off, versus when the node is on but still initializing.  In other words, if people object, I can remove the datastructure network_state.node_on, and we could probably dispense with the event node_started; however we will still need to distinguish between node_stopped versus node_down.
Basic recovery logic (initial development MVP): first set the network_state as not initialized, but node_on is still true.  then restart the mina daemon in the node.  With the basic recovery, no matter why it crashed, it gets restarted
More sophisticated node recovery logic, distinguish between the following 3 cases for node failures:
--the kubernetes pod wasn't pre-empted or anything like that, rather the mina daemon crashed.  FAIL TEST IMMEDIATELY.  check by kubectl exec'ing into the pod, if the pod is there but the daemon inside is down, then the daemon crashed, and so fail immediately.
--the pod crashed because the daemon crashed and/or went OOM, and brought the whole pod down with it.  FAIL TEST IMMEDIATELY.  check by looking at the exit code of the pod?  TODO
--if it's not the above two cases, then the pod was probably killed for kubernetes reasons, and the daemon was most likely fine.  we should try to recover (same as basic recovery logic above).

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-run-nightly

!ci-nightly-me


setHidden not working for sticky header

Library version : Snapshot
setHidden(true) is still showing headers in the case of sticky header recycler view.

@krupalagile, that setter only modifies the hidden flag.
If you want one particular header to not be shown anymore, you have to remove it from the adapter with others means, and coherently if you keep it in memory alive, reset the hidden flag to true.
Normally the headers are shown or hidden all together, so you should use the adapter functions.


Could not find firebase-messaging.jar

Description:
I'am working with react-native-onesignal for android, but from yesterday it stopped working and I can't build android apk.
After "react-native run-android" I have below error:

Could not find firebase-messaging.jar (com.google.firebase:firebase-messaging:12.0.0).
Searched in the following locations:
https://jcenter.bintray.com/com/google/firebase/firebase-messaging/12.0.0/firebase-messaging-12.0.0.jar

Environment
"react-native": "0.53.0",
"react-native-onesignal": "^3.2.4",
build.gradle:

// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {
    repositories {
        google()
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.0'
        classpath 'com.google.gms:google-services:3.2.1'
        //3.0.0

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        google()
        mavenLocal()
        maven { url 'https://maven.google.com' }
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
    }
}

app/build.gradle:

buildscript {
    repositories {
        maven { url 'https://plugins.gradle.org/m2/' } // Gradle Plugin Portal
    }
    dependencies {
        classpath 'gradle.plugin.com.onesignal:onesignal-gradle-plugin:[0.10.0, 0.99.99]'
    }
}
apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'

apply plugin: "com.android.application"

import com.android.build.OutputFile

/**
 * The react.gradle file registers a task for each build variant (e.g. bundleDebugJsAndAssets
 * and bundleReleaseJsAndAssets).
 * These basically call `react-native bundle` with the correct arguments during the Android build
 * cycle. By default, bundleDebugJsAndAssets is skipped, as in debug/dev mode we prefer to load the
 * bundle directly from the development server. Below you can see all the possible configurations
 * and their defaults. If you decide to add a configuration block, make sure to add it before the
 * `apply from: "../../node_modules/react-native/react.gradle"` line.
 *
 * project.ext.react = [
 *   // the name of the generated asset file containing your JS bundle
 *   bundleAssetName: "index.android.bundle",
 *
 *   // the entry file for bundle generation
 *   entryFile: "index.android.js",
 *
 *   // whether to bundle JS and assets in debug mode
 *   bundleInDebug: false,
 *
 *   // whether to bundle JS and assets in release mode
 *   bundleInRelease: true,
 *
 *   // whether to bundle JS and assets in another build variant (if configured).
 *   // See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
 *   // The configuration property can be in the following formats
 *   //         'bundleIn${productFlavor}${buildType}'
 *   //         'bundleIn${buildType}'
 *   // bundleInFreeDebug: true,
 *   // bundleInPaidRelease: true,
 *   // bundleInBeta: true,
 *
 *   // whether to disable dev mode in custom build variants (by default only disabled in release)
 *   // for example: to disable dev mode in the staging build type (if configured)
 *   devDisabledInStaging: true,
 *   // The configuration property can be in the following formats
 *   //         'devDisabledIn${productFlavor}${buildType}'
 *   //         'devDisabledIn${buildType}'
 *
 *   // the root of your project, i.e. where "package.json" lives
 *   root: "../../",
 *
 *   // where to put the JS bundle asset in debug mode
 *   jsBundleDirDebug: "$buildDir/intermediates/assets/debug",
 *
 *   // where to put the JS bundle asset in release mode
 *   jsBundleDirRelease: "$buildDir/intermediates/assets/release",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in debug mode
 *   resourcesDirDebug: "$buildDir/intermediates/res/merged/debug",
 *
 *   // where to put drawable resources / React Native assets, e.g. the ones you use via
 *   // require('./image.png')), in release mode
 *   resourcesDirRelease: "$buildDir/intermediates/res/merged/release",
 *
 *   // by default the gradle tasks are skipped if none of the JS files or assets change; this means
 *   // that we don't look at files in android/ or ios/ to determine whether the tasks are up to
 *   // date; if you have any other folders that you want to ignore for performance reasons (gradle
 *   // indexes the entire tree), add them here. Alternatively, if you have JS files in android/
 *   // for example, you might want to remove it from here.
 *   inputExcludes: ["android/**", "ios/**"],
 *
 *   // override which node gets called and with what additional arguments
 *   nodeExecutableAndArgs: ["node"],
 *
 *   // supply additional arguments to the packager
 *   extraPackagerArgs: []
 * ]
 */

project.ext.react = [
    entryFile: "index.js"
]

apply from: "../../node_modules/react-native/react.gradle"

/**
 * Set this to true to create two separate APKs instead of one:
 *   - An APK that only works on ARM devices
 *   - An APK that only works on x86 devices
 * The advantage is the size of the APK is reduced by about 4MB.
 * Upload all the APKs to the Play Store and people will download
 * the correct one based on the CPU architecture of their device.
 */
def enableSeparateBuildPerCPUArchitecture = false

/**
 * Run Proguard to shrink the Java bytecode in release builds.
 */
def enableProguardInReleaseBuilds = false

android {
    compileSdkVersion 27
    buildToolsVersion '27.0.1'

    defaultConfig {
        applicationId "com.********"
        minSdkVersion 16
        targetSdkVersion 22
        versionCode 1
        versionName "1.0"
        ndk {
            abiFilters "armeabi-v7a", "x86"
        }
        manifestPlaceholders = [onesignal_app_id: "********",
                                onesignal_google_project_number: "REMOTE"]
    }
    signingConfigs {
        release {
            if (project.hasProperty('MYAPP_RELEASE_STORE_FILE')) {
                storeFile file(MYAPP_RELEASE_STORE_FILE)
                storePassword MYAPP_RELEASE_STORE_PASSWORD
                keyAlias MYAPP_RELEASE_KEY_ALIAS
                keyPassword MYAPP_RELEASE_KEY_PASSWORD
            }
        }
    }
    splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false  // If true, also generate a universal APK
            include "armeabi-v7a", "x86"
        }
    }
    buildTypes {
        release {
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
    }
    // applicationVariants are e.g. debug, release
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            // For each separate APK per architecture, set a unique version code as described here:
            // http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits
            def versionCodes = ["armeabi-v7a":1, "x86":2]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) {  // null for the universal-debug, universal-release variants
                output.versionCodeOverride =
                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }
        }
    }
}

dependencies {
    compile project(':realm')
    compile project(':react-native-vector-icons')
    compile fileTree(dir: "libs", include: ["*.jar"])
    compile "com.android.support:appcompat-v7:27.0.1"
    compile ("com.facebook.react:react-native:0.53.0") {force = true}  // From node_modules
    compile(project(":react-native-google-signin")){
        exclude group: "com.google.android.gms" // very important
    }
    compile(project(":react-native-onesignal")){
        exclude group: "com.google.android.gms" // very important
    }
    // old version: 9.2.1
    compile 'com.google.android.gms:play-services-gcm:15.0.1'
    compile 'com.google.android.gms:play-services-analytics:15.0.2'
    compile 'com.google.android.gms:play-services-location:15.0.1'
    compile 'com.google.android.gms:play-services-auth:15.0.1'

    compile 'com.google.firebase:firebase-core:16.0.0'
}

// Run this once to be able to run the application with BUCK
// puts all compile dependencies into folder libs for BUCK to use
task copyDownloadableDepsToLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}

apply plugin: 'com.google.gms.google-services'

I tried everything but no luck.

@javadi69 Normally these these Could not find ... on jcenter are due jcenter() being before maven { url 'https://maven.google.com' } or google(). However in both these build.gradle files I see this is already correct.
Can you make sure this isn't the case in any other of the build.gradle files in your project? Can you also check your node_module folder as well? Lastly I recommend re-syncing gradle in Android Studio to make sure this is not the issue.

@jkasten2 I placed google() before jcenter() in all of my build.gradle files. but still that same error.
re-syncing give me error: Failed to resolve: firebase-messaging

I change classpath 'com.android.tools.build:gradle:3.1.0' to classpath 'com.android.tools.build:gradle:2.2.3' and it worked,
Any idea why i can't use latest gradle version?

@javadi69 Yes, many dependencies (especially in Expo-based react-native projects) require older versions of Gradle.
Our own Android SDK works fine with newer versions of gradle, but not react-native if your app was detached from Expo.


Adding support for clusters (like ROSA) that are labeled differently

ROSA created clusters are labeled differently. This adds support for other types of labelieng.
ROSA Cluster labels:
labels:
  hive.openshift.io/machine-pool: worker
  hive.openshift.io/managed: "true"

While the script currently expects:
labels:
  node-role.kubernetes.io/worker: ""

Results for SNAFU CI Test

Test
Result
Runtime

snafu/scale_openshift_wrapper
PASS
00:06:14


Add process_mode property to InterpolatedCamera

move_and_slide in _physics_process + InterpolatedCamera == stutter

Like this https://github.com/godotengine/godot/pull/24806 but for InterpolatedCamera
This allows the user to choose if the camera should update in _process or _physics_process.

Note that integrating lawnjelly's smoothing-addon is a better way to combat stuttering compared to updating the camera position in the physics process loop.

Thanks!


Update CONTRIBUTING.md to advise against force pushes

I think we're pretty much in agreement to avoid force pushes to PRs, so this changes the respective section in the contribution guide to reflect that (because it actually endorses the opposite).

It would be even more visible for contributors if the repository had a Pull Request template, with a link to the file in it.

It would be even more visible for contributors if the repository had a Pull Request template, with a link to the file in it.