Public Updates (PU's)

This is more of a general question: What would be the preferred approach for handling public updates (PU's) for SharePoint as they come out?
Or should these DSC Resources just be focused on setup / config of SharePoint and such PU's should be handled through separate configuration?

Hey @ryanspletzer
So the question of patching has been thrown around by my team internally since the very first versions of xSharePoint. Unfortunately at the moment there isn't anything we can do with xSharePoint to handle installation of a specific update but it is absolutely on the radar. We had decided to hold off on making decisions on how we handle this until we have some public documentation on the new "zero-downtime patching" feature for SharePoint 2016 that has been discussed, so we can make sure whatever we implement for xSharePoint lines up with anything that needs.
Now that being said, I think there is value in getting a discussion going here around how this could work and what people would want to see in a patching resource. So the challenges that I know we are going to face are more to do with scheduling (when is the right time for an individual server to drop itself out while installing binaries, and when is the right time to bring the farm down with doing the PSConfig activities), as well as how we handle the fact that we would be making changes that can't be reversed so we need to make sure that we make it easy for customers to be in control of how and when a patch occurs so they can ensure they have an appropriate roll-back in place in case the patch goes south, and I'm not quite sure what that looks like.
So lets open the floor to some discussion here - how do people think we can handle patching with xSharePoint? Should we even be trying to do this? All thoughts on the topic welcome.
- B

That is a good question.
Short answer: I think we should have support for it.
Applying a PU is an common and required activity that is part of BAU just as much as creating an user profile property, and since DSC provides an abstraction layer we really need to have that.
The thing is that there has to be a way to recreated the environment with exactly the same process, which brings the need for version management, and every maintenance should be kept as an repeatable transaction. Whada heck do I mean?
Contoso Environment Change History:  (0) Farm is created with a custom configuration and rolled out to production. After that(1) DM solution requires managed properties created, as well as mappings. Shortly after that it (2) Jan 2016 PU is deployed to the farm. (3) PowerBI is implemented
Version History
1.0.0 - Farm built
1.0.1 - Created Managed Property and Mappings.
1.1.2 - Put is deployed to the farm
1.1.3 - PowerBI
If There is a need to rebuild the environment the solution is to replay the sequence. IF desired environment can have version 2, which incorporates all changes, but then I am going a step too far.

I'm actually gonna have to disagree with you here @camiloborges
One of the primary concepts of desired state configuration is that you only need to define the state you want the servers/services to be in, not how you get there. So in theory, I should be able to roll out straight to v1.1.3 of your example there without going through the other stages, because thats the version that is my "desired state". It's a bit of a shift in thinking about how we do scripting and deployment, but ultimately that's how it needs to be. It's why we need to write resources that will check for whatever the current state is and move it to the desired state.
So if we are going to look at how patching is incorporated in to xSharePoint, we need to look at how we can do that in such a way that we define "here is the patch level I want" and that is all we define, the DSC engine and our resoruces needs to figure out what it takes to get it there. So in my mind that's a matter of something along the lines of the farm build number and compare that to the patch we want to install (but this then means where a target CU needs a specific service pack or something before hand we need to make sure that a meaningful error comes out to let someone know that) and then install from there.
But as an overall stance, I don't want to put anything in that creates a need to version DSC scripts and replay them in a sequence to restore farm - it should be about the desired state only.

The philosophy can wait, so let me answer it with DSC as it is designed  ;)
Having the patch can and should be a separate resource, it has an reason even even from a brand new implementation.
I hardly ever streamlined patches, probably because I was never really an infra guy :), so I could have a need to install it anyway, just like we install SP and PreReqs. So, it could be that I need to have a
xSPInstallPrereqs InstallPrerequisites
{
InstallerPath     = "C:\SPInstall\Prerequisiteinstaller.exe"
OnlineMode        = $true
}
xSPInstall InstallBinaries
{
BinaryDir  = "C:\SPInstall"
ProductKey = $ProductKey
}
xSPProductUpdate PU
{
BinaryDir  = "C:\SPInstall"
PUVersion = "Jan2016"
}
So, back to philosophy I do agree that this is what DSC was designed to do. And Yes, I am kinda challenging a fundamental principle of it :)
Perhaps I am leveraging real world application of the word 'desired' :)  Desired State might be and often is a series of Desired States("All VMS in a VM Host", "join network", "install sharepoint")
Also, Progressive changes can lead to different results from a brand new complete configuration, so having an ability to replay the configuration is a nice thing to have. It doesn't even need to be seen as versions, but a transaction log of all that was applied to a machine.

OK so a few points to respond to there - first, I agree that slipstreaming is not the answer. For doing a brand new installation I think it is, but thats a one off and doesn't really address how we look at patching (because in the real world people don't build new farms at the higher patch level to do database attaching as an upgrade mechanism).
To your point about replaying a configuration - you name me a scenario when this matters in SharePoint that you deploying configurations in sequence (and something being a prerequisite doesn't count because DSC handles that) and I'll look at how that can be removed, because like I said, the whole point of DSC is just about "describe the state you want and the resources will just get you there". Replaying things in a sequence is an old school way of looking at this, Lets take for example something that needs a rollback strategy - in DSC you just go to the previous configuration that was applied (granted there are plenty of our own resources here that need more work in that space rather than just provisioning). But when you apply the previous configuration the system shouldn't care that the system was a configuration ahead, or if it came from a previous configuration - it just enacts what is in the configuration it is given. So we really should be working to that goal - if you can think of a specific scenario that can't be done like that though I'm all ears mate :)
Now - the argument about how DSC should work sort of side tracked things a little here, so back to the main issue at hand. Taking the approach of creating a xSPProductUpdate resource (I'm reserving the right to name that better before we do this!) there are a bunch of considerations that would need to go in to this:

When is a server allowed to install the binaries? What happens if multiple servers are installing binaries at the same time and then get caught needing to do a restart and you then lose all of your front ends to simultaneous (or near enough) reboots?
How do you manage the fact that there are pending database upgrades? Again this will cause an outage in 2013 while the updates are applied so we need to be mindful of how we trigger this.

Realistically once we look at those two issues, we are a long way towards figuring out how this could realistically work. So take something like this:
xSPProductUpdate Jan2016CU
{
    InstallerPath = "C:\SP\Updates\CU.exe"
    BinaryInstallWindow = "8:00pm to 11:00pm"
    DatabaseUpgradeWindow = "1:00am to 5:00am"
}

Ignoring the "how we parse the time span strings" bit, there are some things to think about here - if you are doing a push configuration that doesn't automatically refresh and reapply the configurations, do we run it right away? I think probably - in which case you make the window properties optional and if you find a server that has its build version beneath the current farm we run the set method. This could be an approach that works.
You then also need to account for the fact that you don't know when a server will be running a consistency check to see if it is in line with the configuration. if you're checking within 15 min intervals then a wide potential install window is going to be fine, but if you're running longer than that then you need to specify a big wide window to ensure that it gets caught and runs the installer.
Then there are issues around how multiple servers are handled - to the point I made earlier, how do we ensure that all servers aren't patched at once. I know that a lot of customers tend to do their patching based on servers that are within a single fault domain at a time (so that's usually a physical host or common rack of servers on-prem, or within specified fault domains in a hosting providers environment like Azure IaaS). This is different to how we look at DSC configurations where we define roles based on topology - you're a WFE or an App server or a search box or whatever - the physical host doesn't play a role here from a configuration perspective but I know customers who will do the binary installation based on fault domains because in theory I have one of each topology role in each fault domain, so if I start patching everything in fault domain 1 I know i have a second fault domain that has at least one of every role left to keep things running while the binaries are done.
The other thing we need to look at here as well is how we test that one is installed already - I don't want to get in to the habbit of maintaining a list of every build number of every update to determine that "January 2016" maps to 15.0.4787.1000. We need to look at whether or not the package has a build number associated with it so we can compare that to the farm output to determine if the patch level matches.
So taking all of that in to consideration, do we need to take an approach to this where we define the sequence of servers specifically? We already have to define specific server lists for search topology, and we are adding an optional server list for the distributed cache provisioning, so it's not a new concept in xSharePoint to do this, so something like this maybe?
xSPProductUpdate Jan2016CU
{
    InstallerPath = "C:\SP\Updates\CU.exe"
    InstallWindow = "8:00pm to 11:00pm"
    InstallOrder = @(
        "Server1",
        "Server2",
        "Server3"
    )
}

So in this model we look at running the binary installation one at a time, triggering the installs remotely one at a time from the one server. That addresses the sequencing issues and the fault domain point - but then we need an approach to how we determine when to reboot servers. When you are acting alone in DSC you can set the global "I need to reboot" flag, and if the LCM says that it will allow an automatic reboot it will just do it, otherwise it sits in a "pending reboot" state. When we are doing the installs remotely this creates other issues for us because we can't just reboot a server right away. We then also need to consider how the PSConfig stuff is handled on each server if we do it this way as well.
Overall I think my gut feeling on this is probably closer to the first one, where patching is done per server and we tell it when it's allowed to do the different bits. This means that the servers will report that they are out of compliance until a patch is installed (if I deploy the new configuration with the xSPProductUpdate resource at 2pm and the install window doesn't start until 8pm the resource will report false from the test method and then continue to do so until we unblock the setter).
That was a much longer response than I had planned - but hopefully you now see the considerations we need to decide upon here. Also all of this need to keep in mind that there will be more information coming on how the "zero downtime patching" in 2016 is to be achieved, and we need to make sure we can accommodate that once 2016 goes RTM. I'm not foreseeing that being some massively different process, but it is again something we need to make sure is accommodated.
- B

DSC enables us to quickly and efficiently deploy boxes and entire farms. This kind of 'Infrastructure as Code' concept enables us to treat server like cattle and now pets. We shouldn't be encouraging or enabling people to keep servers & farms for long durations. If a server or farm needs is faulting or needs patching, use DSC to build a new farm, migrate the DBs etc, TEST TEST TEST and do a DNS cutover.

Let's ignore the principle and the devops and dsc principles. I don't argue with purists :)
Going back to the focus of the conversation, which is how to push product patches to an environment.
Brian, your whole thinking is completely cool, but is it really achievable(or worthwhile) to have really zero downtime? The priority list is a nice idea, and I think you handled a similar situation with search  topology? Or was it the sample multiserver farm whereby you injected thread dependency? That might be good enough, you can perhaps add a delay between servers if you like, or order the sequence so you have a potential for a minimum downtime.
If we are to ignore zero downtime we can just have 2 checks for each box in the sequence.

binaries
database version
If binaries are not the same deploy patch and run psconfig.
does the database check adds any value here at all?

Sent via iPhone while out and about

On 15 Feb 2016, at 10:03 PM, Cam Adams<EMAIL_ADDRESS>wrote:
DSC enables us to quickly and efficiently deploy boxes and entire farms. This kind of 'Infrastructure as Code' concept enables us to treat server like cattle and now pets. We shouldn't be encouraging or enabling people to keep servers & farms for long durations. If a server or farm needs is faulting or needs patching, use DSC to build a new farm, migrate the DBs etc, TEST TEST TEST and do a DNS cutover.
—
Reply to this email directly or view it on GitHub.

I am a bit torn between two thoughts:

I really like the idea to add this functionality to xSharePoint. It would make the automation process so much better. Especially when installing a new farm and making sure it has the most recent patches installed. In this case the install order and unavailability of the farm is much less of an issue.
However I am not sure how much customers would like to use DSC to implement patches on a farm with is in production. Most of my customers patch their environments in a very controlled fashion, either manually or via script. They plan a maintenance window, during which they install the binaries (all servers at the same time) and then run the config wizard one server at a time. Even though SharePoint has the possibility to patch servers with minimal downtime, not many customers are using this option.

@camiloborges I agree that the priority list is a nice idea, but I do think we are stretching ourselves here, at least for a first cut of something. So perhaps we say "here is how the patch thing works, expect downtime in the window you specificy on the resource" or something like that?
@ykuijs If customers are doing it manually I think the question we need to ask why - what would it take for them to trust a script in a DSC resource to do it vs. doing it manually. If we understand why customers wouldn't want to automate it then it might help us know what the blockers to adoption would be.

@BrianFarnhill - That is it. Better simple and dependent on correct usage and guidance than perfect and never finished :) Go with the fact there will be downtime. I am yet to see a client that doesn't expect it anyway. :D
I have ideas around the question you asked @ykuijs  but I will give him time to reply :P

Since updating is a tricky process, customers would like to have full control over the process. Where you can change less impactful settings (like Farm Admins or Outgoing email settings) outside of a maintenance window, DSC is very useful. Patching is much more difficult. Doing this manually or via a custom script, you have control over the exact process and the sequence of patching.
Is it possible to specify within DSC that two servers cannot run at the same time? If so, we can create two resources that depend on each other: One for installing the binaries, which can run at once on all servers and one for the upgrade process, which has to run one server at a time.
I would prefer to use as much DSC built-in logic and not implement our own logic to control the upgrade process. The process Brian described before tends to go the other way, which sounds a little to me like wrapping a patching script into a DSC resource. And I would like to prevent that as much as possible.

Hey @BrianFarnhill , so, what about the PU resource have a slightly different behavior in 1 named server?
xSPVtcBFProductUpdate {
Version="Jan2015"
Binaries="Path"
PSConfigServer="namedserver.contoso.com"
}
then the process only executes PSConfig on the named server.
Can't get simpler, I think

Two questions:

How to determine the version on the server? Where/how can you check Version=Jan2015??
Why specify a PSConfigServer? PSConfig needs to run on each server in the farm. Just the first server on which PSConfig runs will upgrade all content databases, etc.

Just thought about the answer to my own question: Since SP2010 PSConfig automatically checks if a upgrade process is running on another server and if not, waits until that one is completed. Not sure if the corresponding Powershell cmdlets do the same btw.
On a side note: Does anyone know if the Set-TargetResource has a maximum time it can spend running?? The upgrade process can be a long running process and if DSC sets a maximum time, this might result in a timeout.

a.SharePoint.Core.dll on the server GAC? Get the latest version?
1.b. no where, it should really be tche build version. Could also be optionally grabbed from the package itself, but that would be a little harder :)
I am a retarded :) I simply forgot about this detail. Txs for calling out.

We can't have PSConfig running in more than 1 server before the first one is finished, can we?

If not, what can we do to ensure the first server can finish before the others?
Do we even have any problems with rolling a PU? @BrianFarnhill , if this was a problem that needed handling we'd have encountered it with multiserver farms

Exactly, SharePoint only registers the build numbers. But keep in mind that build numbers can be very deceptive:
https://blogs.technet.microsoft.com/stefan_gossner/2014/08/18/sharepoint-patching-demystified/
https://blogs.technet.microsoft.com/stefan_gossner/2014/10/23/common-question-why-does-the-version-number-on-the-servers-in-farm-page-not-change-after-installing-october-cu/
It totally depends on what exactly is included with the patch which files are updated and how to detect an update has been installed. As Stefan mentions, you cannot trust the "Servers in Farm" build number. The best way is to check the Patch status page

You can run PSConfig on multiple servers at the same time, however the actual upgrade process can only run on one server at a time. Therefore PSConfig places a lock on the configdb when it starts upgrading and beforehand checks if another server already has such a lock. If so, it will wait with the upgrade until the lock is released.

I've tagged this as in progress as @ykuijs is leading up the work in this space

No that PR391 is closed, this one can be closed.


[TEP-0145] Add CEL evaluation

Changes
4th PR of TEP-0145 tracked by https://github.com/tektoncd/pipeline/issues/7244.
This commit adds CEL evaluation. Users are able to use CEL in WhenExpression if the feature flag enable-cel-in-whenexpression is enabled.If the evluation is false, the PipelineTask will be skipped.
/kind feature
Signed-off-by: Yongxuan Zhang<EMAIL_ADDRESS>
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[x] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
Support CEL expression in WhenExpression to guard the execution of Tasks

/test all

@tektoncd/core-maintainers requesting reviews on this PR 🙏🏾
This is the last PR implementing CEL in When Expressions -- https://github.com/tektoncd/pipeline/issues/7244

please add an example 🙏🏾
you can update this example: https://github.com/tektoncd/pipeline/blob/main/examples/v1/pipelineruns/pipelinerun-with-when-expressions.yaml

I do have an example added: examples/v1/pipelineruns/alpha/pipelinerun-with-cel-when-expressions.yaml
That's one reason I didn't add e2e test since the example is running as part of the e2e test.

ah it's all good then, thanks!

/assign

/retest
error resolving image references: GET https://distroless.dev/v2/: unexpected status code 503 Service Unavailable
https://prow.tekton.dev/view/gs/tekton-prow/pr-logs/pull/tektoncd_pipeline/7255/pull-tekton-pipeline-alpha-integration-tests/1717273228327522304


Very unfriendly <make.exe": no_c_compiler: Command not found> message when no gcc is installed

I followed these instructions https://github.com/grpc/grpc/blob/master/BUILDING.md on clean "Ubuntu 18.04.3 LTS" and whenever I ran "make" to actually compile grpc I would face (that's the valuable part of the message):
make.exe": no_c_compiler: Command not found

(and this is the full message):
[C]       Compiling third_party/address_sorting/address_sorting.c
make: no_c_compiler: Command not found
Makefile:2899: recipe for target '/home/admin-/grpc/objs/opt/third_party/address
        _sorting/address_sorting.o' failed
make: *** [/home/admin-/grpc/objs/opt/third_party/address_sorting/address_sortin
        g.o] Error 127

Mmmkay, what do I do with that? Some recipe failed, some command not found, rather hard for someone not very experienced with make.
Turns out I had no C compiler installed and I needed to install one, for example, gcc, using
apt get install gcc

It would be nice if there was better diagnostics for this situation. Not some "command not found" thing but a more explicit text like "no C compiler found on the machine, maybe install one, maybe even gcc"
It looks like the following chain at the beginning of Makefile:
ifeq ($(HAS_CC),true)
  DEFAULT_CC = cc
  DEFAULT_CXX = c++
else
ifeq ($(HAS_GCC),true)
  DEFAULT_CC = gcc
  DEFAULT_CXX = g++
else
ifeq ($(HAS_CLANG),true)
  DEFAULT_CC = clang
  DEFAULT_CXX = clang++
else
  DEFAULT_CC = no_c_compiler
  DEFAULT_CXX = no_c++_compiler
endif
endif

endif
is in charge of compiler detection. The "no compiler" part can be changed to this:
# (clang was detected)
else
 #add this
 $(error No C compiler found. Please ensure cc, gcc or clang is installed.)
 #and remove the "no_compiler" variables
endif

and this emits the following error message:
Makefile:61: *** No C compiler found. Please ensure cc, gcc or clang is installed. Stop.

Very clear and easy to read.

@nicolasnoble I included the possible way to resolve the issue - the latest edit. Could you please take a look?

Our plan for the future is to only support cmake and bazel. Makefile will be only used for building binary artifacts for languages that require it. So I'm not sure if addressing this makes sense in the long run. You should switch your builds to cmake.

Makefile support is now deprecated. Please use cmake.


Add a rule to flag places where emptyList (and similar)  can be used

Kotlin provides the functions emptyArray, emptyList, emptyMap, emptySequence, and emptySet to improve the readability of instantiating an empty "collection".
Expected Behavior of the rule
The below can also be applied to the other "empty" variations.
Noncompliant Code
val strs = listOf<String>()

Compliant Code
val strs = emptyList<String>()

Okay. @veyndan may I ask you to take a stab at this?

Sure thing! Feel free to assign me to this ticket 😄

Done!


Stats file only includes index.html

Do you want to request a feature or report a bug?
bug
What is the current behavior?
stats file only includes index.html
If the current behavior is a bug, please provide the steps to reproduce.
preact build --json
What is the expected behavior?
stats should include the whole bundle
Please mention other relevant information.

node version
8.3.0
npm version
5.3.0
Operating system
Windows
preact cli
1.4.1

I experienced the same behavior as well. I don't have an answer, but if you are in a bind and need the stats, editing the following lines in 'node_modules/preact-cli/lib/lib/webpack/run-webpack.js'  'writeJsonStats' method worked for me:
..
//jsonStats = jsonStats.children && jsonStats.children[0] || jsonStats;
//jsonStats.modules.forEach(stripBabelLoaderFromModuleNames);
//jsonStats.chunks.forEach(c => c.modules.forEach(stripBabelLoaderFromModuleNames));

...
Hope that helps

yup that works, thx


Add more useful apply examples to docs/intro/concepts/inputs-outputs/#apply

The examples that are there right now are basic usage of apply - it would be good to do something where we can do something like build an IAM Policy in our apply to show a more complex example
This relates back to https://github.com/pulumi/pulumi/issues/5236 and the incorrect use of the apply inside the get_policy_document invoke

Found an example for this here: https://www.pulumi.com/docs/concepts/inputs-outputs/apply/#outputs-and-json
I believe this issue can be closed.


Wfx exception handle

Add exception handlers for wfi and wfe in armv9a/src/exception/trap.rs
Disable TWI in HCR_EL2 (trap to EL2) and add warning message to the REC_ENTER requests in case that the normal world wants to set it enabled.

current design decision: I don't see a good reason we support per realm or per realm execution configuration with TWI in HCR_EL2. It is more feasible setting enble or disable for all realms consistently.
As current linux-cca in normal world does not handle wfx exceptions, just disable it. We currently have exception handler for wfx.  When we need such dynamic configuration in the future, let's add the hcr_el2 context management then.

How far can we get to in realm linux booting? Is it going to face another stuck point than specified in #106 ??

How far can we get to in realm linux booting? Is it going to face another stuck point than specified in #106 ??

Good question. There is no error due to the wfi instruction, but the linux booting progress stays there because we haven't implemented timer support. next thing to do is enable timer support. :)
Realm kernel will stay idle until it can schedule. For scheduling it require timer interrupt.
ffff80000892af20 <cpu_do_idle>:
ffff80000892af20:   d503233f    paciasp
ffff80000892af24:   d5033f9f    dsb sy
ffff80000892af28:   d503207f    wfi   // realm is still stuck here due to the missing timer support
ffff80000892af2c:   d50323bf    autiasp
ffff80000892af30:   d65f03c0    ret

wfi instruction

I got it

I didn't get the relationship between the first commit (adding handler) and the second commit (disabling TWI).
If this PR intends to add the handler for WFI/WFE, why should the relevant bit disabled which would make the handler out of reach?
If the intention is disabling the trap to EL2 regarding WFI/WFE, should we still need the handler?

 If this PR intends to add the handler for WFI/WFE, why should the relevant bit disabled which would make the handler out of reach?
If the intention is disabling the trap to EL2 regarding WFI/WFE, should we still need the handler?

Currently disabling TWI in HCR_EL2 is enough.
linux-cca doesn't handle WFx exception for now, but I don't think that's will be a ultimate solution. Usually when core waits for event or interrupt (using wfi, wfe), VM exits and let KVM schdule for another process. As the realm runs in the context of vcpu thread in kvmtool, it would be better to yield to its cpu time if the realm waits for such events (, unless such exit induces a security risk).
I think  linux-cca will eventually implement wfi handler. So, I left the first commit so as to just re-enable TWI.

Currently disabling TWI in HCR_EL2 is enough. linux-cca doesn't handle the WFx exception at the moment, but I don't think that will be the ultimate solution. Usually when core waits for event or interrupt (using wfi, wfe), VM exits and let KVM schdule for another process. As the realm runs in the context of vcpu thread in kvmtool, it would be better to yield to its cpu time if the realm waits for such events (, unless such exit induces a security risk). I think linux-cca will eventually implement wfi handler. So, I left the first commit so as to just re-enable TWI.

Thank you for the detailed answer! I understood that the handler is for the future usage.


code sys.exit() causes interactive terminal to freeze with kernel crash

Type: Bug
When sys.exit() code is executed by clicking on close [X] button while the python program is running in main file, the jupyter interactive-1 window freezes followed by kernel crash.
However, when the same program file is run with default output set to be from dedicated terminal, the program terminates without any issues such vs code freeze or kernel crash.

When sys.exit() code is executed by clicking on close [X] button while the python program

I don't understand how sys.exit is excuted when clicking an x button, what x button?
Please can you share a screen recording of the issue, you can use https://gifcap.dev/ to record the screen.

Please can you try running the exact same code in Jupyter Lab or Jupyter Notebook and see if the issue repros in there.
If it does, please can you share the terminal output.

@DonJayamanne Thank you for reply.
I have tried running the above code in my Jupyter Notebook but the result is exactly as shown in my previous screen-recoding attached above.
Now I have also attached a new screen-recoding for your perusal.
Please do let me know if require any further details.

I have tried running the above code in my Jupyter Notebook but the result is exactly as shown in my previous screen-recoding attached above.

I'm referring to Jupyter Lab application thats launched outside VS Code.
This is what I'm referring to https://jupyter.org/

@DonJayamanne Unfortunately, I do not use stand alone Jupyter Notebook application as I work on various programming languages and VS code suits me fine for this purpose.
I have a suggestion. As Google Colab uses Jupyter Notebook application, I can run this code in Google Colab and send you the result. Will this serve the purpose? Kindly let me know.

Would it be possible to run pip install jupyterlab in your Python environment and then test this.
I do not believe this is an issue with VS Code, hence the suggestion to try Jupyter Lab or Jupyter Notebook.
Google Colab is slightly different, as there are some subtle differences.

@DonJayamanne As I already had Jupyter Notebook installed via pip, I could run my program from the Jupyter Notebook. But still no changes in the outcome. Jupyter Notebook is still throwing the same error and causing the kernel to crash.
If you remember, I had in my very first ticket mentioned that I am facing this issue only when I try to get the output from the Jupyter Interactive Terminal. I am always able to get the desired output from my VS code terminal without any issues.
Fyi, I have attached a copy of the screen recording of the time when I tried to run my program from the Jupyter Notebook which caused my Kernel to crash. Unfortunately, your screen recorder is unable to capture the game viewer pop-up page.

Fyi, I have attached a copy of the screen recording of the time when I tried to run my program from the Jupyter Notebook which caused my Kernel to crash.

Thanks for testing this in Jupyter notebooks.
This confirms my initial hypothesis, given that it crashes outside vscode is not caused by vscode nor the jupyter extension.
I would suggest trying stack overflow or the like to try and get to the bottom of this issue.


where is the build folder?

where is the build folder?

see README.md。

./bin - all executable & libs binaries will be installed here
./build - build scripts for different platforms (mingw.bat, unix.sh, vs.bat) - run build from here!
./temp - temporary build folder with generated make file, projects files, solutions, build obj files, etc.


quickstart simple mainclass - Takes a long time to run

When you deploy it, and tail the logs, then it hang here found about 1min until jolokia initailizes.
I wonder if it need that random trick or something? Maybe @rhuss has an idea?
davsclaus:~/workspace/fabric8-installer/vagrant/openshift (master)/$ oc logs -f quickstart-java-simple-mainclass-tr7qg
Executing /deployments/bin/run ...
Launching application in folder: /deployments
Running  java  -javaagent:/opt/jolokia/jolokia.jar=config=/opt/jolokia/jolokia.properties,useSslClientAuthentication=true,extraClientCheck=true,protocol=https,caCert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt,clientPrincipal=cn=system:master-proxy -classpath .:/deployments/lib/quickstart-java-simple-mainclass-2.2.57-SNAPSHOT.jar:/deployments/lib/commons-lang3-3.4.jar io.fabric8.quickstarts.java.simple.Main

And when about 1 min or so, it runs
davsclaus:~/workspace/fabric8-installer/vagrant/openshift (master)/$ oc logs -f quickstart-java-simple-mainclass-tr7qg
Executing /deployments/bin/run ...
Launching application in folder: /deployments
Running  java  -javaagent:/opt/jolokia/jolokia.jar=config=/opt/jolokia/jolokia.properties,useSslClientAuthentication=true,extraClientCheck=true,protocol=https,caCert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt,clientPrincipal=cn=system:master-proxy -classpath .:/deployments/lib/quickstart-java-simple-mainclass-2.2.57-SNAPSHOT.jar:/deployments/lib/commons-lang3-3.4.jar io.fabric8.quickstarts.java.simple.Main
I> No access restrictor found, access to all MBean is allowed
Jolokia: Agent started with URL https://<IP_ADDRESS>:8778/jolokia/
Hello Fabric8! Here's your random string: Xz3GT
Hello Fabric8! Here's your random string: LjpkX
Hello Fabric8! Here's your random string: c37zw
Hello Fabric8! Here's your random string: Bu7xX
Hello Fabric8! Here's your random string: ptk3g
Hello Fabric8! Here's your random string: XJb50
Hello Fabric8! Here's your random string: LiBiD
Hello Fabric8! Here's your random string: wSokC

Could be because jolokia is configured to use SSL now and it creates a self-signed TLS certificate during startup. If there is not enough entropy in the system, it block on /dev/random (same issue as with Tomcat).
A solution is to use -Djava.security.egd=file:/dev/./urandom. Can you try with adding a <JAVA_OPTIONS>-Djava.security.egd=file:/dev/./urandom"</JAVA_OPTIONS>  to the <env> section in the d-m-p configuration ?

Trying now
davsclaus:~/workspace/fabric8-installer/vagrant/openshift (master)/$ oc logs -f quickstart-java-simple-mainclass-i9h5c
Executing /deployments/bin/run ...
Launching application in folder: /deployments
Running  java  -Djava.security.egd=file:/dev/./urandom" -javaagent:/opt/jolokia/jolokia.jar=config=/opt/jolokia/jolokia.properties,useSslClientAuthentication=true,extraClientCheck=true,protocol=https,caCert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt,clientPrincipal=cn=system:master-proxy -classpath .:/deployments/lib/quickstart-java-simple-mainclass-2.2.57-SNAPSHOT.jar:/deployments/lib/commons-lang3-3.4.jar io.fabric8.quickstarts.java.simple.Main

But still takes 30-60 seconds before printing the hello fabric8

Strange, for me it starts immediately (even without the providing the urandom thing).

Its slow today again with a new vagrant as I destroyed the old one. It takes about 30 sec or so.
Though we should check some of others as it would cause a scale up use-case or redeploy etc to be slow if the java app takes 30 sec to boot.

The cdi quickstarts started quickly and the scala up/down demo of the http/jetty works well.

Removing this makes it run fast
  <fabric8.env.AB_JOLOKIA_AUTH_OPENSHIFT>true</fabric8.env.AB_JOLOKIA_AUTH_OPENSHIFT>


nf33: Add firmware and documentation.

This is a combination of the dsm app from nf28 and the PIR app from sparrow-reference-firmware. The dsm code is identical to nf28's, but I made 2 changes to the PIR app:

I had to tweak the threshold value a bit. The default value was too low, and I was getting lots of false positives.
I changed the PIR_SUPPRESSION_MINS value to 5 (i.e. more frequent motion detection notes).

So, the only real thing to review here is the README.md.

I wasn't checking the pin in the dsm ISR. Latest commit fixes that.


Code Scanning Configs for datadog-agent

What does this PR do?
Adds Configurations to scan Datadog/datadog-agent and push Code Scanning results to Github. The PR also contains fixes for uncontrolled data in path expression.
Motivation
What inspired you to submit this pull request?
Datadog is expanding the CodeQL adoption on its open source repositories.
Additional Notes
Anything else we should know when reviewing?
For more info on how Github Code Scanning works: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning
Describe how to test your changes
Enable Code Scanning on Datadog/datadog-agent from the repository's settings page. Once the PR gets merged, the CodeQL github action runs on main branch and you can see the security findings getting pushed under the repository's Security -> Code Scanning Alerts tab.
Checklist

[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] The need-change/operator and need-change/helm labels has been applied if applicable.
[ ] The appropriate team/.. label has been applied, if known.
[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] The config template has been updated if applicable.

Note: Adding GitHub labels is only possible for contributors with write access.

Using a new CI system means a lot of new issues, if you can use Gitlab, Appveyor or CircleCI it would be much easier for us to maintain. I am reviewing here assuming you can't but please explore that option.

@mx-psi The main reason why we wanted to use Github actions is because, its available free for the public repositories. So we are aiming to make use of the Github actions in setting up the Code Scanning on all Datadog public repos.
cc: @stephengroat


Support for Vue 2 backwards compatability

What problem does this feature solve?
Pinia has managed to support Vue 2 with a peer dependency on @vue/composition-api and a slightly different installation method (have to register a plugin). VueUse works with Vue 2 + @vue/composition-api out of the box. I believe both of these leverage the power of vue-demi. Is this available / possible for Vue Router? I do not see it documented.
As a developer, I have a lot to upgrade to take my project from Vue 2 to Vue 3. If I can incrementally perform upgrades it will be a huge help. My current situation is that I need useRoute (Vue Router 4) to get access to a reactive route object from within Pinia, but cannot upgrade to Vue 3 until Vuetify 3.1 comes out. I am hoping it is not the case that I have to wait for Vuetify 3.1, then upgrade Vue, Vuetify, the Router, and Vuex in addition to all the 3rd party libraries at once (although this might be how things have to go).
What does the proposed API look like?
https://pinia.vuejs.org/getting-started.html#installation
If you are using Vue 2, you also need to install a plugin and inject the created router at the root of the app:
import { createRouter, VueRouterPlugin } from 'vue-router'

Vue.use(VueRouterPlugin)  // is this necessary?
const router = createRouter({
  ...,
})

new Vue({
  el: '#app',
  // other options...
  // ...
  router,
})

Unrelated note
The issue creation wizard for this project adds this at the end of the GitHub URL, which causes a GitHub 500 error.
<!-- generated by vue-issues. DO NOT REMOVE -->&labels=feature request

If your project relies on component libraries like Vuetify, Quasar or ElementUI, it is best to wait for their Vue 3 compatible versions.

https://www.npmjs.com/package/@vue/compat#known-limitations
Thanks anyway 😓


Support SDC41 QTStemma board via detecting it via i2c address.

This adds functionality to detect a single QT Stemma board. Right now the only supported module is the SCD41, but I think that this template should work for people to add boards as they need.
If no qtstemma boards are detected then nothing changes.

Thank you for getting involved!
We don't plan to add support for individual breakouts into the main firmware as it would make keeping the size of the firmware under control quite difficult (MicroPython is pretty constrained both in filesystem space and performance when loading lots of extra code).
That said we can support this usecase with a more general approach allowing the user to customise their main.py and supply some extra readings to be included with the others.
See https://github.com/pimoroni/enviro/issues/41


Add lambda layers support

Description
Lambda layers support
Added layers keyword in zappa_settings.json, put a list of ARN's there and zappa will add them to your function.
GitHub Issues
https://github.com/Miserlou/Zappa/issues/1716

@jgissend10 @piotrdrazikowski I made the change to zappa update and added some tests in #1842 . I'm planning on using layer support in our dev environment soon, so if there are other issues I'll report back.

Keen to see this in, a good first iteration of layer support within the framework, needs another rebase though

When is this planned to be released? Any particular things that are awaiting testing?


Add support for multiple payers

This PR adds support for multiple payers of a certain expense. The database changes are minimal and resemble the structure of the paidFor expense field. There's quite some changes to the interface, mostly to the expense form, which are showcased in the video below.
https://github.com/spliit-app/spliit/assets/15089458/36a27f6d-e02a-41c7-a89e-3d60b1585722
The PR is in a finished state, however it is still marked as draft as I don't know how to provide a correct migration strategy for existing databases (the prisma generated one just seems to drop the paidById column entirely). Some help there would be appreciated. The necessary migration is not too complicated: for each existing expense a new ExpensePaidBy row must be created with participantId equal to the old paidById, expenseId equal to the corresponding expense id and amount equal to the expense's (total) amount.
Closes #14.
Additionally fixes some small bugs regarding amount and balance formatting (this might resolve issues #87 and #140). Also resolves #156 by increasing the upper bound to 10 billion.

You mean something like this? (This is in mobile viewer)

Initially, I didn't opt to introduce an extra icon as I thought it would become too crowded on mobile, but maybe it's just doable.

I would put the remove payer button either on the far right or the far left instead of in the middle, personally

Align to the right, together with the "add payer"

This right alignment is already part of the last commit, I just haven't updated the previous screenshots.
Anybody knows how to implement the correct database migration? Is it the src/scripts/migrate.ts script that needs to be modified or appended to?

This looks like a great addition! Thank you!
This should do for the database migration: npx prisma migrate dev --name multiple_payers
See here for the docs on prisma: https://www.prisma.io/docs/orm/prisma-migrate/getting-started

I see. You need to manually adjust the migration file. This should do (please test!):
-- CreateTable
CREATE TABLE "ExpensePaidBy" (
    "expenseId" TEXT NOT NULL,
    "participantId" TEXT NOT NULL,
    "amount" INTEGER NOT NULL,

    CONSTRAINT "ExpensePaidBy_pkey" PRIMARY KEY ("expenseId","participantId")
);

-- AddForeignKey
ALTER TABLE "ExpensePaidBy" ADD CONSTRAINT "ExpensePaidBy_expenseId_fkey" FOREIGN KEY ("expenseId") REFERENCES "Expense"("id") ON DELETE CASCADE ON UPDATE CASCADE;

-- AddForeignKey
ALTER TABLE "ExpensePaidBy" ADD CONSTRAINT "ExpensePaidBy_participantId_fkey" FOREIGN KEY ("participantId") REFERENCES "Participant"("id") ON DELETE CASCADE ON UPDATE CASCADE;

/*
step 2: copy values of old column "paidById" to new table
*/

INSERT INTO "ExpensePaidBy"
	SELECT "id" AS "expenseId", "paidById" AS "participantId", amount
	FROM "Expense";

/*
step 3: drop old column "paidById"
*/

-- DropForeignKey
ALTER TABLE "Expense" DROP CONSTRAINT "Expense_paidById_fkey";

-- AlterTable
ALTER TABLE "Expense" DROP COLUMN "paidById";

I see. You need to manually adjust the migration file. This should do (please test!):

Thanks @shynst, that worked like a charm! :)
The merge conflicts with the main branch are resolved and the database migration is correctly configured now.
This is ready for review.

What is this PR waiting for?

@scastiel could you let me know whether this is a feature you want in spliit or not? Because otherwise it's quite the hassle to continue resolving all conflicts introduced by later PRs.

This is one of the key feature that folks are missing (coming from Splitwise).  Is there a decision from the the core contributors that can be shared to the community?

Hi @dcbr
If you don't mind, then can you please reslove conflicts for this time ??🙏


Remove dependency on clang-sys

We're using rocksdb, which uses bindgen, which uses clang-sys.

How should this work?


⚠ St. Lawrence Global Observatory CKAN has degraded performance

In db6dbb1, St. Lawrence Global Observatory CKAN (https://catalogue.ogsl.ca/en/) experienced degraded performance:

HTTP code: 200
Response time: 11127 ms

Resolved: St. Lawrence Global Observatory CKAN performance has improved in 1c4533f after 5 minutes.


JSON parseable verification

It seems that swagger-tools validate will not check if the JSON is valid before checking if it matches the expected schema (or that there is an error when handling this check).
As a result, errors like trailing commas are not seen, but trigger an error later on when trying to parse the JSON.
Would it be possible to add this check as a pre-requisite before any other verification ?

swagger-tools doesn't parse JSON, except when retrieving remote references, and all of its APIs take already created/parsed objects.  As for when JSON parsing does occur, I'm not sure how we could attempt to validate JSON that didn't pass parsing.  Do you have an example that can reproduce this?

Here is a malformed JSON that will pass swagger-tools validation even though it can't be parsed:
{
  "swagger": "2.0",
  "info": {
    "title": "User API",
    "description": "my API",
    "version": "1.0.0"
  },
  "host": "api.local.dev",
  "basePath": "/",
  "produces": [
    "application/json"
  ],
  "paths": {
    "/user": {
      "get": {
        "description": "get user",
        "parameters": [
          {
            "name": "partnerName",
            "in": "query",
            "type": "string",
            "required": true,
            "description": "some desc"
          },
        ],
        "responses": {
          "200": {
            "description": "result",
            "schema": {
              "type": "string"
            }
          }
        }
      }
    }
  }
}

Note the extra comma after the parameter

So, here is the problem.  We're using a YAML parser to parse the inputs, whether JSON or YAML.  The reason for this is the YAML parser we use is capable of parsing both JSON and YAML.  It seems that the JSON above is invalid if using JSON.parse but if I use js-yaml (YAML.safeLoad(fs.readFileSync('swagger.yaml', 'utf8')), it does not fail.
I'm not sure if this is a bug or a feature but I'll see if js-yaml has a way to fail or report on such things.

It looks like I've brought this up in the past: https://github.com/nodeca/js-yaml/issues/262  It seems that the only way to solve this is to have a fall-through mode where instead of using the YAML parser for everything, I try the JSON parser first and then fall through to the YAML parser.
Or...we leave it as-is.

According to js-yaml documentation, safeLoad as an option for that : json (default: false) - compatibility with JSON.parse behaviour.

I tried using it, false is the default and when I change it to true, YAML.safeLoad still parses the JSON without issue.  As documented, that option is really for duplicate key handling.
As for this JSON not working, how do you mean?  Can you give me a real error you're encountering?  json-refs is used to load the Swagger documents so once it's loaded, and we've verified we're loading it, the fact that the JSON was not valid shouldn't matter anymore.  (This isn't to say we shouldn't fix this to work around js-yaml but I'm trying to make sure I understand the scope.)

Thanks for checking out the json option.
The error case we have is when trying to load an invalid json file in a swagger instance.
We get an error saying "500 : { "error": { "message": "SyntaxError" } } http://api.temp-swagger-test.domain.com/apis.json" when the json file is not parseable.
Perhaps that has something to do with the fact that the json file is on another domain...

Swagger instance?  You mean swagger-ui?  Yeah, it doesn't use a YAML parser for all of its parsing. but in swagger-tools, we're serving that file so the generated JSON should be valid.  Are you serving the api.json via swagger-tools or via some static file server?
That alone is reason enough to fix this I guess.  The reason I took this route is because there is no 100% guaranteed way to check if an input is JSON or YAML and extension matching is not a guarantee.  I will update json-refs to fix this and will link this issue in the report.

Right, I meant swagger-ui. We are serving the apis.json file via a static file server.
Thanks for your feedback.
Any idea if this can be fixed rapidly or if it'll take some time before someone can get to it ?

I'll get it out ASAP but if it's a show stopper, just fix your JSON.  ;)  That requires no changes elsewhere.  Now that I've got the bug in json-refs, it won't slip through the cracks.


Small bug in WeeklyTrigger

Just noticed this while I was skimming the code, but I'm unfortunately on a deadline and don't have time to figure out how to submit a patch, so apologies for being lazy --
Seems like the line:
            this.WeeksInterval = 1;in the constructor for WeeklyTrigger should read:            this.WeeksInterval = weeksInterval;

Originally posted: 2010-08-22T18:09:23

Thanks for finding this bug. It has been fixed and posted in source drop 56462.
Originally posted: 2010-08-25T16:51:42


add thumbStyle, thumbSize, trackHeight props to Readme.md

Summary:
I added thumbStyle, thumbSize, trackHeight props to the Props Table in Readme.md
Test Plan:
Just check Props Table in the readme.md file.
you should find thumbStyle, thumbSize, trackHeightrows.

Closed because those props are only available for web. check https://github.com/callstack/react-native-slider/issues/92#issuecomment-1380176200


InstructBlip-vicuna13B : llm generate error  with position_id's error shape

Code：
ossfs/workspace/LAVIS/lavis/models/blip2_models/modeling_llama.py:529 in forward
position_ids = position_ids.view(-1, seq_length).long()
Log：
RuntimeError: shape '[-1, 40]' is invalid for input of size 205
When i print the position_ids' shape, it output twice log. as:
position_ids  torch.Size([5, 40])
position_ids  torch.Size([5, 41])
can you tell me why , and how to solve this problem. my friends.
thanks!

Now ,i found the prepare_inputs_for_generation function in  modeling_llama.py
inputs_embeds keeps old value and shape, not update.

same question :(

@dingtine I downloaded the vicuna weights again and then fix the problem!!
The difference is that I use git clone to download the weights first time, and then got the same error as yours.
So I tried to download the weights again through the download link, and the problem got solved!

@dingtine I downloaded the vicuna weights again and then fix the problem!! The difference is that I use git clone to download the weights first time, and then got the same error as yours. So I tried to download the weights again through the download link, and the problem got solved!

hi, how to solve this problem, I met same problem, I got vicuna follow this step python -m fastchat.model.apply_delta
--base 你的路径/llama-13b-hf
--target 你的路径/vicuna-13b \  # 合并后为 37G
--delta 你的路径/vicuna-13b-delta-v0

I encounter the same error. One workaround is to enable use_cache=True for LlamaForCausalLM. Concretely, you can edit this line from:
self.llm_model = LlamaForCausalLM.from_pretrained(llm_model, torch_dtype=torch.float16)

to :
self.llm_model = LlamaForCausalLM.from_pretrained(llm_model, torch_dtype=torch.float16, use_cache=True)

This issue may be related to the version of the huggingface. When using different versions, there will be different input processing methods when generating. I have experienced situations where I failed to use version 4.26 but succeeded in using version 4.28 when using blip2.

I encountered the same error. One workaround is to enable use_cache=True for LlamaForCausalLM. Concretely, you can edit this line from:
self.llm_model = LlamaForCausalLM.from_pretrained(llm_model, torch_dtype=torch.float16)

to :
self.llm_model = LlamaForCausalLM.from_pretrained(llm_model, torch_dtype=torch.float16, use_cache=True)

thx, I met the same problem and fixed it by adding use_cache.


Fix bitwise operation in pcapng.py

Got follow error
Fix with this commit
Please, pull if looks great
george@gregentov-desktop:~/svn/vtest$ ./venv/bin/parse_pcap -v /home/george/Downloads/b75c6134-3d11-449b-8ef5-b53d39bdfa62-attachment.pcap
Traceback (most recent call last):
File "./venv/bin/parse_pcap", line 212, in
main()
File "./venv/bin/parse_pcap", line 200, in main
pcap_file(conn_dict, infile)
File "./venv/bin/parse_pcap", line 125, in pcap_file
for tcp_pac in packet_parser.read_package_r(pcap_file):
File "/home/george/svn/vtest/venv/local/lib/python2.7/site-packages/pcapparser/packet_parser.py", line 203, in read_package_r
for pack in read_tcp_packet(pcap_file):
File "/home/george/svn/vtest/venv/local/lib/python2.7/site-packages/pcapparser/packet_parser.py", line 184, in read_tcp_packet
for link_type, micro_second, link_packet in read_packet():
File "/home/george/svn/vtest/venv/local/lib/python2.7/site-packages/pcapparser/pcapng.py", line 168, in read_packet
data = self.parse_block()
File "/home/george/svn/vtest/venv/local/lib/python2.7/site-packages/pcapparser/pcapng.py", line 148, in parse_block
self.parse_interface_description_block(block_len)
File "/home/george/svn/vtest/venv/local/lib/python2.7/site-packages/pcapparser/pcapng.py", line 86, in parse_interface_description_block
sig = (if_tsresol & 0x80)
TypeError: unsupported operand type(s) for &: 'str' and 'int'

Please, release new version with this fix on pypi.
Or write a release date.

New version 0.4.4 released


can't connect from the outside cluster without flushing iptables

Hello currently I'm on CentOS and k3s v0.3.0, however I can't connect from the outside without running iptables -F
These are the chain it actually sets:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-EXTERNAL-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes externally-visible service portals */
KUBE-FIREWALL  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
ACCEPT     all  --  schmitch01/16        anywhere
ACCEPT     all  --  anywhere             schmitch01/16

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
KUBE-FIREWALL  all  --  anywhere             anywhere

Chain KUBE-EXTERNAL-SERVICES (1 references)
target     prot opt source               destination

Chain KUBE-FIREWALL (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000

Chain KUBE-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* kubernetes forwarding rules */ mark match 0x4000/0x4000
ACCEPT     all  --  schmitch01/16        anywhere             /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             schmitch01/16        /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED

Chain KUBE-SERVICES (1 references)
target     prot opt source               destination

I mean I can actually set a rule for 6443, but that does not help:
iptables -A INPUT -p tcp --dport 6443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 6443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

However when I run iptables -F I can access the cluster and the rules are way smaller, is there something I'm missing?

@schmitch The last rule in your INPUT chain is REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited which will just reject all inbound traffic.  So k3s needs port 6443 open if you want to allow inbound so you need to configure your firewalling system to allow it.  I'm guessing you are using firewalld maybe?   Something in your system is adding ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh which allows SSH, so you need to tell it to also allow 6443.
I think it's really outside the scope of k3s to automatically configure the host level firewall.

actually I did not create any firewalls on this host, I removed firewalld and restarted, now I had that:
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

actually kubeadm also does not add REJECT all -- anywhere anywhere reject-with icmp-host-prohibited.
but reinstalling 0.3 its now gone, too.


Terminal windows don't show after reloading window, but tasks still keep running

VSCode Version: 1.14.1
OS Version: Windows 10 Pro

Steps to Reproduce:

Start a server with npm in an integrated terminal window.
Install an extension, then reload window.

The server still keeps working. I've tried closing vscode and then opening it but the server still keeps running.
Reproduces without extensions: Yes

Duplicate of https://github.com/Microsoft/vscode/issues/26807


Ability to add substrate keys to keystore

Is your feature request related to a problem? Please describe.
To support substrate, the keys need to be added to the mailchain keystore.
Describe the solution you'd like
Expand the add command to include adding substrate keys.
Describe alternatives you've considered
N/A
Additional context
substrate has a different curve ed25519 and the public address which the keystore uses as an index is different for each network. This is mean that the address index will need a re-think

ref #271

Alter keystore.Store interface
// Store private keys but does not return them, instead return decrypter or signer.
type Store interface {
	GetSigner(address []byte, chain string, deriveKeyOptions multi.OptionsBuilders) (signer.Signer, error)
	GetDecrypter(address []byte, decrypterType byte, deriveKeyOptions multi.OptionsBuilders) (cipher.Decrypter, error)
	Store(private crypto.PrivateKey, curveType string, deriveKeyOptions multi.OptionsBuilders) (address []byte, err error)
	HasAddress(address []byte, protocol, network string) bool
	GetAddresses(protocol, network string) ([][]byte, error)
}

Need to  change /addresses to include protocol and network as query string parameters

If you are running mailchain <= v0.0.37 you will need to re-add your keys to the keystore. This change resulted in changing the way that keys are stored, the old index of address has been replaced by public-key


Pausing while active jobs not updating job state

Hi,
So pause and resume works in that when I have a queue of jobs and pause them, no other jobs in the queue are processed until I resume, perfect.
The problem is that the jobs that are "active" and successfully complete never get updated to "complete" and stay "active" even after resume.
My job queue processes 10 jobs asynchronously, while they're processing (I'm just using a timeOut for testing) I pause them and resume them and this is then my output.
Job #895 got queued of type: communication-sms
Job #896 got queued of type: communication-sms
Job #897 got queued of type: communication-sms
Job #898 got queued of type: communication-sms
Job #899 got queued of type: communication-sms
Job #900 got queued of type: communication-sms
Worker is paused...
Worker is paused...
Worker is paused...
Worker is paused...
Worker is paused...
Worker is paused...
done! 895
done! 896
done! 897
done! 898
done! 899
done! 900
Worker has resumed...
Worker has resumed...
Worker has resumed...
Worker has resumed...
Worker has resumed...
Worker has resumed...

After the "done!" output a "Job #x completed!" output is expected in the console but these jobs are not updated to have completed even though they do complete (as seen by "done!").
So I end up having lots of "active" jobs in my queue even though they have completed!
This is surely not intended behaviour? And if it is, then it shouldn't be...
Any help on this issue? Thanks!

I believe I am encountering the same issue, I simply want to process jobs one at a time but wait for 5 seconds after each job of that type before processing the next one, so I have this example code:
Jobs.process('testJob', function(job, ctx, done) {
	setTimeout(function() {
        done();
        ctx.pause(5000, function(err) {
          setTimeout(function() { ctx.resume(); }, 5000);
		});
	}, 1000);
});

what happens is that when ctx.pause() is called it never completes the job in redis, that means I never receive the Jobs.on('complete') event even though the job obviously completed
if I dont call ctx.pause() directly after the done(), e.g I delay it by 1000ms, then I do get the event, so it seems as soon as ctx.pause() is called it will no longer update active jobs as complete when they are marked as done
for my use case I would already be happy with a hint on how to properly implement the pattern "process jobs one at a time but wait x seconds in between", but I do agree with OP that this behaviour of .pause() is not expected

Yes, it seems as a race between pause and done


Advanced Inscribers item extraction issue

Using the latest ae2stuff, it does not seem like Inscriber Presses are able to be extracted once inserted into the advanced inscribers.  Is this intended, and if so, could it be changed to allow extraction of the presses along with everything else?
Thanks.

I like how it works now because it allows automation without filters on everything. I'll think of a way to add this as an option while keeping the current behavior as the default.

Maybe as a config option, or possibly a per machine option in the GUI?

I'm adding a gui button that locks/unlocks the top/bottom slot. Default is locked (which behaves like now).
If unlocked AND the middle slot is empty  AND no current process is ongoing - the top/bottom slot will be able to be removed by automation.


feat(curriculum): add i18n-curriculum submodule

This adds the i18n-curriculum submodule to the repo and some conditions to build using it. It's an intermediary step to move the all the i18n curriculum files out of the main repo. It shouldn't affect any of the existing build process.
When you checkout the PR, the i18n-curriculum folder will show up in the curriculum folder of your file tree - it will be empty. You can build in any language and it will use the existing curriculum files. There's a new BUILD_WITH_SUBMODULE env variable, set it to true to build using the i18n-curriculum submodule folder. Now, if you are building English, it will continue to use the existing curriculum files - but if you change it to any other language, it will use the files in the i18n-curriculum folder. It's still empty so building now will fail. Run git submodule update --init to download all the curriculum files. Now the i18n builds will work.
Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Blocked while I come up with a list of the next steps to finish the process of moving to use the submodule entirely.

Hey Tom, this looks great. It's much cleaner than I'd feared!
One thing confused me, though. When I'm using the submodule, should that be the source of truth for everything, including the english? Or is it supposed to be the case that, even though there's english in the i18n-curriculum/curriculum (challenges and dictionaries), it should be using the english from the original curriculum folder?
As the PR stands, it's using a mixture. Challenges use original for english, but the i18n folder for other langs, but dictionaries use the i18n folder for both.

English exists in the i18n-curriculum folder cause when we download from crowdin, it needs to know the sources or it doesn't know where to put the downloads or something - which are English and don't exist in the i18n-curriculum repo as they do in the main repo. So we need to download the English sources when downloading. I suppose we could remove them from that repo and the PR's after we download the rest of the i18n's and not commit the English.
So those english files don't align with what's on the main repo - they're aligned with the last crowdin upload. So...

should that be the source of truth for everything

No, we are still using the main repo for everything English. Everything else, should use the submodule.

As the PR stands, it's using a mixture. Challenges use original for english, but the i18n folder for other langs, but dictionaries use the i18n folder for both.

I'm not sure that's the case...
 const englishDictionaryDir =
    process.env.BUILD_WITH_SUBMODULE === 'true'
      ? path.resolve(DICTIONARIES_DIR)
      : path.resolve(dictionariesDir);

DICTIONARIES_DIR is the main English, and if !submodule, dictionariesDir is also the main English. It's a little goofy because of some of the existing code and tests. I could potentially use a pair up to get another opinion on that.
When using the submodule, it uses the

I suppose we could remove them from that repo and the PR's after we download the rest of the i18n's and not commit the English.

Unfortunately, no, because we loop over it. There might be another place to put the list of languages, though.

It's a little goofy because of some of the existing code and tests

Sorry, you're right. If it's alright with you, I'll just push a refactor, since the existing code is bad and shouldn't constrain us.

Unfortunately, no, because we loop over it.

I'm not sure I understand - can you clarify a little? I don't think we do anything with that English folder, but I might be wrong.

I'm not sure I understand - can you clarify a little? I don't think we do anything with that English folder, but I might be wrong.

It's this line:
https://github.com/freeCodeCamp/freeCodeCamp/blob/9b71e7a94095ac81482707c6f8f702be51d9e117/curriculum/get-challenges.js#L47
but, you're right, it doesn't actually matter.
I've made that more explicit, by actively filtering out the english, so it's clear that these are the other languages.
Anyways, I think this last commit simplifies things a little, but it's not a huge difference. Feel free to revert it if you don't like the changes.

Well, I've made it testable, but it's not nice... and now the tests are failing. That is to say: I struggled too and I think it's probably worse now :/ I'll have one more go, but I'm not confident I'm getting anywhere.
All the problems seem to stem from always using the english from the curriculum folder and never from i18n-curriculum/curriculum. I get that this would be a big change, but I think it's where we're going, right? i.e. the workflow looks something like this:

A contributor changes the english curriculum
Upload the changes to Crowdin AND create a PR syncing those changes with i18n-curriculum's english
Download the changes, creating a second PR
Merge both PRs (thereby ensuring english and the rest are in sync)
Build entirely from i18n-curriculum

The details of how we keep them in sync are a bit unclear, but that's the gist.

No, that is not the workflow I was going for. I was trying to do what the code was doing - use the i18n-curriculum for the i18n curriculum and still use the main repo for English.
The English folder in the i18n-curriculum repo would be in sync with the rest of the languages. I thought we could potentially use those to build so we don't ever have to worry about things being in sync.
The workflow would be:

A contributor changes the english curriculum
Upload the English to crowdin
Run the download on i18n-curriculum - which automatically creates and merges a PR on that repo, and automatically creates a PR on the main repo to update the submodule.
Continue using main repo for English builds, use i18n-curriculum for other languages.

The workflow would be:

A contributor changes the english curriculum
Upload the English to crowdin
Run the download on i18n-curriculum - which automatically creates and merges a PR on that repo, and automatically creates a PR on the main repo to update the submodule.
Continue using main repo for English builds, use i18n-curriculum for other languages.

I agree except for 4. We can make our lives simpler if we use the i18n-curriculum for all languages. Reason being, we can always update it such that the english and translations are both based off the same main repo commit, i.e. delegate all syncing responsibilities to it. If its main branch is always synced (i.e. no updating the english without also updating everything else), then it should (almost) always be ready to build.

Want to take a look at those and see if they make sense @ojeytonwilliams - or if you think there's a better way or I'm missing anything or anything.

They sound good to me.

I agree except for 4. We can make our lives simpler if we use the i18n-curriculum for all languages...

I like that idea, but I'm not sure I fully understand how it would work. Wouldn't it be behind main then? What would the workflow look like? Maybe we can discuss tomorrow.

Oh I get it.
If we upload the English files from the freecodecamp repo, but build from the English files in the i18n repo (which we download from Crowdin), then we eliminate the whole issue where files get out of sync and the tests fail until we do a download.
Because the English build files are pulled directly from Crowdin, they'd have parity with all of the translated files.

build from the English files in the i18n repo

I have floated this idea before. I think we partially didn't want to do it because we wanted the client to have the latest content. Also, I think there was an argument about relying on what comes from crowdin.

Yeah, credit where it's due: this is your idea, Tom!
So, I think the delay is fine. People can still work on the latest content, it's just that the builds that will lag and not by much.
As for relying on Crowdin, that needs some thought. I don't think we'll necessarily need to increase our reliance, but we'll still need some way of patching the problematic challenges.
I like the general idea, though.

So, I think the delay is fine. People can still work on the latest content,

I believe that approach might lead to confusion. The main purpose of maintaining the curriculum in the main repository is to avoid any ambiguity. Having multiple copies could result in uncertainty about what is live and what is not when merging or pushing to production branches. While we might understand the distinctions, external contributors may not. This could make it even more challenging for them to contribute effectively, as evidenced by our current contribution volumes.
I am open to the idea of using a separate repository for the entire curriculum. However, I am not in favor of maintaining inconsistent copies of the same language.

Alright. This should be good to go. I removed the English files from the i18n-curriculum repo. Now there's only the main English files.

Look for link to a document with the battle plan in chat

As per the plan additional coding activity is required right after merging this PR to keep main branch stable for deployments. Blocking the merge until a cleaner path.


⚠ Bofrost.be has degraded performance

In 6a759fe, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1129 ms

Resolved: Bofrost.be performance has improved in f734c06 after 9 minutes.


Feature: Add ability to do image feature extraction/object-detection using AWS Rekognition

Q: Should this be done in a new Lambda function or as part of the same/single lambda function?
Q: Should this be a lambda function in a separate project?

[ ] add configuration to enable feature
[ ] Integrate AWS Rekognition API
[ ] add option to save to JSON in S3
[ ] add option to save to DB: DynamoDB (Add IAM, create table?)
[ ] add option to save to DB: MongoDB
[ ] add option to save to DB: MySQL-compatible (use something like Knex to support any SQL-like DB?)

Somewhat related to #21

@adieuadieu are you still working on all the enhancements? Nice job btw.

@superandrew213 Thank you. Yes! What would you like to see? (or rather, what would you like to see first?) I have some basic Rekognition stuff ready, including integration into DynamoDB—but I want to refactor it a bit before I commit/push it. Also, I'm aiming to close #18 and release 1.0 before I add Rekognition features.

https://github.com/adieuadieu/serverless-sharp-image/issues/3 would be nice to have for completeness. Looking forward to try Rekognition.

This feels like it should be it's own Lambda function...

@bluepeter yea; I think so to, for the most part. Definitely would follow the whole "microservices" architecture better. My main thought about why you might want it in the same lambda function has to do with performance/optimisation. E.g., say you have a 16MB image. Due to the AWS Recognition API limits of 15MB max image size, you'd have to resize the image. As two separate lambda functions, you'd be separately resizing the image twice, which, at scale, could result in nearly double the operating cost. One way to solve this would be to chain the two functions, perhaps with AWS Step Functions.. but because the resize function can output multiple resized images, or even otherwise manipulate the image, which resized photo should the second recoknition-lambda function use? In other words, I wonder what the best way is to tie the two functions together—or maybe not at all and if you have to resize twice.. tough luck?


store-histogram: Show filename in error message when hit the file not found exception

Problem
When store-histogram hit an exception of file not found, it will be nice to show the filename in the error message to help debugging.
thread 'main' panicked at accounts-db/store-histogram/src/main.rs:252:58:
called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Summary of Changes
add filename in file not found exception message
Fixes #

sorry to request review again.
need to format the file.

this is fine. I'd rather it just keep running and log failing files. If you are running this while a validator is running, it could clean something away and delete it after getting the dir but before opening the file.

Ah. Make sense. That explains when I watch this command every 2 seconds. It failed from time to time.
I push a commit to skip failed metadata.


mapproject with crop window

Hi,
I don't think it's currently possible(?), but it would be very useful to be able to mapproject an image using a cropbox defined from the raw image (like using -srcwin in gdal_translate). Otherwise, if you want to mapproject only a small region, you have to crop the raw image manually and adjust the camera file... or use projwin, but this requires you to know the eventual projected coordinates of the raw cropbox positions... and anyhow, if the raw image is oriented substantially off NSEW, the final mapprojected image will show areas outside of the cropbox.
Cheers, J

mapproject has the option --t_pixelwin in addition to --t_projwin. I never used it myself, but it is documented, and I think we use it internally when we perform the map-projection using multiple processes with each allocated a tile.  See if it works for you.

t_pixelwin refers to the pixel positions in the final mapprojected image, not the raw... so you need to know where the image will end up before you can choose the relevant positions.
Maybe this is a bug(?), because I can't see the value of having t_pixelwin for cropping when t_projwin exists for cropping the final mapprojected image.

I don't think there is currently a way to do this besides cropping the input image.

I looked at the code. There is a lengthy chain of function calls getting deep into VisionWorkbench that would need to be overhauled to make it possible to choose a custom input image region to which to restrict the map-projection.  Some lad who wrote that code, long time ago, just was not enough of a visionary, I guess. I think the case for having this functionality is not very strong for now to warrant such extensive code rework.


[SMALLFIX] Consistently use basenames for UfsStatus names

For getStatus, we always set the UfsStatus name to the full path, but never seem to use it anywhere.
For listStatus, we always set the UfsStatus name to the basename, and do sometimes use it.
It would be nice if we could be consistent with what type of path we store in UfsStatus. Given that we currently rely on listStatus using basenames, I propose using basename consistently.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19151/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19167/
Test PASSed.

We actually do both, logging a warning if the caller passed a non-basename. I preferred this approach so that users aren't surprised when their names are base-ified.


Uploaded Product component UI Kit

Description
The Product Component introduces significant enhancements to the e-commerce UI Kit, specifically focusing on the Product Card, Product Carousel/Slider, Product List and Grid View, and Product Details Page. These updates aim to improve the visual presentation, usability, and overall user experience when browsing and exploring product-related information within the application.
Motivation
The motivation behind these changes is to enhance the overall shopping experience for users by providing a visually appealing, informative, and intuitive presentation of products. The previous components had limitations in terms of visual consistency, information visibility, and interactivity. By improving the Product Card, Carousel/Slider, List and Grid View, and Product Details Page, we aim to elevate the user's browsing experience, increase engagement, and drive conversions.
Changes Made

Enhanced the Product Card with improved visuals, pricing, and essential details.
Optimized the Product Carousel/Slider for dynamic and interactive product browsing.
Introduced toggleable List and Grid View options for flexible display preferences.
Refined the Product Details Page with an improved layout and comprehensive product information.

Checklist

[x] Code follows the project's style guidelines.
[x] Tests have been added or updated to cover the changes.
[ ] Documentation has been updated, if applicable. Mark ☑ in the component section of readme.md file.
[x] All new and existing tests pass.
[ ] The code has been reviewed by at least one other developer.
[x] The pull request is linked to the corresponding issue, if applicable.

Screenshots (if applicable)
Product Card
The Product Card has undergone improvements to provide a more visually appealing and informative representation of individual products. The design updates include enhanced product imagery, clearer pricing and discount information, and improved visibility of essential details such as product name, ratings, and availability. These enhancements make it easier for users to evaluate and select products at a glance.
Product Card- Light Mode

Product Card - Dark Mode

Product Carousel/Slider
The Product Carousel/Slider has been optimized to showcase multiple products in a dynamic and interactive manner. Users can now easily swipe or click through a collection of product images and details, providing a more engaging and immersive browsing experience. This updated component allows for better product discovery and comparison.
Product Carousel/Slider - Light Mode

Product carousel/Slider - Dark Mode

Product List & Grid view
The Product List and Grid View is to offer flexible viewing options based on user preferences. Users can now toggle between list and grid layouts, allowing them to choose the most suitable display format for their browsing needs. This customization feature enhances user satisfaction and provides a more personalized shopping experience.
Product List & Grid view - Light Mode

Product List & Grid view - Dark Mode

Product Details Page
The Product Details Page has the presentation and accessibility of comprehensive product information. The layout enhancements include clearer product descriptions, specifications, customer reviews, and related products, enabling users to make well-informed purchasing decisions. These updates enhance usability and provide a more comprehensive view of each product's details.
Product Details Page - Light Mode

Product Details Page - Dark Mode

Hey @Rishika-S-V
Thanks for putting this PR up
We'll review it merge if all is good

LGTM


HMR doesn't seem to be working properly.

Version
3.0.3
Node and OS info
Node: v10.7.0, Npm: 6.1.0, MacOs High Sierra 10.13.4
Steps to reproduce
This is a new project. Here are all my dependencies at the moment:
"dependencies": {
    "axios": "^0.18.0",
    "glob-loader": "^0.3.0",
    "lodash": "^4.17.11",
    "vue": "^2.5.17"
  },
  "devDependencies": {
    "@types/jest": "^23.3.2",
    "@vue/cli-plugin-babel": "^3.0.3",
    "@vue/cli-plugin-eslint": "^3.0.3",
    "@vue/cli-plugin-unit-jest": "^3.0.3",
    "@vue/cli-service": "^3.0.3",
    "@vue/eslint-config-prettier": "^3.0.3",
    "@vue/test-utils": "^1.0.0-beta.25",
    "babel-core": "7.0.0-bridge.0",
    "babel-jest": "^23.6.0",
    "lint-staged": "^7.2.2",
    "node-sass": "^4.9.0",
    "sass-loader": "^7.0.1",
    "vue-cli-plugin-styleguidist": "^0.1.4",
    "vue-template-compiler": "^2.5.17"
  }

These are my scripts, and I see the behavior when I simply run serve (which I point to that file which is basically to render the components in the library (this is for a library of internal components):
  "scripts": {
    "build": "vue-cli-service build --target lib src/main.js --name component-lib",
    "lint": "vue-cli-service lint",
    "prepare": "npm run build",
    "dev": "vue-cli-service serve --open src/__DevSandbox__/index.js",
    "styleguide": "vue-cli-service styleguidist",
    "styleguide:build": "vue-cli-service styleguidist:build",
    "test": "vue-cli-service test:unit",
    "test:watch": "vue-cli-service test:unit --watch"
  }

I'm not sure if anyone else is seeing this issue as well but basically adding
devServer: {
    watchOptions: {
      poll: true
    }
  }

fixes the issue.
What is expected?
HMR should be working.
What is actually happening?
I needed to add
devServer: {
    watchOptions: {
      poll: true
    }
  }

In order to get hmr working as expected.

This issue exist for any project using webpack, basically. Webpack's file watch mechanism can fail to pick up changes under various circumstances. Their docs say this:

If watching does not work for you, try out this option. Watching does not work with NFS and machines in VirtualBox.

From my experience maintaining our previous webpack template, there also are or were other factors that could be problematic for some users, like file paths with special characters, folders watched by tools like Google Drive / Dropbox, folders within a vm, etc.
There's nothing we can do about this, really.


[10.1.x] ISPN-13229 LocalPublisherManagerImpl doesn't clean up changeListener …

Backporting the fix for Memory leak issue in 10.1.x release.

Thanks @Madhumitha-G-ML


Add the Search tab for GitLab

Roaming around GitLab with GitTouch is hard, can you add the Search tab for GitLab?

@pd4d10 Can I do this? Per this, there are many scopes, but I should do only projects, issues and users, similar to github right? Also, do you have any intent in migrating to graphql?(this one though can only be done through REST)

@shreyas1599 Sure, that would be great.

@pd4d10 Can I do this? Per this, there are many scopes, but I should do only projects, issues, and users, similar to GitHub right? Also, do you have any intent in migrating to GraphQL? (this one though can only be done through REST)

@shreyas1599 So, in the global search, we only pull projects, users, and issues` s scopes to search. And speaking of GraphQL, maybe we can ask GitLab about migrating to GraphQL like what GH does?

And speaking of GraphQL, maybe we can ask GitLab about migrating to GraphQL like what GH does?

Yeah, they have graphql support only for a few API's. They're slowly adding them, I think.

Hi, @AndreiJirohHaliliDev2006 , are you using iOS or Android devices?
Thanks to the PR by @shreyas1599 , Android beta version has been released: https://play.google.com/apps/testing/io.github.pd4d10.gittouch
iOS test flight version is being reviewed. I'll update the link once it's finished.
For detail see this issue: https://github.com/git-touch/git-touch/issues/61
Thanks for your feedback!

Hi, @AndreiJirohHaliliDev2006 , are you using iOS or Android devices?
Thanks to the PR by @shreyas1599 , Android beta version has been released: https://play.google.com/apps/testing/io.github.pd4d10.gittouch
iOS test flight version is being reviewed. I'll update the link once it's finished.
For detail see this issue: #61
Thanks for your feedback!

I am using Android 4.4.3. I'll join the beta testers squad soon as I am back on my phone. Thanks again, @pd4d10.


Publish Docker image

Now that we're open source (🥳), it's time to get an image pushed to Docker Hub, and the deployment manifests updated to match.

Please ensure the docker image is multi-architecture supported. Popular architectures like arm64 often missed, using buildx should make supporting multiple architectures trivial, happy to help if needed.

The one built right now, that isn't being published anywhere, isn't multi-architecture. However, I agree, and hope to get that working soon.

@terinjokes if you publish the Dockerfile and are happy I can set up some workflows in GHA and get it built and compiled for multi-archiecture?

An update here: I'm still planning on doing this. I'm running into a temporary permissions issue in Docker Hub creating this image and getting credentials to publish from Actions. I hope to have this sorted soon. I'm really sorry for the delay.

All good, can help out if required as I've done this many times, but let me know.

This isn't a technical problem, unfortunately.

Has this image been published yet ?

Nope. I still do not have the correct permissions in Docker Hub.

Is there a way to locally build this image ?

If you have nix installed you can build ./hack/docker.nix.
$ nix build -f ./hack/docker.nix
[11 built, 10 copied (1.5 MiB), 0.4 MiB DL]

$ docker load < result
docker load < result
a630bb07cd03: Loading layer [==================================================>]  1.649MB/1.649MB
14f0fd68d210: Loading layer [==================================================>]    256kB/256kB
7862e9b9223d: Loading layer [==================================================>]  31.63MB/31.63MB
ca397a15dfa0: Loading layer [==================================================>]  573.4kB/573.4kB
542652079767: Loading layer [==================================================>]  112.6kB/112.6kB
255355ea7603: Loading layer [==================================================>]  2.888MB/2.888MB
48ca96316146: Loading layer [==================================================>]  36.37MB/36.37MB
bab8c8268779: Loading layer [==================================================>]  10.24kB/10.24kB
Loaded image: origin-ca-issuer:dvx0mk1aysi6s46r2k3iis92b19klnk1

If you don't have nix installed, I've found the nixpkgs/nix:latest image works well, just make sure to copy the destination of the result symlink before exiting the container.
$ docker -v $(pwd):/opt/work -w /opt/work --rm -it nixpkgs/nix
bash-4.4# nix build -f ./hack/docker.nix
[12 built, 137 copied (951.8 MiB), 225.9 MiB DL]

bash-4.4# cp result image.tar.gz

bash-4.4# exit

$ docker load < image.tar.gz
f04b2eecad2b: Loading layer [==================================================>]   36.4MB/36.4MB
bab8c8268779: Loading layer [==================================================>]  10.24kB/10.24kB
Loaded image: origin-ca-issuer:dvx0mk1aysi6s46r2k3iis92b19klnk1

Obviously, once I have access to pushing to Docker Hub you'll be able to docker pull (or, more relevantly, stick in your YAML) without needing to know or worry about nix at all.

If you don't feel like doing that, this is my local build from rev e06fedae20300b4552aaed60a6b2684a1d5964b8: image.tar.gz (21MB)
$ sha256sum image.tar.gz
ecd572a4402b771e01b7c8865142c737fc0992cd0cca598262878fc309e9c65c  image.tar.gz

what is blocking this?

I don't have permission to publish to the Cloudflare Docker Hub organization. I'm working with an internal team to get the permissions sorted out.

Sorry for the delay. I've published cloudflare/origin-ca-issuer:v0.5.0 for amd64 and arm64.


PowerToys Run should prioritise the "Settings" packaged application option over the "Settings" application option (which resolves to Control Panel)

Description of the new feature / enhancement
As per the title, when typing settings and pressing enter, the old Control Panel is opened on Windows 10. Whilst it's still possible to launch both, for a user that mostly deals with the new Settings app, it is a nuisance. Changing the behaviour (not sure it should be global, just for these two items) would improve the flow of those who type quickly without thinking, and matches the behaviour of the Windows 10 Start Menu.
Scenario when this would be used?
When a user wants to open the settings app with PowerToys Run
Supporting information
Steps to reproduce (not classing as a bug because it might be that behaviour wasn't spotted, and you can still work around the issue):
Type "Settings" into PowerToys Run and press 'Enter'.
The control panel opens instead of the Settings app.
The settings app only opens if the item selected is "packaged application".

@jaimecbernardo
We should exclude the shortcut in Startmenu which is called "Setting", has the modern logo and opens the controlpanel.exe. The shortcut makes no sense because there is the control panel shortcut itself and the package modern settings app.

Can also confirm W11 is not affected. If excluding the shortcut fixes it, then great.

So, my point of view in this is that it is a shotcut present in %programdata%\Microsoft\Windows\Start Menu\Programs It's a valid shortcut to an application that's present in the machine. If a user has no use for this shortcut, can I advise to delete the shortcut instead?
Does this make sense?
/needinfo

So, my point of view in this is that it is a shotcut present in %programdata%\Microsoft\Windows\Start Menu\Programs It's a valid shortcut to an application that's present in the machine. If a user has no use for this shortcut, can I advise to delete the shortcut instead?
Does this make sense?
/needinfo

yes.


Support PyTorch >=1.7

When using PyTorch >=1.7, the following error would occur at the beginning of training:
RuntimeError: stft input and window must be on the same device but got self on cuda:0 and window on cpu

A solution to this is https://github.com/kan-bayashi/ParallelWaveGAN/pull/225. However, this can be easily solved by using PyTorch <1.7, so this is rather a note for future users.

Hi Unilight,
thank you very much!!
I will merge the modification into the current repo.


[stable/gitlab-ee] Removing the logo as it is not accessible

The logo is causing issues with Artifact Hub

/lgtm

Merging in as this is a legacy deprecated chart from long ago. The only change is removing the icon.


modifications to the common anode RGB LED also works

app becomes appgnd app5v (amend Part 1)

app becomes appgnd app5v
appgnd => led with common cathode
app5v => led common anode

app becomes appgnd and app5v (amend part 2)

app5v modification to work with RGB LED anode
common

Control-led-rgb fails to serialport

Last serialport no longer part of johnny-five and do
load more during an npm install.
on my PC, it works with version 1.4.10, the latest bug. to
certainly revisit this ...

Uploading documentation related app5v

diagram for app5v (RGB led common anode)
PS: I added 330ohm of resistance

Hey!
sorry for the delay, thank you for to contribute.


nixos-rebuild: fix condition for byAttr in edit action

Description of changes
the condition edited was always true since buildFile was defined by default. this prevented running that action
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4386


Omit localhost tracking warning

I would like to get rid of the console warning which is provided when tracking on localhost is disabled (*). Ideally it should be possible to disable it through the options. (Or the other way around, only allow it to enable it on purpose but disable it by default – but that would be a breaking change.)
Would a PR be appreciated here?
Thanks
Thomas
(*)
https://github.com/plausible/plausible-tracker/blob/294405cafc934ee666c1a295a5b2fd8737993ce2/src/lib/request.ts#L45

I would love this as well, the [Plausible] Ignoring event because website is running locally warning is littered all over when I run our test suite on my machine

Hello,
Since this package have not been update for two years, I made a fork.
I rewrite the tracker to be more modular and I fix this issue.
https://github.com/Barbapapazes/plausible-tracker

Good to know @Barbapapazes, I will give your fork a shot soon.