RFC: PHPStan extension API for $this variable in closures

Hi,
there are some issues like https://github.com/nunomaduro/larastan/issues/877 or https://github.com/nunomaduro/larastan/issues/166 that could be solved by Larastan properly understanding what is $this inside Closure passed to certain methods.
Can you tell me more about what the logic is? If I'd understand a few use-cases about this, I could design an API that Larastan could make use of to properly describe the behaviour.
Is this only about macros? What are they? Or are there multiple functionalities in Laravel that would take advantage of this?

Hello Ondřej!
The most frequent one is binding a Closure it an object. In this Closure $this is the instance of Collection.
        Collection::macro('isAssoc', function () {
            return Arr::isAssoc($this->toBase()->all());
        });

Alright, two questions:

Where is the static macro method defined?
Can it be described like this? When there's a static call to ???::macro(), the second argument is a closure, the $this inside the closure is ???.

But I'm concerned about the declaring class of macro method, hope it's declared natively and not magically.

In the framework https://github.com/laravel/framework/blob/d43075467da598edf6376af0589bb4c58b07a3dc/src/Illuminate/Macroable/Traits/Macroable.php#L19-L29
Yes!

Hi,
Thank you for considering this!
Yes, mainly this is about macros. But I think this could apply to any other code in PHP that uses Closure::bindTo
In Laravel you can see the implementation of macro here. I guess the important parts are macro, __call and __callStatic methods.

When there's a static call to ???::macro(), the second argument is a closure, the $this inside the closure is ???.

Yes, that'd be correct.

The Call to undefined method Foo:setBar error is solved by this extension. Basically we read the protected macros property with reflection. And get the closure. And create ReflectionFunction from it and use it for parameters, return type etc.

Alright, I'll try to think of something but I won't rather promise any timeline as I can see some complications already:

the macro method is defined on a trait. "Declaring trait" is mostly hidden in PHPStan's Reflection APIs so you'd have to register the extension for all classes that implement the trait which isn't great.
The modern "no-code" approach would be to define some PHPDoc for this, something like @param-closure-this self $macro, but you can't use stub files for traits either, so that would have to be implemented first.

If it could be solved by a simple PHPDoc, I think it can be added to Laravel core. So no stub file would be needed.

I wouldn't rely on that. If I implement this, I'd be glad if Larastan users could use it right away and not wait for Laravel's decision as they're pretty conservative about this - it took Laravel a few years to have generics for Collection and it probably wouldn't happen without Nuno being on the core team :)

Support for @param-closure-this just landed in PHPStan 1.11.x-dev: https://github.com/phpstan/phpstan-src/commit/c8e1c8cbcbe502388d1cff237a9e1308cf837e89
PHPStan 1.11 is going to be released at some point in April or May, but you can already test this to see if it works for Laravel.

Support for @param-closure-this just landed in PHPStan 1.11.x-dev: phpstan/phpstan-src@c8e1c8c
PHPStan 1.11 is going to be released at some point in April or May, but you can already test this to see if it works for Laravel.

Awesome! I'll test this and see where we can make use of it.

Is this in larastan now? Automatically for Laravel's Macroable?

Is this in larastan now? Automatically for Laravel's Macroable?

Yes. But it's not released yet. I'll do it later this week.

Is this in larastan now? Automatically for Laravel's Macroable?

Yes. But it's not released yet. I'll do it later this week.

Still errors on protected methods, see #1252. Is that still a limitation of Phpstan?

There's a feature request for rebinding scope: https://github.com/phpstan/phpstan/issues/11010


clean-webpack-plugin 0.1.6 updates and fixes

clean-webpack-plugin API changed with 0.1.5. This adds the necessary changes.
Solves #826.

Thanks!


ReasonML

Small square png
png with full name

Hey,
is there a vector version?

Not with acceptable quality. I'm happy to take the time to make one and PR it.

Added in 6b63f545834a4d869ff11fb6e1405d871a037bf8
Thanks


Github links to the Bug Bounty CheatSheet

Hi @C15C01337

this is not the proper way of adding resources.
Please check some of the previous contributions to know more
Some of the resources that you have added are duplicate i.e. already present in the repo. So either you improve them or add unique one.

Hi @C15C01337
It looks like you have copy pasted from https://github.com/dwisiswant0/awesome-oneliner-bugbounty
I would suggest you,
If you thought, this repo is helpful then you add a direct link to this repo in our repo by giving him a credit.
Add in the appropriate place.

I didn't know that how to appropriately add the links to the repo in the
first place so I learned to create a folder and add a Readme.md file inside
the folder. I mistakenly forget to add the credit to the actual repo owner.
I apologize for that and will try to add more resources with appropriate
descriptions.
On Sat, Oct 8, 2022, 3:00 PM Prashant Bhapkar @.***>
wrote:

Hi @C15C01337 https://github.com/C15C01337
It looks like you have copy pasted from
https://github.com/dwisiswant0/awesome-oneliner-bugbounty
I would suggest you,
If you thought, this repo is helpful then you add a direct link to this
repo in our repo by giving him a credit.
Add in the appropriate place.
—
Reply to this email directly, view it on GitHub
https://github.com/Prashant-Bhapkar/Awesome-Security-Resources/pull/21#issuecomment-1272274307,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQYPWVP6DWQ4QMVOQC6LE6DWCE3RPANCNFSM6AAAAAAQ72MTU4
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

Don't copy-paste.
Do one thing,
just add the appropriate heading in this repo and just add a link to this "https://github.com/dwisiswant0/awesome-oneliner-bugbounty" repo

I did accordingly just added the link to the repo and asked for others to
add the repo if there is any other they know. I am really sorry for my
mistake done previously and I will never repeat it again. Waiting for your
acceptance, I have raised a pull request.
On Sun, Oct 9, 2022 at 12:12 AM Prashant Bhapkar @.***>
wrote:

Don't copy-paste.
Do one thing,
just add the appropriate heading in this repo and just add a link to this "
https://github.com/dwisiswant0/awesome-oneliner-bugbounty" repo
—
Reply to this email directly, view it on GitHub
https://github.com/Prashant-Bhapkar/Awesome-Security-Resources/pull/21#issuecomment-1272374017,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQYPWVKHI6ZTT3EZ4AN6LZTWCG4KBANCNFSM6AAAAAAQ72MTU4
.
You are receiving this because you were mentioned.Message ID:
@.***
com>


Blank message body

First time i see a message is not displayed at all, the message body area is completely blank and white.
It looks like this is a html message from Outlook. Rainloop CE <IP_ADDRESS>8
Message excerpt:
Subject: =?ISO-8859-1?Q?XXX,=A0200430544?=
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_Part_78_1485032645.1455527798073"
Importance: Normal
X-Priority: 3

------=_Part_78_1485032645.1455527798073
Content-Type: multipart/related;
	boundary="----=_Part_80_952829482.1455527798073"

------=_Part_80_952829482.1455527798073
Content-Type: text/html;charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=
=A0

...

D=FCsseldorf,=A015. F=
ebruar 2016

=A0

...

...

I have the same problem, but  with Content-Type: text/html;charset=koi8-r
UTF-8 works just fine, but I don't know, how to deal with those services that still send ancient charsets.

Could you give me<EMAIL_ADDRESS>the email message for test?

Sent it. Google send such charset with multipart Content/Type, encoded in base64
And it is read by Rainloop with no problem. Unfortunately Yandex is biggest Russian mail provider.

Everything looks great for me. Most likely you should install (or update) php-iconv / php-mbstring libs.

Can you please post a raw source of email? I wonder what it looks like.

http://pastebin.com/YyQAmJeA


Update base image Dockerfile

Update base image Dockerfile according to Dockerfile best practice. See RUN section.
According to official doc, RUN apt-get update in one line will cause caching issues if the referenced archive gets updated.

:+1: We should definitely be doing things this way

this needs to be rebased as we switched off sbt to gradle

#25 does this. Thanks for the hint


Low number of EMP 500 sample in data portal

@cmungall and I looked at for EMP 500 samples in the data portal on Friday. We found 80.
NCBI Biosample says that there are 1024 samples.
I am not an expert on the EMP studies, but this did seem like a big discrepancy to me.
I think I have heard one or more person say that many of the EMP 500 samples didn't meet some of our suitability criteria. @hubin-keio ? @Michal-Babins ? @sujaypatil96, since you obtained the biosample metadata from GOLD, do you have any insight into this?
I get the sense that there have been many separate studies in the Earth Microbiome Project initiative. Is it possible that we loaded the wrong one?
I am doing some more research in our SQLite version of NCBI's biosample_set now. That's available from https://portal.nersc.gov/project/m3513/biosample/biosample_basex.db.gz
CC @emileyfadrosh

This should probably be moved to a different repo

@sujaypatil96 remembers @dehays saying that there were only 80 soil samples

The ETL pipeline only pulled out data for the 80 soil samples from the EMP500 study that are in the GOLD database. To see a list of the 80 samples: https://github.com/microbiomedata/sample-annotator/blob/main/sample_annotator/clients/nmdc/input/soil_ids.txt

It would be interesting to review how the ~ 80 samples were identified as coming from a soil environment, but the count of useful EMP500 soil samples is not in dispute anymore.


Added describe_vpn_connections() to EC2.

Bumped version to 1.4.6

1.4.6 uploaded to PyPI.

Coverage remained the same at 39.295% when pulling 66a077de2d662199b4880f3b8ef4a5505ce04f89 on mikegrima:describe_vpn into 22810a0287d0fa9ea3399e108e262191bb47bed0 on Netflix-Skunkworks:master.


Provide serviceAccount token as token file in Slurm

Short Description of the issue

When serviceAccount field is filled (even for default one called "default"), the pod in Kubernetes automatically receive the token to talk to kubernetes API
ls -al /var/run/secrets/kubernetes.io/serviceaccount/
drwxr-xr-x    2 root     root           100 Dec 19 13:21 ..2024_12_19_13_21_43.446791399
lrwxrwxrwx    1 root     root            31 Dec 19 13:21 ..data -> ..2024_12_19_13_21_43.446791399
lrwxrwxrwx    1 root     root            13 Dec 16 18:01 ca.crt -> ..data/ca.crt
lrwxrwxrwx    1 root     root            16 Dec 16 18:01 namespace -> ..data/namespace
lrwxrwxrwx    1 root     root            12 Dec 16 18:01 token -> ..data/token

Additionally, the kubelet automatically add environment variables that contains Kubernetes API address and port (thanks to https://github.com/kubernetes/kubernetes/blob/v1.9.0/pkg/kubelet/envvars/envvars.go#L45-L48):
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_HOST=10..... (some ip)

There are other KUBERNETES variables, but these two are the minimum for my test case, Argo, to be able to communicate to Kubernetes API.
Environment

Operating System: Debian 13
Other related components versions: Kind 1.25

Steps to reproduce

deploy any pod, even with the default serviceAccount, this should not be in error
ls -al /var/run/secrets/kubernetes.io/serviceaccount/
env | grep KUBERNETES_

Logs, stacktrace, or other symptoms

Summary of proposed changes
See below

Ok I see a (long painful) path.

Add in InterLink current Role the ability to request serviceAccount token

- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]

In presence of this volume (this JSON is generated from volumes.String() and is a bit rearranged)

{
   "Name":"kube-api-access-kzzwz",
   "VolumeSource":"VolumeSource"{
      "Projected":"&ProjectedVolumeSource"{
         "VolumeProjection"{
            "VolumeProjection"{
               "ServiceAccountToken":"&ServiceAccountTokenProjection"{
                  "Audience":,
                  "ExpirationSeconds":*3607,
                  "Path":"token"
               },
            },
            "VolumeProjection"{
               "ConfigMap":"&ConfigMapProjection"{
                  "LocalObjectReference":"LocalObjectReference"{
                     "Name":"kube-root-ca.crt"
                  },
                  "Items":[

                  ]"KeyToPath"{
                     "KeyToPath"{
                        "Key":"ca.crt",
                        "Path":"ca.crt",
                     }
                  },
               },
            },
            "VolumeProjection"{
               "DownwardAPI":"&DownwardAPIProjection"{
                  "DownwardAPIVolumeFile"{
                     "DownwardAPIVolumeFile"{
                        "Path":"namespace",
                        "FieldRef":"&ObjectFieldSelector"{
                           "APIVersion":v1,
                           "FieldPath":"metadata.namespace"
                        },
                     }
                  }
               },
            }
         },
         "DefaultMode":*420
      },
   }
}

for token, in InterLink VK, request a service account token (see https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1205-bound-service-account-tokens#example-flow) . For simplicity, boundObjectRef can be null and validityDuration should hard-coded to 99999h, but it could be great if the first is attached to the pod UID. The second variable should stay at 99999h because otherwise it would be a PITA to have InterLink VK to API to Slurm Plugin renew the token periodically.
This token file should be put in the pod creation request from InterLink VK to API, and API to (InterLink Slurm) Plugin.
The InterLink Slurm Plugin should put this content to pod directory ~/.interlink/pod-uid-blabla/volumes/kube-api-access-66fbd/token
for ca.crt, InterLink VK should request content of configMap kube-root-ca.crt present in its namespace (something like this below, but in HTTP request)

kubectl get configmap -n [namespace name] kube-root-ca.crt
NAME               DATA   AGE
kube-root-ca.crt   1      97m

The content should be in pod creation request from VK to API to Plugin.
The InterLink Slurm Plugin should put the content to a file in ~/.interlink/pod-uid-blabla/volumes/kube-api-access-66fbd/ca.crt

for namespace, in InterLink VK, if we have
volume.Projected.Sources[0].DownwardAPI.Items[0].FieldRef.FieldPath == "metadata.namespace" then we put the namespace where we are in pod request creation, from VK to API to Plugin.
The InterLink Slurm Plugin should put this content to pod directory ~/.interlink/pod-uid-blabla/volumes/kube-api-access-66fbd/namespace
Note: this namespace is not interlink but it is the one where the serviceAccount exist.

Then the InterLink Slurm Plugin should add bind path to Singularity/Apptainer, from these file to the inside where the VolumeMounts want. Eg

    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-66fbd
      readOnly: true

is translated to Singularity --bind ~/.interlink/pod-uid-blabla/volumes/kube-api-access-66fbd:/var/run/secrets/kubernetes.io/serviceaccount

Just one quick comment. The projected accounts token will be rotated each hour.
I think there is no way around it, unless you pre create a token for a service account manually diabling the rotation (and the projection as well)


Typescript compiler errror Cannot find name 'F'. when compiling flagsmith in Angular project

I'm using flagsmith in a Angular project but are getting following typescript compile error:
✘ [ERROR] TS2304: Cannot find name 'F'. [plugin angular-compiler]

    node_modules/flagsmith/types.d.ts:72:46:
      72 │ ...hange = (previousFlags: IFlags<F> | null, params: IRetrieveInfo...

Workaround is to set "skipLibCheck": true in tsconfig but would like to avoid this.

This is fixed in 4.0.1 of flagsmith, flagsmith-es and react-native-flagsmith. Please re-open this if you are still having any issues. Thanks again 🚀 .

Works like a charm. Thanks for the quick fix ⏩


Update basic-exemple for #10

The failure is an unrelated JS issue.

The failure is an unrelated JS issue.


[NetAppFiles] Fix serialization

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


Load words from DB instead of loading it from json file

Hey ich would like to work on this Issue. If it is still open.

Yes, it's open.

Can you assignee the issue to me ?

Done


[btstest] test new UIA API functionality

Observations:

[x]    1) Should whitelist be able to be updated by account name? This would make using the API more simple.
[x]    2) Unable issue to issuer account without whitelisting after restricted_deposits flag is set- should the issuer be implicitly whitelisted?
[x]    3) Unable to wallet_transfer asset- always throws insufficient relay fee despite having shares to pay with.
[x]    4) Submitting bid / ask for restricted asset throws exception because account name isn't considered
whitelisted.
[x]    5) Need an API call for retracting a specified balance.

@robrigo I've made some fixes based on your feedback:

You now whitelist registered accounts (which allows for both the owner key and current active key) rather than individual addresses.

Issuer account should now always be implicitly whitelisted.

Fee problem with transfers should be fixed now.

Bid and ask failure should be fixed now.

I've added wallet_uia_retract_balance. There's not a real friendly way to get a balance ID for passing to this function--you can use blockchain_list_balances or wallet_account_balance_ids for example for testing. In the future we would also want something like a wallet_uia_retract_order for retracting funds tied up in market orders.

Let me know any additional feedback with the latest version. Thanks, and keep up the good work!

Thanks Vikram. I've started to update the tests to reflect these changes: https://github.com/robrigo/bitshares/commit/21e24f69c5b71f399f0e94e90e18ff20422d3a4a
As you said, it will be difficult to test wallet_uia_retract_balance due to the non deterministic nature of balance ID generation. Each run of the test produces different IDs, so we will need the btstest framework to include capturing of regex groups into variables that can be passed to the API calls.

@theoreticalbts Shouldn't there be some way to ensure deterministic balance IDs in the test(s) referenced here?


Very good but with z-order problem

Hi I try to use this lib but with a problem.
When I try to place this widget into my app and the menu is closed the overlay stay always on top. If I use it with a listview when the menu is closed and I try to scroll the listview the gesture is detected by menu and not by listview, this makes it unusable :(

Hi, would you send me your error code for our better support to you.

Hi, I cannot make an example because the problem became into my app and I cannot send you my app.
I try to explain you the problem.
Into a simple scaffold with a ListView when I add you lib and try to open and close the menu, after that the scrolling is not over the listview but always on the menu though if it not visible.

Hi, we fixed your request. Now it's on live & see the below link:
https://pub.dev/packages/flutter_boom_menu#-changelog-tab-
Thank you!

Very good now work very well


修正 Keynote 資訊拼字與標點

其實最重要原因是有個地方把 jserv 拼錯了 (jserve) XD
順手把一些標點改成正確的 code points (主要是把 straight quotes 改成 typographers’ quotes)。只是外觀上的問題而已，不影響內文。

順便問一下，外國人的簡介需要在中文版翻譯嗎？

Current coverage is 94.20%

Merging #116 into master will not affect coverage as of 8a8a5dd

@@            master   #116   diff @@
=====================================
  Files           31     31
  Stmts         1000   1000
  Branches         0      0
  Methods          0      0
=====================================
  Hit            942    942
  Partial          0      0
  Missed          58     58

Review entire Coverage Diff as of 8a8a5dd

Powered by Codecov. Updated on successful CI builds.

有人有空翻的話就翻 xd


Add ko installer to release workflow

This PR adds the ko installer to the release workflow to fix recent failures in CI when pushing new tags.
Signed-off-by: Adolfo García Veytia (Puerco<EMAIL_ADDRESS>

I think https://github.com/openvex/vexctl/pull/96 and this one should fix the release of the binaries
/cc @cpanato


Gatherling scraper fails

Fetching https://gatherling.com/deck.php?mode=view&id=58385 (cache ok)
Traceback (most recent call last):
  File "/home/discord/decksite/decksite/scrapers/gatherling.py", line 241, in lookup
    return decks_by_identifier[gatherling_id]
KeyError: '58174'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "run.py", line 86, in <module>
    run()
  File "run.py", line 31, in run
    task(sys.argv)
  File "run.py", line 79, in task
    s.scrape() # type: ignore
  File "/home/discord/decksite/decksite/scrapers/gatherling.py", line 27, in scrape
    i = tournament(url, name)
  File "/home/discord/decksite/decksite/scrapers/gatherling.py", line 52, in tournament
    return add_decks(dt, competition_id, final, s)
  File "/home/discord/decksite/decksite/scrapers/gatherling.py", line 93, in add_decks
    add_ids(matches, ds)
  File "/home/discord/decksite/decksite/scrapers/gatherling.py", line 246, in add_ids
    m['right_id'] = lookup(m['right_identifier']).id if m['right_identifier'] else None
  File "/home/discord/decksite/decksite/scrapers/gatherling.py", line 243, in lookup
    raise InvalidDataException("Unable to find deck with gatherling id '{0}'".format(gatherling_id))
shared.pd_exception.InvalidDataException: Unable to find deck with gatherling id '58174'
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7f94bb7916a0>

DELETE FROM `match` WHERE id IN (SELECT match_id FROM deck_match WHERE deck_id IN (SELECT id FROM deck WHERE competition_id = 495));
DELETE FROM deck WHERE competition_id = 495;

and re-run scraper cleared things up.
Might be better to make this more resilient but this sorts things for now.


System.IO.Compression.FileSystem is not included

after done a little research, i've found that System.IO.Compression.FileSystem.dll is in fact compatible to .NET Framework 4.0 and can run perfectly after a little modify, but since it's not included in this reference source, in theory i can't legally release a build which is compatible with 4.0 (i did use cecil to replace the depended enum type in 4.5, which is the only thing blocks developers from using it on 4.0)
is that due to license difference between this reference source & the zlib stuff?

Hmm, that's a good point. Not sure why this assembly is missing.

Any news regarding this? Would like to use it as a base for a Unity/UWP compatible zipping lib...


At-a-glance view of all tags affected in a changeset

I'm submitting a feature request
Brief Description
I'm suggesting a quick at-glance overview of all tags on all objects created, changed or deleted in a changeset, similar to how it's presented in the OSM Analytic difference Engine
What is the motivation / use case for this feature?
Since june 2015 I had been almost every day watching the "demo" instance of the OSM Analytic difference Engine, which covered the edit activity in Denmark (the North European country). I loved it a lot because it provided me with a quick at-a-glance overview of tags and objects affected by each individual changeset. Unfortunately the server was recently blocked from accessing the OSM api (and subsequently taken down), apparently because the load on the api was considered too high (I don't have any real technical insight in this, but occasionally talk to the author)
Coming to osmcha I'm feeling practically blind because I now have to click around quite a lot to get to the same information, that I could have at just a glance with the "OSM analytic tracker".  When I see a "Wiki* tag changed" flag or similar, I want to immediately see which one. Not have to dig a lot to find it.

Hi @Hjart
We made something similar on OSMCha: https://user-images.githubusercontent.com/666291/34695408-824871f0-f4a9-11e7-9968-ff41801e57ca.png
Have you used it?

Hi @Hjart
We made something similar on OSMCha: https://user-images.githubusercontent.com/666291/34695408-824871f0-f4a9-11e7-9968-ff41801e57ca.png
Have you used it?

I've used it a number of times and while it has it's advantages (direct link to objects), it does require clicking around a lot i order to see what was actually changed. I would really appreciate a nice flat list, so I wouldn't need all that clicking.
Over the years I occasionally used osmcha when the "demo" was down or I wanted to track something a week back or something like that, but always found the "demo" way more convenient for daily work.

Look at i.e. https://osmcha.mapbox.com/changesets/65527114?aoi=e500f2e1-e9ae-4585-90b2-f9b4d0faebbe . The Analytic Tracker would have shown me that a relation was deleted as well as the tags on it, right away. Osmcha tells me that 1 object was deleted. Nothing else. This forces me to open the osm changeset in order to know whether this was something important or not.

Unfortunately the server was recently blocked from accessing the OSM api (and subsequently taken down), apparently because the load on the api was considered too high

This is just not the case, you're jumping to conclusions here.

Uhm, that's quite unexpected. That other Github issue was never communicated to osm sysadmins, and by the time the first optimizations were in place, the site was still up and running.

Osm.expandable.dk went offline on december 3 or 4 . I sent Michael VL an email to notify him and December 5 he responded telling me that his access to the osm api  had been blocked. This is all I know

Hi,
The analytic tracker was indeed taken down because it could no longer access the API server from its current IP address. Running it from other IP addresses than what was back then osm.expandable.dk worked fine. While I cannot prove it, I assumed this was because it added too much load on the API server. I have since moved the domain osm.expandable.dk to another domain but has not resumed running the analytic tracker service. While I have continued doing optimization and minimizing the usage of the API, I have not restarted the service since I assume it would just get blocked again. Since the tracker supports the edit process I think it should be fair to use the API, however, thats not my call to make.


Update messaging

Overview:
Update messaging on homepage to reflect the open-source nature of the project.
What needs to be done:
Steps

Update messaging on homepage to reflect the open-source nature of the project and replace 'brought to you by the Fostrum team' to 'inspired by the folks at Fostrum'.

Criteria of success:

Text successfully updated

Stakeholder:
@aliserag

I can pick this one up! :) should have a PR pretty quickly

#33 was merged so this also needs to be closed @Aliserag  @NoirKomBatman


Clarification regarding bastion and private DNS zones

[Enter feedback here]
Under https://docs.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal#create-a-private-endpoint, step 9, this page indicates "Integrate with private DNS zone | Leave the default of Yes."
However, if you read the Bastion FAQ: https://docs.microsoft.com/en-us/azure/bastion/bastion-faq#can-i-use-azure-bastion-with-azure-private-dns-zones, it specifies very clearly "The use of Azure Bastion with Private endpoint integrated Azure Private DNS Zones is not supported at this time. Before you deploy your Azure Bastion resource, please make sure that the host virtual network is not linked to a Private endpoint integrated private DNS zone."
Which information is correct?

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

ID: 0f0990fc-9834-bde3-5e06-071c75fa89a5
Version Independent ID: 96f5df37-aa95-443d-2500-37665179ce89
Content: Quickstart: Create a virtual network - Azure portal - Azure Virtual Network
Content Source: articles/virtual-network/quick-create-portal.md
Service: virtual-network
GitHub Login: @KumudD
Microsoft Alias: kumud

Thanks for the feedback! We are currently investigating and will update you shortly.

@rajeevmv The Bastion FAQ explains correctly regarding the Azure services overlap with the names listed (core.windows.net
& azure.com), thus avoid integrating the endpoint with private DNS zone. This is correct and need to be setup as mentioned.
Please let us know if you have any further questions and we will be glad to assist further. Thank you!

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Show Contributors

Show the contribution list in README.md file
hint
you can use GitHub API to show contributors.

Hey @Muhammad-Shahid-Jamal I am interested in this project. Please assign this issue to me.

Sure @BkPankaj  Go Ahead

@BkPankaj also star the repo as well Thanks

@Muhammad-Shahid-Jamal I have added a contributors feature, fetching the data from the GitHub API. Please verify and merge the changes.


Can't zoom the map with scroll when it has a Draw interaction with freehand: true

If I set freehand: true in a new ol.interaction.Draw, I can't zoom the map using my scroll wheel.
It seems this is due to this line: https://github.com/openlayers/openlayers/blob/v4.3.4/src/ol/interaction/draw.js#L312 where we're stopping event propagation if freehand mode is on. This seems a bit too greedy, and it might be better to only stop event propagation when freehand mode is on and the event is a mousedown or mousemove.

The change you propose makes sense. Would you be able to provide a pull request?

@ahocevar for sure! I'll put something together this week


[BUG-Critical] packer build keeps failing on node enviroment

Describe the bug
I am using a remote docker container with a default node enviroment to run my deployment there. (Buddy.works)
Since a few days the build keeps failing and we are not able to reproduce this issue locally - it is only affected on the build server. I have found some issues after deep diving but i am not sure if they are related because i can only debug this on the remote container.
I am trying to debug and solve this issue for the past 7 days - it keeps going back to the packer/webpack config - i am just lost here - i also suspected it to be maybe path issue because we have "zero" issues locally on "Mac" or "Windows" computers.
Only on linux and this node box it makes issues.
To Reproduce
Steps to reproduce the behavior:

npm install
npm run build

Expected behavior
I expect the "packer build" command to exit if an error occurs.
I expect the packer build command to compile/analyze only my project code "NOT" node_modules! If we analyze also node_modules the headache goes bigger right now.
Log Output
packer build
Custom webpack configuration found /buddy/greenforce-v2/prod.config.js
- Compiling...
assets by status 6.14 MiB [cached] 302 assets
ERROR in ./src/styles/templates/collection.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/templates/collection.scss 1:154  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/templates/collection.js 11:0-48
ERROR in ./src/styles/templates/customers/login.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/templates/customers/login.scss 1:157  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/templates/customers/login.js 11:0-56
ERROR in ./src/styles/templates/customers/register.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/templates/customers/register.scss 1:157  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/templates/customers/register.js 11:0-59
ERROR in ./src/styles/templates/index.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/templates/index.scss 1:154  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/templates/index.js 11:0-43
ERROR in ./src/styles/templates/page.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/templates/page.scss 1:154  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/templates/page.js 11:0-42
ERROR in ./src/styles/templates/product.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/templates/product.scss 1:154  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/templates/product.js 11:0-45
ERROR in ./src/styles/theme.scss
Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ../../usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/cjs.js):
SassError: expected "{".
  ╷
1 │ import api from<EMAIL_ADDRESS>  │                                                                                ^
  ╵
  src/styles/theme.scss 1:151  root stylesheet
    at processResult (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:721:19)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/NormalModule.js:827:5
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:399:11
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:251:18
    at context.callback (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/loader-runner/lib/LoaderRunner.js:124:13)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass-loader/dist/index.js:54:7
    at Function.call$2 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:95949:16)
    at _render_closure.call$0 (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:83914:23)
    at Object.Primitives_applyFunction (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:6522:30)
    at Object.Function_apply (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/sass/sass.dart.js:13852:16)
 @ ./src/scripts/layout/theme.js 13:0-33
7 ERRORS in child compilations (Use 'stats.children: true' resp. '--stats-children' for more details)
webpack 5.53.0 compiled with 14 errors in 10026 ms
(node:40) UnhandledPromiseRejectionWarning: Error: Compile errors
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/cli/commands/build.js:42:48
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/webpack.js:141:8
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/HookWebpackError.js:68:3
    at Hook.eval [as callAsync] (eval at create (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/tapable/lib/Hook.js:18:14)
    at Cache.shutdown (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/Cache.js:150:23)
    at /usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/Compiler.js:1147:15
    at Hook.eval [as callAsync] (eval at create (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/tapable/lib/Hook.js:18:14)
    at Compiler.close (/usr/local/lib/node_modules/@hayes0724/shopify-packer/node_modules/webpack/lib/Compiler.js:1140:23)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:40) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:40) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Build finished successfully!

System (please complete the following information):

OS: Node 14.17.3
Node Version 14.17.3
NPM Version 7.19.1

Packer (please complete the following information):

Version (latest)

Found the issue its not related with packer.


buildenv: read propagated-user-env-packages line-by-line

Motivation
Since 3cb745d5a69018829ac15f7d5a508135f6bda123, the format of
propagated-user-env-packages has changed and propagated packages have not been
included by buildenv, including in the system environment.
The buildenv builder is modified to read propagated-user-env-packages
line-by-line, instead of expecting all packages on one line.
Testing

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

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

This is a rebuild-the-world bugfix, so nobody is going to merge this into staging until those boxes above are checked.
Input from any Perl experts is welcome. I think this will work now, but even with 16 cores it will take me a minute or two to find out. 🙄
@Ericson2314 Several things were broken by this. I expect if you had run the NixOS tests before merging, you would have discovered that and prevented this.

@ttuegel Sorry! I've been unsure of exactly how much testing staging PRs are supposed to receive---exhaustive testing is easier without a mass rebuild and rebuilding both stdenvs as I have been doing already takes a while.
In this specific case, I tried to grep for all instances of the changed files' names and audit them, but regrettably forgot that one. Part of the problem might have been that I originally I didn't intend to mess with propagated-user-env-packages, but then had to due to the the symlinking that occurs between it an the other.

This patch is not correct. Apparently, Perl does not trim trailing newlines when reading a file line-wise. 🙄

There's also a buildenv script in nix-env – does that mean it's broken now?

There's also a buildenv script in nix-env – does that mean it's broken now?

Yes. Both the Perl script in the released version and the unreleased C++ version are now broken.

Oh jeeze, did not realize I was changing an interface of Nix itself. Well, if we want to keep my change, Nix can be compatible with both the old and the new by reading in the entire file and breaking on white-space (in a double loop for example). I would be happy to make the patch.

Well, if we want to keep my change, Nix can be compatible with both the old and the new by reading in the entire file and breaking on white-space (in a double loop for example).

I think it would be better just to use buildEnv from Nixpkgs for nix-env. Note that Nix already depends on Nixpkgs because nix-shell uses runCommand. Making Nix compatible with both conventions doesn't suit the purpose of allowing spaces in store paths.
Arguably, Nix should not depend on Nixpkgs at all, but if it's going to, it should at least depend on high-level interfaces.

I would be happy to make the patch or the reversion.

I may be alone, but I would prefer not to revert this. I think newline-separated lists is the correct way to do it and ultimately the way we must go. We have already had one rebuild due to this, I would hate to revert it, incur another rebuild, and then eventually bring it back and get another rebuild.

OK, this works correctly on NixOS. Because it's a platform independent change, I expect it will work on macOS, too. It would be difficult to check every package that depends on this, because it's a mass rebuild, but if it's still broken, it's at least less broken now.

fixes #27565

Ugh. I bisected for hours to find those new printLines everywhere.
I think 3cb745d5a69018829ac15f7d5a508135f6bda123 and anything else that
introduced new printLines on master needs to be reverted ASAP.
Current master is completely broken. Both environment.systemPackages
and nix-env -i are unusable ATM.
After those changes are reverted this patch should be applied to master,
then nix's buildenv should be fixed (I see such PR in progress), then we
should wait a while for users to update their nix, and only then reapply
file format changes.

https://github.com/NixOS/nix/pull/1480 https://github.com/NixOS/nix/pull/1482 are the Nix 1.12 and 1.11 PRs for being compatible with space-separated or line-separated entries.

Right. Merging those two PRs into nix, merging this PR into master and
updating nix in nixpkgs would probably work for most users, but not in
every possible case.
The problem is that 3cb745d5a69018829ac15f7d5a508135f6bda123 silently
breaks nix semantics.
For instance, if one uses nix on non-NixOS system or doesn't use
nixos-rebuild on NixOS-like system then doing all of the above actions
will still leave one with an old version of nix that will build unusable
things without producing any errors. That's bad.
I see no other way to fix that except to revert
3cb745d5a69018829ac15f7d5a508135f6bda123 first, and then maybe pick it
back when everything else gets merged (note that you'll have to update
nixpkgs nix version check to ask for the new nix since that's a
backwards-incompatible change).
I puzzles me why you care about those newlines so much, just
sed 's/ /\n/' them on display or something if you read those
generated files so often.
/cc @edolstra because of his seal of approval on #27284

What I'm trying to say is this:
Current treatment of newlines in both buildEnv and buildenv can be
treated as a bug that needs to be fixed. True. (I imagine there're more
such parsing bugs for files stored in nix-support. What would happen
if I concatenate some junk to a random file there? Nothing too good, I
suspect.) Silently doing the wrong thing is bad.
But before 3cb745d5a69018829ac15f7d5a508135f6bda123 that bug was never
triggered.
Since 3cb745d5a69018829ac15f7d5a508135f6bda123 is not a killer-feature
by any measure, it triggers that bug for many sinless packages, and that
bug is rather hard to debug, 3cb745d5a69018829ac15f7d5a508135f6bda123
needs to be reverted ASAP.
It can be cherry-picked back when the bug is dealt with, but not before.

@oxij I'm not against reverting---it would be more work for me but I have already caused more work and pain than than that from the reversion for many other people.
But I do think the line-based way is ultimately better, which I think everyone agrees. Insofar that the patches move us one step closer to that, and do not interfere with a revert, I see no issues with merging them once I can test them.
Also, keep in mind for users that can update Nix manually, doing so is a more immediate solution than waiting for the channels to catch up to the revert.

I'm not against reverting---it would be more work for me but I have
already caused more work and pain than than that from the reversion
for many other people.

Why? I reverted it locally without any conflicts and no problems since.

But I do think the line-based way is ultimately better, which I think
everyone agrees.

I don't. Why not go all the way to IFS="\0" then? Paths can have
newlines in them too. Since neither space nor newline can be used in
shebangs I don't see any difference between those two for building
executable packages with nix. And if I wanted to use nix-store as a
generic storage interface or something I would go for '\0'.

Insofar that the patches move us one step closer to that, and do not
interfere with a revert, I see no issues with merging them once I can
test them.

I don't understand what you are talking about. I don't see any
substantial followups in master ATM. All I ask is to revert
3cb745d5a69018829ac15f7d5a508135f6bda123 because of the

pain

From my point of view it looked like this: an old revision worked
perfectly, master failed, hundreds commits in between. "Okay, then."
Debug the package in question until "aha, it doesn't propagate packages
anymore" discovery (minutes), check history for anything obvious (~half
an hour), nothing, "Okay, then.", write a simple script that checks that
the package propagates its deps into result (minutes), bisect nixpkgs
with that script, wait awhile (days), as there was a mass rebuild on
almost every step, revert the culprit, "Aaaaah, finally.", argue that
the source of that misery needs to be reverted in master so that other
people won't need to repeat that (hours).

Also, keep in mind for users that can update Nix manually, doing so
is a more immediate solution than waiting for the channels to catch up
to the revert.

Except.

How do I know that this new silent "behavior" is supposed to be
fixed by updating nix?

What if I use nix provided by my distro and have no idea how to build
it myself?

Is it normal that nix-env -i <package> for nix before those two PRs
for nix and the same nix-env -i <package> after produce completely
different environments on the same revision of nixpkgs?

(Because produced environments don't depend on nix version. Should
packages depend on nix version they are build with?)

How do I know that I should not only update my nix, but also to rebuild
all my user environments to get the fix?

My point is: if you want to keep
3cb745d5a69018829ac15f7d5a508135f6bda123 in master and have everything
work as it should (without any craziness itemized above) you should
update lib/minver.nix in nixpkgs to require a future nix version.
This, of course, will break evaluation for everyone until that future
version comes out. Which strongly suggests that
3cb745d5a69018829ac15f7d5a508135f6bda123 needs to be reverted for
everyone now.
I've already spent my time bisecting the problem and reverted its source
(and will keep reverting any followups until lib/minver.nix gets
updated, because we don't just break things in SLNOS). But you are free
to do whatever, of course.
In any case, you have to consider that there are some poor nixpkgs users
struggling with the side effects of that change right now. And some of
them would feel those effects for quite awhile after everything gets
"fixed" because nix with 3cb745d5a69018829ac15f7d5a508135f6bda123
propagates at least some of the problems directly into /nix/store and
you'll have to --gc and rebuild those environments to fix that. (Which,
by the way, is another reason to use buildEnv from nixpkgs in nix
instead of the builtin buildenv, but I digress.)

@oxij Ah, I didn't realize that was an easy revert---I got confused with the Darwin problems I also caused which are less so.

propagates at least some of the problems directly into /nix/store

Woah. Ok that's real bad CC @edolstra. I'm reverting now.

Which, by the way, is another reason to use buildEnv from nixpkgs in nix instead of the builtin buildenv, but I digress.

Well, it is interesting and not coincident that the breakage I cause both this this and Darwin nix-env stem from impurities. I would like to see some real solutions to the long-standing warts around both of those.

Done in https://github.com/NixOS/nixpkgs/commit/b087618ac06256cb3c06278e7eaba45841f4ea91

@oxij Now that that is done, I would like to talk about changing the format in a more controlled process. @ttuegel This unfortunately would mean yet another mass rebuild, but are you still interested in switching away from space-separated?
I wouldn't be opposed to \0 as a deliminator. My reasoning for '\n'-deliminated was that, as we don't support arbitrary path, it is both easiest to read as a human, and easiest to work with in lousy scripting languages.

@Ericson2314 so will you merge master into staging now then?
I've just encountered an odd bug on staging that doesn't happen on master.
$ nix-build -A python.pkgs.oslo-config
these derivations will be built:
  /nix/store/96ywyrxfhl7lqi07mdjx0zqbnwcv0izj-python2.7-oslo.config-2.5.0.drv
building path(s) ‘/nix/store/wgb3i1kchx8g09qxsgg2yvyfjxpafyya-python2.7-oslo.config-2.5.0’
unpacking sources
unpacking source archive /nix/store/y7wdfdh7jfic9j1bss9v6qw32zbvgbz1-oslo.config-2.5.0.tar.gz
source root is oslo.config-2.5.0
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file oslo.config-2.5.0/setup.cfg
patching sources

builder for ‘/nix/store/96ywyrxfhl7lqi07mdjx0zqbnwcv0izj-python2.7-oslo.config-2.5.0.drv’ failed with exit code 1
error: build of ‘/nix/store/96ywyrxfhl7lqi07mdjx0zqbnwcv0izj-python2.7-oslo.config-2.5.0.drv’ failed

Another failure without any helpful output. Note that b087618 doesn't matter.

I wouldn't be opposed to \0 as a deliminator. My reasoning for '\n'-deliminated was that, as we don't support arbitrary path, it is both easiest to read as a human, and easiest to work with in lousy scripting languages.

The only thing I have to say is: if we are going to use something weird (i.e. not \n and not  ) then we should use one of the ASCII delimiter characters.

There are only paths of the first level of /nix/store, so the character set is limited, no \n nor space is expected

Reverted

Yay! Thanks!

I wouldn't be opposed to \0 as a deliminator. My reasoning for '\n'-deliminated was that, as we don't support arbitrary path, it is both easiest to read as a human, and easiest to work with in lousy scripting languages.

GNU tools support -z and similar options for millennia.
E.g. I regularly do something like
find . -iname '*.jpg' -print0 | sort -zR | head -zn 1 | xargs -0 -I{} qiv -if {}
in directories with some crazy filenames and it just works (this shows a
random jpg with qiv).

The only thing I have to say is: if we are going to use something weird (i.e. not \n and not  ) then we should use one of the ASCII delimiter characters.

Should not. Any char except '\0' and '/' can be in a file system name as
per POSIX 1003.1-2001.

@oxij So I'm now thinking it's import that when reading we support both ' ' and whatever the new deliminator is, not only so new Nix supports old nixpkgs, but so that packages from different nixpkgs can be mixed together. It wouldn't be a breaking change for Nix or Nixpkgs, but just a bump of lib/minver.nix. The old deliminator, ' ' would be considered deprecated, however. Down the road, when Nixpkgs has been using the new deliminator for a major release or two, we can then stop accepting it on read---a breaking change but one causing little breakage in practice.
Given that plan, however, I find using '\0' somewhat unpalatable because that would mean using \0 and ' ' as deliminator which strikes me as very odd / giving a false sense of security. But, I could be convinced as the plan is to deprecate ' '.

The more I think about it the more I like the '\0'. However, mixing ' '
and '\0' doesn't feel right, I agree. The solution is to allow '\0' xor
' ' (not both) in a single file.

Down the road, when Nixpkgs has been using the new deliminator for a
major release or two, we can then stop accepting it on read---a
breaking change but one causing little breakage in practice.

I would prefer if nix/buildEnv would start complaining about the ' '
early (something like "Your environment is using a package ${name}' with a package metadata format that is deprecated. Please upgrade ${name}' or remove it from your environment.").
Also, there's a case of really old nix trying to use internal buildenv
with a new package format (use case: build on a testing machine with a
new nix, copy closure to a stable production machine, nix-env -i the
result).
I see no graceful way to handle that except make packages to have a kind
of "metadata version" which nix should start checking as soon as
possible.

Noting here that both b087618a and f6f40e3f were nominal reverts of 3cb745d5a69018829ac15f7d5a508135f6bda123.  They were merged in https://github.com/NixOS/nixpkgs/commit/9be40841ea4251a09ae7a1023abc1b6d191f61bb, where the approach of f6f40e3f was taken.  So the net result on both master and staging currently is not an exact revert of 3cb745d5a69018829ac15f7d5a508135f6bda123.
I'm not familiar enough with nix to really say whether that matters.
However, I'm in the process of building a nix expr for OpenJDK 9 over in #27194, and need to know whether I should be using echo -n or printWords in my 9.nix, which is a copy of 8.nix.  Thanks!

@jerith666 it probably doesn't matter, but try printWords.


Improvements to TerminalInput

Modernization and light cleanup of TerminalInput.cpp and .hpp.
Addresses Issue #685

@Nicholas-Baron
You might want to set up an email alias on your GitHub account 🥇
Or look into fixing your git user.email config 😅
to get proper credit for your commits 🏆
https://help.github.com/articles/adding-an-email-address-to-your-github-account/
https://help.github.com/articles/setting-your-commit-email-address-in-git
then to amend your commits: https://stackoverflow.com/a/3042512
You can see your email used here: https://github.com/microsoft/Terminal/pull/690/commits/bdb587dc359481c97961b776703e67f11bd6b94a.patch


Make Sisimai::Lhost::* Faster take.2

#354
Divide a message body into message/delivery-status part and message/rfc822 part
About 30% faster than v4.25.4p6
Decrease about 15% at lines of code
Sisimai::RFC5322->fillet divides entire message body

Coverage increased (+0.6%) to 95.099% when pulling 2655b52c15e9f013a568da8a3ebad6bbb4a56172 on 354-make-lhost-faster-take-2 into 2300425e08e357cb39952fdefd17b6c48ebd5d5a on master.


[docs] Document that go-metro is not available with A6

What does this PR do?
Documents that go-metro is not available with A6 (for now at least)
Additional Notes
pinging @l0k0ms since this affects docs
See also counterpart PR on datadog-agent: https://github.com/DataDog/datadog-agent/pull/1419

@olivielpeau thanks for the ping :) G2G for me !


Fix module build, add TS declaration files, fix search addon

This introduces a breaking change to importing the project, the README file has been updated to reflect this. It's now exporting an ES6-style module which can be imported without the use of require. This was done because I couldn't get the build to work without making this change and because it's moving towards the future. You can still require using regular JavaScript, but there's a Terminal object on the default export.
src/xterm.ts still lives on but it is only the entrypoint for browserify now. This is mentioned in the header.
Fixes #865
Fixes #866
Fixes #867

Verified core lib and search addon works in demo on Chrome.
Verified core lib and search addon in VS Code:
// Old (legacy import):
import Terminal = require('xterm');

// New:
import { Terminal } from 'xterm';

Verified TS Server picks up declarations/typings using a simple TS file:

Coverage decreased (-0.02%) to 71.465% when pulling f21d5f25ecaa6c1c843ee6b2761c7958e1eb16ed on Tyriar:865_fix_module_build into acefa1a4239a63957eaf366adcdf57ff633fade3 on sourcelair:v3.


Update README.md

Added some clarification about roles and dependencies and bash-friendly variable substitution

cheers. interested to hear if you use this. we've found it indispensable

yes thanks for releasing this!


Add FAIcon to TabItem

@flozz Here is my proposition for adding FAIcon to the TabItem.

Wrong branch... Sorry.


v0.15.x rebase

Rebase SharperShape's changes on top of v0.15.x branch

@bemyak ...Tegola released 0.15.0 the day after you created this PR 😅 https://github.com/go-spatial/tegola/releases/tag/v0.15.0 Maybe you could rebase on top of that?
Also, the reason for this change is that we want to use Postgres 13. I propose to test it as follows:

Ask cloudops or Bastien directly to create an aurora-13 version of our postgres image. (BTW, at the same time he can delete the rds tag, we don't need it anymore.) Then you can use the rebased tegola in vector-tile-service and run tests. They don't really test much, but will fail if the service fails to connect to the DB.
Restore the eu Aurora DB from a snapshot, upgrade it to 13 and temporarily change vector-tile-service env vars in eu to connect to that instance. If you can see Assets in viewer and requests for .pbf files in the Chrome Inspector, then the service has successfully connected to Postgres 13.

Git history in the upstream is a bit messed up: the v0.15.0 tag is assigned to a deattached commit, and v0.15.x branch was deleted. I propose keeping this branch, to ease any potential further development.

Git history in the upstream is a bit messed up: the v0.15.0 tag is assigned to a deattached commit, and v0.15.x branch was deleted. I propose keeping this branch, to ease any potential further development.

We can also rebase our master onto v0.15.0 tag since we use master as the main development branch in all other repos. Unless you think it would make things complicated for the next upstream rebase.

@emreisikligil, currently our master is in sync with the upstream. The only thing missing from the official v0.15.0 release is this minor CI change. To me, it seems like the author has pushed the tagged commit and simply forgot to push the master branch. I'd rather wait instead of rebasing.

I've verified that it works with our vecror-tile-service, proceeding with merging.


Fix building with bgfx-debug feature

Also add github CI workflow to ensure bgfx-debug feature is tested

Thank you for the work done here, on the wrapper and for the quick merge!

np! I'm happy people find it useful :)


Update rails to include cve fixes on actionpack

Update Rails to include CVE fixes on actionpack.
bundle-audit logs
Name: actionpack
Version: <IP_ADDRESS>
CVE: CVE-2023-28362
Criticality: Unknown
URL: https://discuss.rubyonrails.org/t/cve-2023-28362-possible-xss-via-user-supplied-values-to-redirect-to/83132
Title: Possible XSS via User Supplied Values to redirect_to
Solution: upgrade to '~> <IP_ADDRESS>', '>= <IP_ADDRESS>'

Vulnerabilities found!

Pull request checklist

[x] My code contains tests covering the code I modified
[x] I linted and tested the project with bin/check
[ ] I added significant changes and product updates to the changelog

@joemasilotti : I have 2 questions about this PR:

Is this type of upgrade required to add an entry to changelog?

bundler-audit in the gemfile (and in the CI next)
I usually setup bundle-audit on CI to check and RED CI when there are CVE on dependencies, but with dependabot that sometimes is not necessary.
For private apps that focus the dev team to prioritize dependencies update over other features.
For OSS repo, and with dependabot, where you don't have compliance requirements, I sometimes find that too much.
What are your thoughts on it?

No CHANGELOG entry is required for this
I don't think we need bundler-audit, especially with dependabot. Let's remove it.

For reference purposes: https://github.com/rails/rails/pull/48705

Updating: there is a fix that has been merged: https://github.com/rails/rails/pull/48730
I will give it a try.

@joemasilotti : I've tried updating rails to latest main branch, to see if the fix on https://github.com/rails/rails/pull/48730 would solve the CI issue, but it actually add several new failures.
Just a glimpse:
bundle exec rails test
...
674 tests, 1633 assertions, 1 failures, 14 errors, 0 skips

This is the most common error:
Error:
LinkedinProfileFetcherTest#test_handles_error_response_from_API:
RuntimeError: Unknown enum attribute 'sites' for Developers::ExternalProfile
    app/models/developers/external_profiles/linkedin_profile_fetcher.rb:34:in `upsert_external_profiles'
    test/integration/developer_external_profiles/linkedin_profile_fetcher_test.rb:46:in `block in <class:LinkedinProfileFetcherTest>'

But there are also 2 i18n CI failures, and one related to Cannot get a signed_id for a new record.
Anyway, it appears there may have some newer regressions in rails main, coming in rails 7.1.0 that will need more work.
IMO: next step are:

close this PR
open a draft with rails main to get visibility of the new regressions and try to identify
get a new PR with this and this change.

Please let me know your thoughts.

Thanks for this @heliocola! Merging as soon as CI passes.


Update libopus static library to correct arch for darwin arm64

See https://github.com/pion/mediadevices/pull/368#issuecomment-1114623571

@edaniels This is just removing, did you also intend to add the correct one?
thanks for opening this PR!

@Sean-Der It's a modification! Curious that it's not an add and remove since it's binary.

@edaniels Could you update
https://github.com/pion/mediadevices/blob/master/dockerfiles/darwin-arm64.cmake
https://github.com/pion/mediadevices/blob/master/dockerfiles/darwin-arm64.Dockerfile
to make it cross-compilable?
All other static libraries are built by the scripts in https://github.com/pion/mediadevices/tree/master/dockerfiles and it's very hard to be maintained in the future without cross-compilation.

I did this via the make target so there's no changes to make. It looks like the wrong file was originally committed :)

Is pkg/codec/openh264/lib/libopenh264-darwin-arm64.a incorrect as well?

lookin good 8)
Non-fat file: ./pkg/codec/openh264/lib/libopenh264-darwin-arm64.a is architecture: arm64
Non-fat file: ./pkg/codec/openh264/lib/libopenh264-darwin-x64.a is architecture: x86_64


fix support FieldBased feature on field for issue #2350

What this PR does / why we need it?
fix support FieldBased feature on field
Summary of your change
Please indicate you've done the following:

[ ] Made sure tests are passing and test coverage is added if needed.
[ ] Made sure commit message follow the rule of Conventional Commits specification.
[ ] Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.42%. Comparing base (021facc) to head (d35541f).

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #2357      +/-   ##
============================================
- Coverage     77.42%   77.42%   -0.01%
+ Complexity    22770    22769       -1
============================================
  Files           634      634
  Lines         85390    85392       +2
  Branches      19368    19369       +1
============================================
- Hits          66114    66111       -3
- Misses        11253    11256       +3
- Partials       8023     8025       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Allow configurable output directory

-o, --outputdirectory -> Specify in which folder the per-domain subfolders will be created

In the interim, the script should be able to handle this by calling the script from the intended output directory. E.g.
cd /home/me/outputdirectory
/root/BugBountyScanner.sh -d target1.com

Will output in /home/me/outputdirectory/target1.com/


Music is broken

Current release branch fails to connect to a voice channel

Fixed in 574835b. Was a small oversight on my part.


⚠ Bofrost.fr has degraded performance

In 8a3f344, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1072 ms

Resolved: Bofrost.fr performance has improved in 538cf54 after 7 minutes.


require play, pause and stop events

Could you please explain in detail? Play and pause are already there right? And why stop when you could just pause?

I need the on Start () button to start it. I wonder if you can. Slider (for rewind) disable feature required.

We can understand that it has stopped but you do not return any information that it has started. I want to disable items on my page when it starts playing

Can we turn off the STOP feature. Can he steal once to the end? you can't stop

any solution please.. @vmudigal

@karincayazilim, I will work on this. :)

not working in IOS thanks you

Hello, I need to stop track when user click on button but not at player button, how can I do it?

Fixed in v12.0.1


Add back caret prefix to react and redux versions

Reference: c790172c5
Fixes #2330

Current coverage is 100% (diff: 100%)

Merging #2331 into master will not change coverage

@@           master   #2331   diff @@
=====================================
  Files          61      61
  Lines        1267    1267
  Methods         0       0
  Messages        0       0
  Branches        0       0
=====================================
  Hits         1267    1267
  Misses          0       0
  Partials        0       0

Powered by Codecov. Last update 8857778...e09a61a

Oops. I was fighting some dep conflicts with nyc test coverage.

Published in v6.4.1.


Created a socket event listener 'Player 2 joined' and broadcast the message to the room with the id.

Created a socket event listener 'Player 2 joined' and broadcast the message to the room with the id.
The response was passed to the DOM and the user was in memory

Solves Issue #227
Test link
https://chess.zuri.chat/test

Kindly fix the merge conflict boss 🤲🏾

It's unclear what is happening here and what the user story being addressed is.

The end point is adding a user to a chess channel (which is coming from the frontend) and broadcast to the other person in the room that some player has join same room.


add SlickStack (new technology request)

I hope this PR is correct. SlickStack is detected by a single HTTP "X-Powered-By" header that does not include any version numbers, ever.
Ref: https://slickstack.io
Ref: https://trends.builtwith.com/framework/SlickStack

Thanks!


Logging Facility does not create new ILogger per web request

One of the items logged when using NLog is 'Count'. Simple way for us to watch the call progression on a given thread.
When using the Logging facility on our MVC applications we are seeing that the Count is not resetting per web request and will continue to increment until IIS is recycled.
After digging around I can not see to find a way to have the Logging Facility create a new ILogger instance per web request. Seems like this would be a common desire.
NOTE: Im very new to castle.windsor so if this is something simple and im just missing it them my apologies.
I have this questions open on SO

was able to work around it with the following, what is lost by not using the facility?
Thanks,
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            container.Register(
                Component
                    .For<ILoggerFactory>()
                    .ImplementedBy <NLogFactory>()
                    .DependsOn(Dependency.OnValue("configFile", "nlog.config"))
                    .LifestylePerWebRequest(),
                Component.For<ILogger>()
                    .UsingFactoryMethod(
                        (kernel, model, context) =>
                        {
                            var logger = kernel.Resolve<ILoggerFactory>()
                                .Create(context.Handler.ComponentModel.ComponentName.Name);
                            return logger;
                        })
                    .LifestyleTransient()
                );
        }

Hey,
I may be off base with what you're wanting to do, but i think you've got your lifestyles mixed up. The factory should have a singleton lifestyle and the logger should have a PerWebRequest lifestyle because it's that you want to have one per request?
The factories lifestyle has no affect on the items it creates. Using the factory method the way you are is allowing it to work because every time it creates the transient object it is then resolving a new factory if it's a new request.
container.Register(
                Component
                    .For<ILoggerFactory>()
                    .ImplementedBy <NLogFactory>()
                    .DependsOn(Dependency.OnValue("configFile", "nlog.config")),
                Component.For<ILogger>()
                    .ImplementedBy <NLogger>()
                    .LifestylePerWebRequest()
                );

Good point, I'll check that out. Thanks for the input. What your saying
makes sense so I'll see if it ends with the desired result and post back.
Still feel like I should be able to get a per web request logger using the
facility out of the box.
-Chris
On Aug 28, 2015 7:03 PM, "Dale Francis"<EMAIL_ADDRESS>wrote:

Hey,
I may be off base with what you're wanting to do, but i think you've got
your lifestyles mixed up. The factory should have a singleton lifestyle and
the logger should have a PerWebRequest lifestyle because it's that you want
to have one per request?
The factories lifestyle has no affect on the items it creates. Using the
factory method the way you are is allowing it to work because every time it
creates the transient object it is then resolving a new factory if it's a
new request.
container.Register(
Component
.For()
.ImplementedBy ()
.DependsOn(Dependency.OnValue("configFile", "nlog.config")),
Component.For()
.ImplementedBy ()
.LifestylePerWebRequest()
);
—
Reply to this email directly or view it on GitHub
https://github.com/castleproject/Windsor/issues/93#issuecomment-135907338
.

Hey,
Well you will out of the box but its the service that needs the right life-style

Can you give me an example?
-Chris
On Aug 31, 2015 1:11 PM, "Dale Francis"<EMAIL_ADDRESS>wrote:

Hey,
Well you will out of the box but its the service that needs the right
life-style
—
Reply to this email directly or view it on GitHub
https://github.com/castleproject/Windsor/issues/93#issuecomment-136431416
.

Can do, I am working on a small asp thing this week so I'll incorporate
this and send some code
On Fri, Sep 4, 2015 at 4:36 PM pcKris<EMAIL_ADDRESS>wrote:

Can you give me an example?
-Chris
On Aug 31, 2015 1:11 PM, "Dale Francis"<EMAIL_ADDRESS>wrote:

Hey,
Well you will out of the box but its the service that needs the right
life-style
—
Reply to this email directly or view it on GitHub
<
https://github.com/castleproject/Windsor/issues/93#issuecomment-136431416>
.

—
Reply to this email directly or view it on GitHub
https://github.com/castleproject/Windsor/issues/93#issuecomment-137878638
.

Ping for progress on this one
-Chris
On Sep 4, 2015 7:52 PM, "Dale Francis"<EMAIL_ADDRESS>wrote:

Can do, I am working on a small asp thing this week so I'll incorporate
this and send some code
On Fri, Sep 4, 2015 at 4:36 PM pcKris<EMAIL_ADDRESS>wrote:

Can you give me an example?
-Chris
On Aug 31, 2015 1:11 PM, "Dale Francis"<EMAIL_ADDRESS>wrote:

Hey,
Well you will out of the box but its the service that needs the right
life-style
—
Reply to this email directly or view it on GitHub
<

https://github.com/castleproject/Windsor/issues/93#issuecomment-136431416>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/castleproject/Windsor/issues/93#issuecomment-137878638>
.

—
Reply to this email directly or view it on GitHub
https://github.com/castleproject/Windsor/issues/93#issuecomment-137879878
.

@workabyte - please feel free to ping back on this issue, I am clearing out the backlog to keep things relevant for Castle.Windsor.
Closing for now will ask for forgiveness later :)


StaticFileContext.ValidateMethod wrongly named

The ValidateMethod in the StaticFileContext should probably be named IsValidMethod.

I don't see why. It's doing more work than the IsXXX properties.

It does not really do any action, it just checks conditions.
It checks if something is valid by checking if the HTTP request method is a GET or a HEAD.

This issue was moved to aspnet/Home#2443


MGMT-16979: Optimize Alarm server requests

Use Alertmanager filter API for optimizing the Alarm server requests. The supported properties for now are (mapping from O2 to Alertmanager):

alarmDefinitionID --> alertname
probableCauseID --> alertname
extensions/{key} --> {key}

/approve
/lgtm


Conan

Reference Issue

What does this implement/fix? Explain your changes.
Any other comments?

Let's merge?


Raise pidfile wait timeout

Docker has some problems with the network hook that sometimes takes a long time on some systems due to fsync. This raises the timeout to 15 sec.
Signed-off-by: Tonis Tiigi<EMAIL_ADDRESS>

LGTM.
Although, since users can specify hooks, I'd probably add an option for specifying the timeout length :)


Added body to SuperAgentRequestAdapter

The PR was supposed to be on the fork repo, and github opened here automatically


unzip datasets.zip error

Archive:  datasets.zip
warning [datasets.zip]:  zipfile claims to be last disk of a multi-part archive;
  attempting to process anyway, assuming all parts have been concatenated
  together in order.  Expect "errors" and warnings...true multi-part support
  doesn't exist yet (coming soon).
file #1:  bad zipfile offset (local header sig):  4
file #2:  bad zipfile offset (local header sig):  43
file #3:  bad zipfile offset (local header sig):  87
file #4:  bad zipfile offset (local header sig):  3472375
file #5:  bad zipfile offset (local header sig):  8800734
file #6:  bad zipfile offset (local header sig):  8800781
file #7:  bad zipfile offset (local header sig):  8800872
file #8:  bad zipfile offset (local header sig):  8801829
file #9:  bad zipfile offset (local header sig):  9547300
file #10:  bad zipfile offset (local header sig):  20530956
file #11:  bad zipfile offset (local header sig):  20531003
file #12:  bad zipfile offset (local header sig):  20531177
file #13:  bad zipfile offset (local header sig):  20532155
file #14:  bad zipfile offset (lseek):  75014144
file #15:  bad zipfile offset (local header sig):  75016487
file #16:  bad zipfile offset (lseek):  75481088
file #17:  bad zipfile offset (lseek):  76800000
file #18:  bad zipfile offset (lseek):  77160448
file #19:  bad zipfile offset (lseek):  78184448

problem solved:

cat datasets.z01 datasets.zip > single.zip
unzip single.zip

problem solved:

cat datasets.z01 datasets.zip > single.zip
unzip single.zip


Adds dbmanager cache into an examle

When I used the RBAC first time, I didn't know about the dbmanager caching. I was relaying on the examples only. Then I saw many queries in my logs and started searching to eventually find the cache property.
I think there isn't a situation, when someone doesn't use caching for dbmanager rbac, so i'ts very helpful to put it in the example above.
Hope I'm correct.

Q
A

Is bugfix?
no

New feature?
no

Breaks BC?
no

Tests pass?
yes

Fixed issues
-

Merged. Thanks!


[Select] Component throws warning about not using 'selected' on

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
Controlled select throws this warning when rendering its list of options:
Warning: Use the defaultValueorvalueprops on <select> instead of settingselected on <option>.
All other behavior is normal: value is set when looking at react dev tools, value can be seen correctly.  onChange callback has access to the value.  I'm having trouble when looking at packages/src/Select/SelectInput.js finding out what is being passed from this controlled select that React doesn't like.
Making this a native Select does not show this behavior.

Expected Behavior 🤔
No warning thrown

Steps to Reproduce 🕹

import React, { useState, Fragment } from "react";
import Select from "@material-ui/core/Select";
const App = () => {
  const [itemType, setItemType] = useState("custom");
  return (
    <Fragment>
      <Select value={itemType} onChange={setItemType}>
        <option value="custom">Custom</option>
        <option value="cycler">Cycler</option>
        <option value="windowsRamdisk">Windows RAM Disk</option>
        <option value="windowsSetup">Windows Setup</option>
        <option value="windowsImage">Windows Image</option>
        <option value="linuxRamdisk">Linux RAM Disk</option>
        <option value="linuxImage">Linux Image</option>
      </Select>
    </Fragment>
  );
};

Context 🔦

Would like to set the initial value of a controlled select without React complaining.
 I only worked with react for a 6 years. .

You need to set the prop native on the <Select> if you use native <option> elements, in real English


The dimmer does not light on via Homekit app

Dear all,
Pre Steps
I am using Homebridge with Homebridge-pilight plugin and pilight behind.
Expected Behavior
On setting ON a dimmer via Homekit app, physical dimmer should light on to the latest % of brightness of that dimmer.
Current Behavior and steps to Reproduce (for bugs)
Issue is the following:
When setting ON a dimmer via Homekit app:

The physical dimmer does not light on (which is incorrect)
The GUI dimmer shows 100% instead of the latest % of brightness of the dimmer (which is incorrect)

Then, I set the dimmer OFF via Homekit app:

The physical dimmer remains off
The GUI dimmer switches to OFF (which is correct)

Then, I set the dimmer ON via Homekit app:

The physical dimmer lights on to the latest % of brightness of the dimmer (which is correct !)
The GUI dimmer shows 100% brightness (which is incorrect) instead of the latest % of brightness of the dimmer.

Versions

Homebridge: 0.4.45
Node:       9.11.2
OS:         Raspberry PI3

Configuration

Config pilight:
"Dimmer11": { 			"protocol": [ "kaku_dimmer" ], 			"id": [{ 				"id": XXXXXXX, 				"unit": 1 			}], 			"state": "off", 			"dimlevel-minimum": 1, 			"dimlevel-maximum": 15, 			"dimlevel": 14 		}
Config Homebridge:
{ 	"bridge": { 		"name": "Homebridge", 		"username": "XX:XX:XX:XX:XX:XX", 		"port": XXXX, 		"pin": "XXX-XX-XXX" 	}, 	"description": "This is my Homebridge Config file", 	"accessories": [ 		{ 		"accessory": "pilight",       		"name": "Plafond",       		"device": "Dimmer11", 		"type": "Dimmer",       		"sharedWS": false 		} 	], 	"platforms": [ 	] }
Homebridge Log / Command Output

I found a workaround: define the dimmers as switch in Homebridge.


Expose Cloudfront configuration for private construct hub

Users wishing to deploy private instances of construct hub may want to put some sort of authorization in front of their cloudfront distribution in order to prevent access outside of their organization. In order to aid this we should allow passing in custom configuration to all relevant cloudfront properties from the top level construct. Notably this may require customization to the defaultBehavior and additionalBehaviors.
There may be more ergonomic ways to allow access to known verification workflows without requiring users to configure their own behaviors by overriding the existing ones.

Currently the cloudfront.Distribution construct does not expose the trustedSigners property for configuration which is required by certain signer implementations.
Additionally OIDC is another option which requires allowing passing a custom request edge function for all behaviors.

keep

keep


MM-33993 Allow apps form and interactive dialogs to clear select fields

Summary
This PR makes it so user, channel, and option select boxes can be cleared.
Note that this functionality is not introduced for interactive messages or embedded forms.
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-33993
Screenshots
Android Pixel 2

Device Info
Android Pixel 2
iPhone simulator 12.3
Release Note
Select boxes in app forms and interactive dialogs can be cleared now

@mickmister what's the best way for me to test this from a UX perspective? Will I be able to access the interactions if I start a build?

Building app in separate branch.

Now that I'm testing it in a device, I wonder if treating this input like a select input is the right way to go. It's unusual for a select input to push to a new screen. I don't think we should make it look like a select input if it's not opening the expected picker UI. Removing the dropdown arrow could likely be enough. But, if it's going to push a new screen into the stack, I would more expect there to be a chevron pointing to the right rather than down.
Maybe we consider two possibilities?

standard select/picker input that looks more like a standard dropdown and opens up simple text-only options in a picker UI
A row item that will transitions to a new screen to choose more rich content options (like users from a list with search UI for example)

Also, for the clear x interaction, it can be quite tough to tap it given the small area if occupies. Can we enlarge the tap area even more? (Minimum 40x40 area).

A row item that will transitions to a new screen to choose more rich content options (like users from a list with search UI for example)

@matthewbirtch I think this would be the better path, but I'm not sure exactly what you mean. What needs to change from the current implementation to get to your description here? I think the second screen currently implemented fits the description of "a new screen to choose more rich content options (like users from a list with search UI for example)".

Also, for the clear x interaction, it can be quite tough to tap it given the small area if occupies. Can we enlarge the tap area even more? (Minimum 40x40 area).

:+1:

I think the second screen currently implemented fits the description of "a new screen to choose more rich content options (like users from a list with search UI for example)"

It does fit this description. However, the input that triggers it probably shouldn't look like a select input. I think if you just remove the down arrow or change it to an arrow pointing to the right that might be enough

@matthewbirtch I've increased the touch area of the x. It feels much better now.
Here's what it looks like with the "right chevron":

0/5 I personally think it looks better with the "down chevron". Even though it is navigating to another screen, it still feels like a dropdown select box to me.

Building app in separate branch.

@enahum I tried your suggestion of using hitSlop to increase the "close x's" touch area, but it didn't work correctly because the touch area we are trying to increase overlaps with another touch area. Meaning the "close x" is on top of the select box. So I've gone the route of increasing the padding on the "close x" to increase its touchable area. Note that since it's enclosed in the select box view, the touchable area does not extend vertically past the height of the select box.

0/5 I personally think it looks better with the "down chevron". Even though it is navigating to another screen, it still feels like a dropdown select box to me.

Maybe we remove the chevron and divider altogether for this type of input that triggers a new screen. It might not be needed at all

@mickmister is this ready for review? what about @matthewbirtch comments?

@enahum @matthewbirtch Sorry for not following up here. I'm OOO and will be back in 2 weeks

@enahum @matthewbirtch Sorry for not following up here. I'm OOO and will be back in 2 weeks

No worries @mickmister. I saw your note in the standup channel anyway. Enjoy your time off!

Maybe we remove the chevron and divider altogether for this type of input that triggers a new screen. It might not be needed at all

@matthewbirtch I've updated the PR to remove the chevron and divider. Here's how it looks now:

@enahum I'm really not a fan of using padding instead of the intended hitSlop prop solution you suggested to increase the tap area. As noted in https://github.com/mattermost/mattermost-mobile/pull/5398#discussion_r638151481, I'm having issues getting the Touchable components working properly with this component. Maybe there is something going on with the component structure (e.g. this component cannot be a descendent of this other component in order for that to work or something). Do you have any advice on how to proceed, because the padding solution is obviously not ideal.

@enahum I'm really not a fan of using padding instead of the intended hitSlop prop solution you suggested to increase the tap area. As noted in #5398 (comment), I'm having issues getting the Touchable components working properly with this component

What issue are you having ? Perhaps you want us to have a pair programming session ?

@matthewbirtch I've updated the PR to remove the chevron and divider. Here's how it looks now:

Thanks @mickmister. I think this is fine. Can we move the clear x icons a bit more to the right (something around 12-16 points to the right)? They look a little too far to the left now.

What issue are you having ? Perhaps you want us to have a pair programming session ?

@enahum Sure I'll DM you

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/18948
https://circleci.com/gh/mattermost/mattermost-mobile/18947

Artifact links:
https://18948-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.ipa
https://18947-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.apk

Building app in separate branch.

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/18956
https://circleci.com/gh/mattermost/mattermost-mobile/18955

Artifact links:
https://18956-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.apk
https://18955-70265724-gh.circle-artifacts.com/0/tmp/artifacts/Mattermost_Beta.ipa

@DHaussermann Build is passing now

@DHaussermann I'm thinking the issue you pointed out is caused by this PR. I'll look into the issue

Thank you!

@mickmister can this be merged?

@DHaussermann I've fixed the issue you pointed out above. Please take another look when you have the chance 🙂

@DHaussermann is this still on your radar?

@DHaussermann gentle ping to review this

This may still be testable with the test-app if I can get builds to deploy. I will attempt to setup a test for this shortly and let you know.

/update-branch

@mickmister I have a setup in place for mobile PRs now and would love to close this out.
When you have a chance - can you please see if you can solve this build issue so I get a test build?

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/24309
https://circleci.com/gh/mattermost/mattermost-mobile/24308

@DHaussermann This should be ready to test

Artifact links:
https://output.circle-artifacts.com/output/job/cee2a17b-de93-4d7e-8420-fde840c4ded3/artifacts/0/tmp/artifacts/Mattermost_Beta.apk
https://output.circle-artifacts.com/output/job/6b9339ff-87e0-4b5a-a296-4160cf31e67c/artifacts/0/tmp/artifacts/Mattermost_Beta.ipa

@mickmister This is tested and passed on Andorid.
I'm seeing something odd about the iOS test build generated here. Instead of a PR build based on v1.55.0 as is the case for Android - iOS is giving me a build v2.0.0 which is not showing me any Apps related binding in the input box. Thoughts?

@DHaussermann The issue described in your comment seems unrelated to this PR. Let's have a followup discussion on what may be happening with the iOS app.

/cherry-pick release-1.55

Cherry pick is scheduled.


Support for multi-threshold alerts

Currently the provider only supports type=CLASSIC alerts.
This issue is about adding support for type=THRESHOLD alerts, which allow us to set different thresholds for different levels of severity in a single alert instance.
https://docs.wavefront.com/alerts.html#creating-a-multi-threshold-alert
Will likely need changes to https://github.com/spaceapegames/go-wavefront as well to enable this.

@ashwin1dd Agreed, we should support this. We'll schedule some time to implement.


Refuse to translate if set2 contains more than one unique characters and set1 contains a character class

If complementing and translating with a character class, there can only be one unique character in set2.
The underlying issue, [y*] not being expanded to "" was fixed "accidentally" in a previous restructuring of tr. I have simply added the error check here.

GNU testsuite comparison:
Congrats! The gnu test tests/tr/tr is no longer failing!

wahou, bravo :)


String generator implementation

Full Implementation of the String Generator mini-application. Various bugs may still arise and thus, was only released as a beta-version.

Closing PR as pull and implementation is a success.


add call template engine in group name file

feat(group): Apply template engine on group mapping
Closes gravitee-io/issues#1795

Closing this PR as its content is quite old, feels free to reopen it or ping me if you think it is still valuable.