CRITICAL BUG // DefaultLimitNOFILESoft=1024

Description
My GitHub actions started failing on 7/22/22... after lots of troubleshooting, I realized a new virtual environment was pushed between my successful run on the 21st and the failures starting on the 22nd.
I can't check what the limits were on the previous Ubuntu image, but for the current one, the build steps are launching with systemd limits of:
DefaultLimitNOFILE=65536
DefaultLimitNOFILESoft=1024

Note the soft limit of 1024. After lots of troubleshooting, I believe it's that limit which is causing my jobs to fail. I'm testing Packer templates, and that tool uses Go. Every step launches a new process. Because my templates have gotten rather larger, this results in several hundred processes, all of which use unix sockets ot communicate with each other. The result is thousands of open file handles. I believe the limiter is what is causing the templates to fail, since 1024 is far below what is needed.
Platforms affected

[ ] Azure DevOps
[X] GitHub Actions

Virtual environments affected

[ ] Ubuntu 18.04
[X] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 10.15
[ ] macOS 11
[ ] macOS 12
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
Environment: ubuntu-20.04
Version: 20220717.1
Included Software: https://github.com/actions/virtual-environments/blob/ubuntu20/20220717.1/images/linux/Ubuntu2004-Readme.md
Image Release: https://github.com/actions/virtual-environments/releases/tag/ubuntu20%2F20220717.1
Is it regression?
Yes. 20220717.1
Expected behavior
My GitHub actions should pass!
Actual behavior
My GitHub actions now fail!
Repro steps
This example would need to checkout the lavabit/robox repository.
name: Robox Validate

jobs:
  Build:
    runs-on: ubuntu-20.04
    env:
        LANG: en_US.UTF-8
        LANGUAGE: en_US:en
        LC_ALL: en_US.UTF-8
    steps:
    - uses: actions/checkout@master
    - name: Install Dependencies
      env:
        DEBIAN_FRONTEND: noninteractive
        DEBCONF_NONINTERACTIVE_SEEN: true
      run: |
        curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
        sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
        sudo apt-get update
        sudo apt-get --assume-yes install packer
    - name: Validate Generic Box Configurations
      env:
        GOGC: 50
        PACKER_LOG: 1
        GOMAXPROCS: 1
        VERSION: 1.0.0
      run: |
        date +"%nStarting generic box validation at %r on %x%n"
        export PACKER_LOG_PATH=generic-docker.txt ; packer validate generic-docker.json &>> packer-validate.txt && printf "File  + generic-docker.json\n" || { printf "File  - generic-docker.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-hyperv.txt ; packer validate generic-hyperv.json &>> packer-validate.txt && printf "File  + generic-hyperv.json\n" || { printf "File  - generic-hyperv.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-libvirt.txt ; packer validate generic-libvirt.json &>> packer-validate.txt && printf "File  + generic-libvirt.json\n" || { printf "File  - generic-libvirt.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-parallels.txt ; packer validate generic-parallels.json &>> packer-validate.txt && printf "File  + generic-parallels.json\n" || { printf "File  - generic-parallels.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-virtualbox.txt ; packer validate generic-virtualbox.json &>> packer-validate.txt && printf "File  + generic-virtualbox.json\n" || { printf "File  - generic-virtualbox.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-vmware.txt ; packer validate generic-vmware.json &>> packer-validate.txt && printf "File  + generic-vmware.json\n" || { printf "File  - generic-vmware.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-libvirt-x32.txt ; packer validate generic-libvirt-x32.json &>> packer-validate.txt && printf "File  + generic-libvirt-x32.json\n" || { printf "File  - generic-libvirt-x32.json\n" ; exit 1 ; }
        export PACKER_LOG_PATH=generic-virtualbox-x32.txt ; packer validate generic-virtualbox-x32.json &>> packer-validate.txt && printf "File  + generic-virtualbox-x32.json\n" || { printf "File  - generic-virtualbox-x32.json\n" ; exit 1 ; }
        date +"%nFinished generic box validation at %r on %x%n"

Hey @ladar.
You can change this limit:
https://github.com/actions/virtual-environments/issues/4683#issuecomment-988542768
https://github.com/actions/virtual-environments/issues/3738#issuecomment-881207263
Default settings:

- name: ulimit
  run: |
      sudo prlimit --pid $$ --nofile=500000:500000
      ulimit -n

So I don't know definitively what caused the breakage between the 20220717 and 20220722 images.  So the issue could be at a lower level.
I don't know which change fixed the problem, but I wasn't able to get the workflow to run reliability until I increased the swap size from 4096 to 8192. Some of my other changes may have also helped, as they reduced the memory footprint. In particular net.unix.max_dgram_qlen combines with net.core.wmem_default and net.core.wmem_max to limit the backlog for unix sockets. Critically though, the Linux kernel requires the entire memory block (qlen*wmem) to be a contiguous for unix sockets. If the host running the image faces memory contention, it might not be able to find a contiguous block, which can cause the symptoms I saw.
The entire fixes:
- name: Increase Limits
  run: |
    sudo sysctl -q vm.overcommit_ratio=100
    sudo sysctl -q net.unix.max_dgram_qlen=64
    sudo prlimit --pid $$ --nproc=65536:65536
    sudo prlimit --pid $$ --nofile=500000:500000
    printf "DefaultLimitNPROC=65536:65536\n" | sudo tee -a /etc/systemd/user.conf > /dev/null || exit 1
    printf "DefaultLimitNPROC=65536:65536\n" | sudo tee -a /etc/systemd/system.conf > /dev/null || exit 1
    printf "DefaultLimitNOFILE=500000:500000\n" | sudo tee -a /etc/systemd/user.conf > /dev/null || exit 1
    printf "DefaultLimitNOFILE=500000:500000\n" | sudo tee -a /etc/systemd/system.conf > /dev/null || exit 1
    sudo systemctl daemon-reload
    systemctl --user daemon-reload
- name: Increase Swap
  run: |
    sudo dd if=/dev/zero of=/swap bs=1M count=4096 status=none
    sudo chmod 600 /swap
    sudo mkswap /swap
    sudo swapon /swap

I had to rerun the prlimit increase commands for each build step like so:
- name: Demonstrate Limit Increases for a Build Step
  env:
    GOGC: 50
    GOMAXPROCS: 1
  run: |
    date +"%nStarting a sample/example build step at %r on %x%n"
    sudo prlimit --pid $$ --nproc=65536:65536
    sudo prlimit --pid $$ --nofile=500000:500000

@al-cheb I saw you closed the bug. Were you able to figure out what changed between the 20220717 and 20220721 images?

I may be wrong, but I came across this issue while trying to remember how I helped a co-worker correct a problem with the open files soft limit previously.  What I recall was that while the kernel was configured to support a sufficiently large ulimit maximum, the GitHub Runner Action was spawned from a process in some ancestor unit file that was either explicitly setting or implicitly accepting a reduced soft limit.  The way these things inherit, you can always opt into a smaller limit, but you cannot raise your limit higher than what you inherit at process creation time.
In order for our own set of sufficiently large ulimit -nfiles to be effective, we had to modify this ancestor unit file to not restrict itself and its children quite as much.
I don't have that running example environment or access to one similar just now, so while I am sure we fixed his by raising the soft ulimit for open files in some ancestor systemd unit file, I cannot seem to recall which one we had to target for GitHub actions to inherit the correctly all the way back to PID=1.
Anyhow, I see this thread is relatively recent so thought I'd share what I had retained in case it is of some help/value.

This can be a hard issue to track down, because it runs contrary to how nix systems historically handled the open file limit (aka a hard max for the  kernel and via the ulimit interface). It's also an issue that gets buried inside the morass that is systemd, which is still an opaque MacGuffin to the average system administrator.
The quickest fix is:
sudo sed -i '/DefaultLimitNOFILE=/d' /etc/systemd/user.conf
printf "DefaultLimitNOFILE=65536\n" | sudo tee -a /etc/systemd/user.conf > /dev/null

sudo sed -i '/DefaultLimitNOFILE=/d' /etc/systemd/system.conf
printf "DefaultLimitNOFILE=65536:524288\n" | sudo tee -a /etc/systemd/system.conf > /dev/null

This will increase the default limits for everything, and save you lots of grief. Of course this assumes your not on a system shared by many, that is resource constricted. If that is the case, you'll need a more granular approach.
To see where the limits are, run  this:
 echo 'user'; systemctl --user show | grep NOFILE ; echo 'system' ;sudo sudo systemctl show  | grep NOFILE

And don't forget, the kernel maximum, and the ulimit values still apply, so update those as well, if necessary.


Update pekko-connectors-kafka to 0.0.0+1744-ec306c46-SNAPSHOT

About this PR
📦 Updates org.apache.pekko:pekko-connectors-kafka from 0.0.0+1738-07a19b8e-SNAPSHOT to 0.0.0+1744-ec306c46-SNAPSHOT
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.apache.pekko", artifactId = "pekko-connectors-kafka" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.apache.pekko", artifactId = "pekko-connectors-kafka" }
}]

labels: library-update, early-semver-build-metadata, semver-spec-build-metadata, version-scheme:semver-spec, commit-count:1

Superseded by #431.


Update 32blit.md

I just went over this again and realised it reads like the second sentence is referring to the first. Which it isn't. My bad.

Thank you! And no worries- the great thing about a "beta" repo is that we can just say "It's a beta" whenever something like this crops up.


Fix account registration bug

Description
Unable to register a new account due to redirection.
Changes

List your changes as bullet points
Include technical details or decisions if necessary

Screenshots (if applicable)
Include any relevant screenshots or GIFs that demonstrate your changes visually.
Additional Notes
Resolves #236

Bug not present on staging environment, only on local. Make this change in this PR on your local machine if required.


feat(sequence): interval stickiness

Builds on top of https://github.com/microsoft/FluidFramework/pull/15247 in order to implement interval stickiness

Copying relevant comments from local reference PR:

one more thing I thought of--since we already require back-compat for "stickiness absent from a serialized interval means forward stickiness", we might as well codify this pattern in the encoding to save some bytes.

This seems like a feature that should be called out in the release notes for the sequence package. If it's not ready to be used, that's ok - we can just note that the feature is coming and the initial work was done in this release. If you disagree that this is notable, just remove the changeset-required label and you can fill me in separately.


where did kube_config_cluster.yml come from?

There is some magic missing: Where does kube_config_cluster.yml come from?

rke cli creates the kube_config_cluster.yml in the installation folder.


There exists no mailing list for VIE and its widgets

Create a mailing list for VIE

CreateJS has a Google Group. We could either create one for VIE as well, or just use iks-dev. That list is relatively quiet


Building error

Insert (void) at beginning of line 63 in bitmexws.cpp. Corrected line is:
  (void)std::async(std::launch::async, [this]() { this->maintain_heartbeat(); });


Unable to properly select text in panels

Bug Description
When a creator tries to select the text in the prepublish checklist, something prevents this from happening. Selecting from the bottom captures a different set of text than selecting from the top

Expected Behaviour

Steps to Reproduce

open an existing story with some recommendations
use the standard click drag to select text from the Prepublish checklist recommendations
note the inability to select all text as expected

Screenshots

Additional Context

Plugin Version:
Operating System:
Browser:

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

Implementation Brief

Looked at this issue. Here are what I found:

Go the Checklist panel
Select some text (not the entire paragraph), stop for a 1~2 seconds
Keep select the remaining text, the cursor will be blocked for selecting text.

It seems like this issue is happening in the entire right side bar.

Should user be able to click-and-drag to select a portion of test? At present, this only seems to be working if user begins their click-and-drag at the start of copy
Also, shouldn't clicking elsewhere deselect selected text?

Should user be able to click-and-drag to select a portion of test? At present, this only seems to be working if user begins their click-and-drag at the start of copy

It depends on where you are trying to select text.
For example, partial selection works fine in the Page Advancement panel in the Document tab.
But it won't work in the Pre-Publish tab because those checklist items are actually clickable buttons. And you can't select text in a button. The browser won't let you do that :-)

Also, shouldn't clicking elsewhere deselect selected text?

Not necessarily. The browser will only clear selection depending on where you click next.
For example, it will clear selection when you click in search input field afterwards, but not when you click on a button (or the canvas, for that matter)

Verified in QA


hello. I encountered an error in my operation

I use unity version 2019.1.5f1.
Compute shader (MeshInfoTextureGen): Property (OutTangent) at kernel index (0) is not set
UnityEngine.ComputeShader:Dispatch(Int32, Int32, Int32, Int32)
d__3:MoveNext() (at Assets/AnimationBaker/Scripts/AnimatorTextureBaker.cs:79)
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

thank you!
AnimationClipTextureBaker is working fine.
I will fix AnimatorTextureBaker and AnimationTextureBaker!
here is difference

https://github.com/sugi-cho/Animation-Texture-Baker/blob/master/Assets/AnimationBaker/Scripts/AnimationClipTextureBaker.cs#L17-L22
https://github.com/sugi-cho/Animation-Texture-Baker/blob/master/Assets/AnimationBaker/Scripts/AnimatorTextureBaker.cs#L16-L20

AnimatorTextureBaker does not bake TangentTexture. but ComputeShader has Tangent data.


static site generator breaking on nested code blocks

Information:
v1.23 and v1.24 both caused this behaviour.
Description
I don't understand exactly what would have changed, but recently the gridsome static site generator started breaking when processing nested syntax code blocks. This presumably occurred with the latest release.
It can be fixed by adding a check for whether document exists in the current context.
https://github.com/PrismJS/prism/pull/2975
Additional description and examples in the related gridsome repo:
https://github.com/gridsome/gridsome/issues/1524

Duplicate of #2973.


Lecture Attachments: Full authentication is required to access this resource

Describe the bug
We added attachments to our lecture and one looks to be broken.
When we try to download the file, the following error occurs:
{
  "type": "https://www.jhipster.tech/problem/problem-with-message",
  "title": "Unauthorized",
  "status": 401,
  "detail": "Full authentication is required to access this resource",
  "path": "/api/files/temp/Fib_Solution.zip",
  "message": "error.http.401"
}

To Reproduce

Go to 'Lectures'
Click on 'Add Attachments'
Once done, try downloading it.

Expected behavior
The file should download.
Screenshots
No response
What browsers are you seeing the problem on?
Chrome, Firefox
Additional context
We are unable to reproduce it.
We kept the broken attachment in case it helps you debugging it.
The broken attachment can be found in our Speicher und Pointer lecture for the C-Vorkurs.
It's called Diesen Link bitte ignorieren....
Link to the lecture: https://artemis.ase.in.tum.de/courses/152/lectures/231
Relevant log output
No response

Closed, as I can not reproduce the issue.


Support Module Source Hierarchy

Expected Behavior
Since Java 9, the Java compiler and other JDK tools support two different ways to organize the source code: Package Hierarchy and Module Source Hierarchy (see Directory Hierarchies in javac documentation). However Gradle currently supports only Package Hierarchy, which was the only layout supported by all Java versions up to 8. Supporting Module Source Hierarchy in a Gradle project is possible, but difficult. It took us many weeks of effort, and the result is summarized in a page titled Java Module Source Hierarchy in a Gradle sub-project.
Issues #25954 and #25962 were filled as small steps for making easier for developers to hack a Gradle build, but it would be very appreciated if Gradle had out-of-the-box support for Module Source Hierarchy. It would require some way to tell to all Gradle tasks that a sub-project uses Source Module Hierarchy, then improvements in at least the following tasks:

compileJava and compileTestJava for using the --source-module-path option.
test for using the --patch-module and --add-exports options.
jar for generating one JAR per JPMS module instead of one JAR for the whole sub-project.
generatePomFile for filtering the dependencies on a per JPMS module basis.
javadoc in a way similar to compileJava.

We wrote Java code for supporting all the above in an experimental build of the Apache SIS project. It currently contains some hard-coded values because I do not have enough Gradle knowledge for doing it properly. But I would be happy to contribute with that code if Gradle team can provide guidance.
Current Behavior (optional)
No response
Context
Few developers are aware of the Module Source Hierarchy offered by Java tools since JDK 9, presumably because this layout is unsupported by both Gradle and Maven. However Module Source Hierarchy is used by the OpenJDK project itself and has some great advantages described in above-cited page. To summarize, it gives to developers an extra level of flexibility for organizing their modules, enables more compile-time checks of cross-module documentation, facilitates aggregated javadoc and aggregated annotation processing, facilitates the reuse of test fixtures between modules, and more. Module Source Hierarchy can help developers to write better code, it is unfortunate that developers can hardly use it.

As mentioned in the other issue, the JavaModuleDetector handles detecting whether a given dependency should be placed on the modulepath or the classpath, based on the presence of module-info files or Automatic-Module-Name attributes. This would be the place where I think we need to make updates.
You mentioned you'd be potentially interested in contributing a fix for this issue. I believe the solution to this problem should be entirely contained to the above-linked class. Along with the actual changes to that class, we'd also want to update JavaModuleDetectorTest. We'd also want to add integration tests:

JavaModuleExecutionIntegrationTest: Verify application plugin execution
JavaModuleCompileIntegrationTest: Verify java-library plugin compilation
Any other subclasses of AbstractJavaModuleIntegrationTest which may also need additional verification (javadoc, testing, at the minimum)

Thanks. I will take a look at those classes and come back if I have questions. It may take a few weeks.

After reading this issue again, it seems I misinterpreted the initial issue and this is much larger scoped than I had originally thought. I expect that for some of your listed tasks, implementations may be self-contained enough for external contribution, but for other more complicated tasks, internal design and implementation will likely be required.
Given that, in the next coming weeks, we will be discussing internally our plans for JPMS and if we will be able to dedicate resources towards improving Gradle's compatibility any time in the foreseeable future.
In any case, I think this issue is too complex -- containing too many acceptance criteria -- and should be split up into multiple linked issues so that we can more easily prioritize and track work for each task individually. However, this can happen after we've discussed more internally about priority.
For now, I think it is important to split off the most important work. Of the above-listed tasks, which do you feel are critical for even basic JPMS support in Gradle? Is there anything listed that, if fixed, can unblock significant use cases for users who wish to develop JPMS applications and libraries in Gradle?

Indeed it is a task of large scope, and I agree that it probably needs internal discussion in Gradle team for a plan. The list of tasks could be reworded in two main groups:
Recognize module pattern
The --module-source-path option of the Java compiler handles the *, { and } characters in a special way (see Module-pattern form on Oracle's documentation):
javac --module-source-path=/foo/*/bar

One possible way to support that in Gradle may be to introduce a new modulePattern method that can be used in setSrcDir like below :
sourceSets {
    main {
        java {
            setSrcDirs(modulePattern("src/*/main/java))
        }
    }
    test {
        java {
            setSrcDirs(modulePattern("src/*/test/java))
        }
    }
}

The use of modulePattern would have the following effects:

Set some flag inside Gradle telling that module source hierarchy is used. A consequence is that Gradle shall not emit the --source-path option anymore to the Java compiler, and emit the --source-module-path option instead with the modulePattern value verbatim (including the *, { and } characters),
For other consumer of source file directories that do not understand the module pattern, Gradle could behave as if the source files were expanded like below:

sourceSets {
    main {
        java {
            setSrcDirs(listOf(file("src/foo.bar.a/main/java),
                              file("src/foo.bar.b/main/java),
                              file("src/foo.bar.C/main/java),
                              /* etc. /* )
        }
    }
    test {
        java {
            setSrcDirs(listOf(file("src/foo.bar.a/test/java),
                              file("src/foo.bar.b/test/java),
                              file("src/foo.bar.c/test/java),
                              /* etc. /* )
        }
    }
}

Above expansion allows for instance a project to be opened in an IDE.
Caveats:

Make sure that dependencies are on the module-path.
If compiling only a few Java classes instead of all of them, it may be necessary to add an --add-modules option with a comma-separated list of all modules of the project (not dependencies). It tells the compiler to continue to take other modules in account even if none of their files is  recompiled.
When compiling tests, we need to generate a --patch-module option for each module to compile. Values are of the form module=test source directory.

Some code inspiration may be found here. This link contains hard-coded stuff specific to Apache SIS project, but the main idea can be seen.
Separation of JAR files
The JAR task needs to be aware that the Gradle sub-project can generate many JAR files (one per JPMS module) instead of one. This is easy to do since javac created a sub-directory for each module. We just need to iterate over those directories.
The Maven pom.xml file to generate needs a little bit more work because each JPMS module may use only a subset of the dependencies that we declared for the project. So ideally, each Maven pom.xml should have the dependencies filtered for containing only those that are used by the JPMS module. Some sources of inspiration may be found in this file.

Yes I was expecting that some kind of specification draft would need to be written. I can volunteer for that, but would need a mentor for both the form (where/how to write) and for saying what is the "gradle way" to design things.

Hello @big-guy. I can volunteer for drafting a proposal, but would it be possible to have someone to guide me? Where to write it, which template?

@big-guy, @ov7a : this issue is becoming a high priority for us. Without module source hierarchy, the Java compiler produces hundreds of warnings about unknown modules in opens or exports statements, or about unknown targets in Javadoc links. With module source hierarchy, we are getting complains from exasperated developers about the terrible lack of support in IDE, which get confused by the workarounds described in this issues. I would be happy to contribute with what I can, but I do not know Gradle internal and would need guidance. If there is a "change request" to fill, is there a template I could use? If there is a prototype to write, can someone point me to the code to edit?
Thanks

Hi @desruisseaux,
I read through the post you linked to in the description.
IIUC, you're proposing that if you have multiple modules, instead of organizing them as separate projects like:
module.a/src/main/java/...
module.b/src/main/java/...

You would instead organize them as a single project with multiple modules:
src/module.a/main/java/...
src/module.b/main/java/...

This seems to be at odds with what the JDK describes as a Module Source Hierarchy because that seems to follow the first convention (module name and then src/main/java). The post describes a similar, but different convention. I understand that this was just a suggestion in the javac documentation.
My reading of the original JEP that introduced these flags is that this was done to support layouts like the JDK uses. I don't think this translates well into general usage.
There are a few other problems with this approach:

A Gradle project typically produces a single "thing" (a library or application). If you have multiple modules, most plugins are going to be broken or ignore everything outside the "main" module unless they also understand something like a module-source-path or analyze each module as a separate group of sources.
A user typically wants to configure a single "thing" in a project. If you can have multiple modules in one project, users will either be unable to specify different dependencies for each module or jump through different hoops.

We aren't going to go in this direction.
That said, I do think our JPMS support is very basic and does the wrong thing. Instead of trying to build all the modules inside a single project, I think we should focus on how we detect when we need to treat something like a module. If there are specific problems here, we can discuss/fix those.
In the post, one of the motivations for this layout was to better separate modules.  You can do this in another way.  Instead of including all of the modules in one Gradle build (IOW, listing them all in a single settings.gradle), you can create several included builds.
So instead of endorsed representing a single Gradle project with many modules in it, you can have endorsed be a single Gradle build with multiple subprojects.  incubator and optional could be separate builds as well and they can all be brought back together with a single root build that includes them all.

Hello @big-guy. Thanks for the reply. I'm aware that we can create a Gradle build with many sub-projects, but this is not equivalent. As far as I know, there is no way to achieve some of the Module Source Hierarchy benefits with Gradle builds. More on it below. But first, a few clarifications:
JEP-201 indeed makes arbitrary choices with their src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java scheme. The src, share, $OS and classes parts in this scheme are arbitrary, in the same way as endorsed, incubator, src, main, test, etc. parts in my post were arbitrary. However, what are not arbitrary are the $MODULE and $PACKAGE parts. Before Module Source Hierarchy, the mandatory scheme was <anything>/$PACKAGE/*.java. With Module Source Hierarchy, the mandatory scheme is <anything>/$MODULE$/<anything>/$PACKAGE/*.java. The users can choose whatever they want for the <anything> parts. But the $MODULE and $PACKAGE parts are enforced by the javac compiler. So in the following comment:

IIUC, you're proposing that if you have multiple modules, instead of organizing them as separate projects like:
module.a/src/main/java/...
module.b/src/main/java/...

You would instead organize them as a single project with multiple modules:
src/module.a/main/java/...
src/module.b/main/java/...

The module.a/src/main/java/... versus src/module.a/main/java/... question is not important, and not the real topic of this issue because Gradle or the users can choose whatever they want. The important topic is to have the module.a and module.b parts handled by javac instead of Gradle, for the reasons exposed below.
With Module Source Hierarchy, building a group of modules is still done by a single call to javac or javadoc tools. This RFE is not a request for Gradle to iterate over the modules and invoke javac for each of them. For plugins that delegate their work to JDK tools working on source code, the impact should be small (mostly an adjustment in parameters) . For plugins working on JAR files, there is more work to do because they need to iterate over the JARs. But it still easy for some tasks such as signing. Furthermore, it may be acceptable to have those plugins throwing some kind of UnsupportedOperationException, and warn users that not all plugins support Module Source Hierarchy. Having javac, javadoc, jar, publish and signing support could be enough for starting (I can contribute code for them).

If you have multiple modules, most plugins are going to be broken or ignore everything outside the "main" module

Conversely, if a plugin needs to process many modules together (for example aggregated Javadoc), the current Gradle and Maven layout makes the task difficult for them. So I'm not sure that any of the two approaches is fundamentally more difficult than the other. They put the difficulty in different places.
Why Gradle sub-projects are not equivalent
As far as I know, Gradle projects, like Maven projects, are acyclic graphs. If module C depends on module B which itself depends on module A, it works fine. But there is no way for module A to reference module B or C except by Java reflection. By contrast, Module Source Hierarchy allows a limited form of cyclic graphs:

In exports statements of module-info files.
In opens statements of module-info files.
In @see, @link and @linkplain Javadoc tags.

For example, module B can have the following module-info file:
module B {
    requires A;                          // Module A is a dependency of B.
    exports com.foo.api;                 // Public API exported to everyone.
    exports com.foo.internal to A, C;    // Private API exported only to modules A and C.
}

In the above, A is a dependency of B, while C is a dependant of B. The reference to A is no problem with Gradle sub-projects. However the reference to C is a problem. As far as I know, there is no way to make the Java compiler aware of the existence of module C without Module Source Hierarchy, because trying to do that with Gradle projects would create a cyclic graphs. By contrast, with Module Source Hierarchy, javac manages those cycles as well as it manages cycles between classes or cycles between methods. The same issue applies to opens statements as well. If the -Xdoclint option is passed to javac, then the same issue applies also to @see and similar Javadoc tags.
I presume that Oracle's developers were aware of the problem for build tools, because references to dependants like C in exports and opens statements causes javac to emits only warnings instead of a fatal errors as it usually does for unknown symbols. However in medium-sized projects, we quickly get hundreds of warnings.
The question
Does Gradle wants to allow developers to resolve those javac warnings? If yes, then I'm not aware of any way other than supporting Module Source Hierarchy.

I believe that this issue has been closed on the basis of a misunderstanding of Module Source Hierarchy, maybe because I mixed unnecessary things in my attempt to explain (in particular changes of src/main/java layout convention). To demonstrate above reply, I created a very small project showing the issue. The project contains 3 modules named a, b and c where a is a dependency of b, and b is a dependency of c. The source files are organized as classical Gradle projects. For example the build.gradle file of module b is simply as below (note that there is no change in source directory layout):
apply plugin: 'java'
description = 'Module B'
dependencies {
    implementation(project(":a"))
}

The module-info.java file of module b is as discussed in above comment:
module b {
    requires a;
    exports b.api;                  // Package accessible by everyone.
    exports b.internal to a, c;     // Package accessible only by selected modules.
}

Forward references like c above are allowed in exports, opens and Javadoc tags. Actually, if we ignore Java reflection, useful exports statements can only contain forward references. Exporting to module a is useless (except if module a does reflection) because a cannot requires module b. Forward references are allowed by necessity in exports statements, even at the cost of cyclic graphs, but are not allowed in requires statements for example.
Test with classical Gradle module
Run the following commands in a Unix shell (tested with Gradle 8.3 and Java 21):
git clone https://github.com/Geomatys/MavenModulepathBug cyclic-graph
cd cyclic-graph
git checkout cyclic-graph/gradle-modules
gradle compileJava

The compilation succeed, but with the following warning:
> Task :b:compileJava
b/src/main/java/module-info.java:4: warning: [module] module not found: c
    exports b.internal to a, c;     // Package accessible only by selected modules.
                             ^
1 warning

Test with Javadoc check enabled
The following commands test a case identical to the previous test, with only the -Xdoclint compiler option added in module a:
gradle clean
git checkout cyclic-graph/gradle-modules-doclint
gradle compileJava

Now, the compilation fails with a fatal error:
> Task :a:compileJava FAILED
a/src/main/java/a/api/A.java:4: error: reference not found
 * @see c.api.C
^
1 error

Test with Module Source Hierarchy
The following commands change absolutely nothing to Java source code and directory hierarchy. This test demonstrates that this issue is not about the src/main/java hierarchy convention. The tag only changes Gradle configuration. It removes all build.gradle files in modules a, b, c and replaces them by a single build.gradle file in the root directory. The -Xdoclint compiler option is still present. This build configuration gives all modules together to the Java compiler, in one single call to javac, and lets the compiler manages inter-dependencies between modules.
gradle clean
git checkout cyclic-graph/module-source-hierarchy
gradle compileJava

All Java compiler warnings and errors are gone!

No more "module not found: c" warning!
No more "reference not found: see c.api.C" error!

We can rely on compile-time checks of forward references. This safety is the reason why Module Source Hierarchy is needed. I'm not aware of any way to resolve those compiler warnings and errors with classical Gradle modules. If some way is nevertheless possible, I suspect it may be more convolved than relying on compiler build-in support.
So @big-guy, the question is: can you compile this cyclic-graph project without compiler warning using Gradle modules? (without disabling warning of course).

Ping? I would like to check if this issue was closed by misunderstanding. The argument was that we can do the same thing with Gradle modules, but this is not exactly true as far as I know. To check, if the answer to any of the following question is "yes", then this issue can really be closed:

Can you compile this very simple test case with Gradle modules without Java compiler warnings?
If no, is it Gradle's decision to not provide support for developers wanting to build modular projects with those warnings resolved?

Reopening this case for re-triage, as there was a misunderstanding. Discussed it with @desruisseaux at Community over Code. See the test case above

To further comment on this issue - in my opinion, it should be somehow supported with Gradle's multi-project builds as well.
If you put everything in a single source set (just as test case suggests) - then all of your modules will have same set of dependencies. This is not significant when building standalone JAR files, but is very significant when you intend to publish these to Maven.

Hi @desruisseaux,
We agree that there's something missing here. We'd like Gradle to support JPMS more fully.
Our goal wouldn't be to support module source hierarchy specifically, but we want to solve how Gradle can model circular dependencies  in a module.  We need to do this investigation.  Part of the problem is that modules and projects do not align well when there are circular module dependencies and building multiple modules (within one project) does not align with how Gradle would publish and consume multiple jars.
I don't know when we will be able to get to this, certainly not before Gradle 9.0.

If you put everything in a single source set (just as test case suggests) - then all of your modules will have same set of dependencies.

Not necessarily. If deploying to Maven Central, we need to generate pom.xml file for each module anyway. The code generating those pom.xml files can filter the dependencies for including only the ones declared in module-info. This is exactly what our custom Gradle plugin for Apache SIS does.
In Maven terminology, a project using Module Source Hierarchy would typically have no <dependencies> section (except for test dependencies), but only a <dependencyManagement> section. The <dependencies> section is generated for each module as the intersection of <dependencyManagement> with module-info.


Next feature ? Clean the terminal on each runtime

Hey  👋
So this is a not an issue but maybe I thought about cleaning the terminal to keep it clean on each runtime ?
Thanks for your work, it's great  🙃

@luctst You got it! You can download new version with this feature implemented. (:


Fixes - recv_window and replace tabs in configs

receive_window was always set to 5000. If the user supplies a valid value between 5000 and 60000, it will now be used.
came up yesterday in the evening: some users had literal tabs in their config.json, this is not supported by the yaml parser. tabs will be replaces with spaces now to address this

Type of change
Please make your selection.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] This change requires a new dependency
[ ] Code Maintainability / comments
[ ] Code Refactoring / future-proofing

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added pytest unit tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have checked my code and corrected any misspellings

Reporter confirmed the fix is working.

Thanks for the update


Automate notification of new root to keyholders

Description

And re-signing on any config changes.
Notify keyholders after the action runs.

Done in https://github.com/sigstore/root-signing/commit/fbd45af5663f4518c8ba9564e91ba688a21ae2ce
Will need to figure out how to notify keyholders. Changing title.

I believe this is handled by signing events now naming the signers who need to sign (whether people read github notifications may be another matter though)


confirmPayment method doesnot work, got error There was an unexpected error -- try again in a few seconds

I need to create payment method id for client but never success and always got below error.
React native version
react-native-cli: 2.0.1
react-native: 0.62.0
iOS : 14.0
Error: There was an unexpected error -- try again in a few seconds
    at Object.promiseMethodWrapper [as confirmPayment] (NativeModules.js:103)
    at Stripe.confirmPayment (index.js:16)
    at AddCard.handlePayment (AddCard.js:41)
    at Object.onPress (AddCard.js:100)
    at onPress (TouchableHighlight.js:209)
    at Pressability._performTransitionSideEffects (Pressability.js:655)
    at Pressability._receiveSignal (Pressability.js:589)
    at onResponderRelease (Pressability.js:499)
    at Object.invokeGuardedCallbackImpl (ReactNativeRenderer-dev.js:286)
    at invokeGuardedCallback (ReactNativeRenderer-dev.js:497)

Please help us for above error

Hi,
Same issue in iOS, works fine in android
Any solution??

Any solution for this? Ran into the same issue. Why is this closed?

@katiachumakova I need to use confirmSetupIntent method for charge in future where in the library they used confirmIntent so we used this library and modify by our way. That's why i closed this issue


[FLINK-19764] Add More Metrics to TaskManager in Web UI

What is the purpose of the change
ref https://issues.apache.org/jira/browse/FLINK-19764
Brief change log
Add More Metrics to TaskManager in Web UI
Verifying this change

visit the TM metrics page
verify if the TM metrics match the document https://ci.apache.org/projects/flink/flink-docs-release-1.11/ops/memory/mem_setup_tm.html

before:

after:

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (yes)
If yes, how is the feature documented? (no needed)

Hi @XComp
fixed, thanks for your comments

@vthinkxie confirmed in a private chat that the PR can be merged into master. @rmetzger it would be good if you could take over.

Thanks. I will check out the PR myself and then maybe merge it.

I'll merge the change. It works in Safari, Firefox and Chrome.


Source code for the first example

I'm talking about this: https://raw.githubusercontent.com/Gil2015/tools_file/master/img/react-native-table-component/example.jpg
Could someone share source code for this please?

The structure is the same as in the picture.

    <Row />
    <Rows />

    <TableWrapper>
        <Cell />
        <Cell />
        <Cell />
        <Cell />
    </TableWrapper>
    <TableWrapper>
        <Col />
        <Cols />
    </TableWrapper>


Add content pages navigation test

This corresponds with https://github.com/alphagov/cdn-configs/pull/55
https://trello.com/c/yLYk4BtF/34-set-up-ab-test-in-fastly

Thanks 👍


[eslint] Enforce operator-linebreak and no-multiple-empty-lines

I think this is safe to merge. :+1: Let's do it :sunglasses:

@alitaheri @oliviertassinari I think we should use this:
http://eslint.org/docs/rules/no-nested-ternary.html

Holding for PR catch-up.

I think that it's safe to merge this PR. We haven't seen any conflict in a week, while merging many PRs.

@oliviertassinari I'm going to re-run the build and will merge if all is :+1:

@mbrookes I can't see what failed in that travis build, can you?

@oliviertassinari @mbrookes Found the errors. I think the GUI travis output is screwed up. When I click "raw log" I see the errors coming up:

[00:26:38] Using gulpfile ~/build/callemall/material-ui/gulpfile.js
[00:26:38] Starting 'eslint:src'...
[00:26:48]
src/Stepper/HorizontalStep.jsx
  115:8  error  '?' should be placed at the end of the line  operator-linebreak
  116:8  error  ':' should be placed at the end of the line  operator-linebreak
  117:8  error  '?' should be placed at the end of the line  operator-linebreak
  118:8  error  ':' should be placed at the end of the line  operator-linebreak

src/Stepper/Stepper.jsx
  123:9  error  '&&' should be placed at the end of the line  operator-linebreak

src/Stepper/VerticalStep.jsx
  205:8  error  '?' should be placed at the end of the line  operator-linebreak
  206:8  error  ':' should be placed at the end of the line  operator-linebreak
  207:8  error  '?' should be placed at the end of the line  operator-linebreak
  208:8  error  ':' should be placed at the end of the line  operator-linebreak

âœ– 9 problems (9 errors, 0 warnings)

events.js:154
      throw er; // Unhandled 'error' event
      ^
ESLintError: Failed with 9 errors

Ok, travis GUI output was screwed up at first (seemed cached from the initial build actually). I deleted my posts regarding it and the raw log. The errors are visible in the gui now.
@oliviertassinari can you fix these up quickly:
src/Stepper/HorizontalStep.jsx
  115:8  error  '?' should be placed at the end of the line  operator-linebreak
  116:8  error  ':' should be placed at the end of the line  operator-linebreak
  117:8  error  '?' should be placed at the end of the line  operator-linebreak
  118:8  error  ':' should be placed at the end of the line  operator-linebreak
src/Stepper/Stepper.jsx
  123:9  error  '&&' should be placed at the end of the line  operator-linebreak
src/Stepper/VerticalStep.jsx
  205:8  error  '?' should be placed at the end of the line  operator-linebreak
  206:8  error  ':' should be placed at the end of the line  operator-linebreak
  207:8  error  '?' should be placed at the end of the line  operator-linebreak
  208:8  error  ':' should be placed at the end of the line  operator-linebreak


How do I populate an array field?

Hello.
So there are not examples of how I can populate an array field from a different schema.  For example;
Country Model;
const CountrySchema = new Schema(
  {
    _id: {
      type: "object",
      value: { type: "Buffer" },
      default: () => MUUID.v4(),
    },
    name: {
      type: String,
      unique: true,
      required: true,
    },
  }
 )

Festival Model;
const FestivalSchema = new Schema(
  {
    _id: {
      type: "object",
      value: { type: "Buffer" },
      default: () => MUUID.v4(),
    },
    name: {
      type: String,
      unique: true,
      required: true,
    },
    allowedCountries: [
      {
        type: Schema.Types.Mixed, // "object" does not work
        ref: config.mongodb.collections.cards.country,
        required: true,
      },
    ],
  }
)

"object" as a type does not work in the allowedCountries array. It gives the following error;
TypeError: Invalid schema configuration: `object` is not a valid type within the array `allowedCountries`.See http://bit.ly/mongoose-schematypes for a list of valid schema types.

I am able to save a festival with an array of UUIDs, but when fetching i can not seem to be able to populate because it always returns an empty array.
Here is the command;
const brand = await FestivalModel
      .findOne({ _id: MUUID.from(festivalId) })
      .populate('allowedCountries', { id: 1, name: 1, slug: 1 })
      .exec();

I believe I'm getting something wrong in my approach. Please help.

Fixed it. All I had to do was to apply MUUID.from to the content of the array I  was passing into allowedCountries


Issue 360 leak handler

Fixing memory leak on VlcMediaPlayer->GetMedia()
Adding a sample for multiple players tests. With this sample project I have intensively test the create and dispose of players so this #346 might be already fixed.

All commits squashed in last commit:
Commit

Hi.
Everything done and comments applied.
Is there anything pending to complete the pull?

Yes, time for me to review it :smile: I don't think I will have much time until monday

Squashed and merged manually thanks!
I made a few changes to the sample projects used the libvlc nuget package and used a publicly available URL by default, so that anyone can test.


Stronger wording and simpler design on the banner

Before:

After:

Something's wrong with the arrow positioning:

Text on top is also slightly too big. Mac, 13 inches.

@vadimdemedes damn, seeing this now too in Safari. It looked perfect in Chrome :( Will need adjustments then.

@vadimdemedes looks like the truncated right is a problem with Safari SVG embeds through IMG. If you open it directly or embed as object, it works correctly. 🤷♂


the debug cannot start up the externalConsole

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:1.59.0
OS Version:Windows 8.1

Steps to Reproduce:
1.when i was debugging a c programmer, only a few minutes before it can work well, i didn't change any settings and the launch.json file sets the externalConsole true, but it cannot start up the externalConsole.
2.after lots of tries, i reinstall the vscode, but it still cannot debug, but the programer still can be compiled & run.
3.the detail information about the error is in the following pictures. when i start debugging, the first picture appear, we can see the debug bar, but after one second, the second picture come, the debug bar disappear.

/extCpp


feat: Using Parameters to Define Build/Test Jobs Platforms and Python Versions

Allows configuring what platforms and Python versions the building and testing set of jobs take place on. By default it remains Python 3.5 - 3.7, and Ubuntu, MacOS and Windows.
This enables disabling builds for unsupported platforms/Python versions, as was needed in https://github.com/tomtom-international/ebr-trackerbot/pull/4 since it cannot support Python 3.5.

Please update as well the readme and describe this feature

Please update as well the readme and describe this feature

Ok, updated

Nice


Deprecate .NET 7, Node.js 16 and Python 3.8 runtime options

Add deprecated tag to the .NET 7, Node.js 16 and Python 3.8 runtime options.

This PR has just been updated to also deprecate Python 3.8 @aarondfrancis


spl-token create-token No such file or directory (os error 2)

Sounds like you need to install the spl-token CLI binary. Please direct questions to the developer support channel in Solana's Discord!


Copy function for Jupyter notebook plot viewer

When creating a plot in a Jupyter notebook, it'd be nice to be able to right click and copy an image, either straight from the notebook or from the viewer tab that pops up when you click the little graph icon.

thanks for the suggestion

Looks like there is already an issue in core for this, which is where it would need to be implemented: https://github.com/microsoft/vscode/issues/129880


Possible reasons why a table is not attached to massive?

Any reason why this would work
	db.run("select * from crap", function(err, res) {
		return callback(null, res);
	});

but this returns Cannot read property 'crap' of undefined
	db.public.crap.insert(userObject, function(err, res) {
		console.log(err);
		return callback(null, res);
	});

It's as if massive is skipping this crap table. The table was created like
	CREATE TABLE IF NOT EXISTS public.crap (
		crap_id SERIAL,
		firstName text NOT NULL,
		lastName text NOT NULL,
		email text UNIQUE NOT NULL
	);

I'm sure it's something stupid on my end but I'm pulling my hair out

I tried logging what tables are connected to massive
	var tables = db.tables.map(function(table) {
		return table.name;
	});
	console.log(tables);

and I get
web_1  | [nodemon] restarting due to changes...
web_1  | [nodemon] starting `node ./bin/www`
web_1  | DB connected
web_1  | Express server listening on port: 3000
[nodemon] clean exit - waiting for changes before restart
web_1  | [ 'districts',
web_1  |   'migrations',
web_1  |   'roles',
web_1  |   'schools',
web_1  |   'session',
web_1  |   'user_roles',
web_1  |   'users' ]
web_1  | Cannot read property 'crap' of undefined
web_1  | GET /crap 500 22.723 ms - 1143

Why isn't crap in the table list, it's so odd. I can select & insert fine using pgAdmin

Can you check to see what happens of you remove the public like so:
    db.crap.insert(userObject, function(err, res) {
        console.log(err);
        return callback(null, res);
    });

When Massive loads the tables, items in the public schema are bolted directly onto the Massive instance itself, without the public qualifier. I suspect that is the issue, but if not, let us know.

crap also needs to have a primary key and be visible to the user you're connecting with.

@xivSolutions and @dmfay , thank you
The combined solution of removing public AND adding a primary key made the table show up.
	CREATE TABLE IF NOT EXISTS public.crap (
		crap_id SERIAL,
		firstName text NOT NULL,
		lastName text NOT NULL,
		email text UNIQUE NOT NULL,
		PRIMARY KEY(crap_id)
	);

This should probably be added to the documentation somewhere.. but basically if tables aren't detected by massive, devs need make sure the table has a primary key

But...who would define a database table without a primary key? :trollface:
Kidding :-) Glad you got it resolved!

yea I actually made a crap table just to test it and figured, ohh im testing who needs a key anyhow. Big mistake 💩


Use flexbox

https://philipwalton.github.io/solved-by-flexbox/demos/grids/

+1 This is really nice feature.

I'm releasing a simple css grid system with flexbox. It supports both columns and rows.
It's only an idea of  I would in picnic css as grid system. It included a simple sidebar layout too.
https://bitbucket.org/hadokee/flexgrid

Hi @hadokee , unfortunately you forgot to add a License so I cannot include it in Picnic (I haven't even read it just in case). Would you mind adding the license for it, please?
Another take:

http://gridlex.devlint.fr/

Hi Francisco it was only a try. Probably gridlex is better coded and documented :)

Also this one: https://github.com/IonicaBizau/gridly

I created one based on flexbox, but I'm still not happy. There is a tradeoff to choose:
Margins
Add a negative margin to the wrapper and a margin to the children, then do overflow-x: hidden; so they don't show up on the right. However this cuts box-shadow and any other thing that people using the library might have.
The advantage is that then the client-code is really clean (unless you want to change the gutter) so it's flexible and intuitive. This is really similar implementation to the one currently with Picnic. Example for client code:
.grid > *:first-child {
  width: 100%;
}

Space between
Using flexbox and justify-content: space-between; we can get pretty close. However, this yields a nightmare of numbers to maintain (for the developer using picnic) like max-width: calc(50% - #{$gutter/2});.
Then when there's a N number of hanging items, where N > 1 and N < columns, the space is gotten in the middle also, which is really odd. See issue (or google). So the solution is even uglier:
.grid.three > *:last-child:nth-child(3n+2) {
  margin-right: calc(33.3333% + #{$gutter/4});
  //max-width: calc(100% * 2 / 3 - #{$gutter/3});
}

I am not sure if using flexbox and re-implementing the whole grid system is worth it here. Maybe witha light implementation of Solved with Flexbox is enough, since the state of the technology is not there yet (see next point).
Future
In the far, far away future this might be interesting (right now not even firefox/chrome support it). I hope this time they get it right:
https://css-tricks.com/almanac/properties/c/columns/

No flexbox, I'll switch it also to floats since they are much more flexible than table


ManagedByFilter doesn't appear to be changeable.

[Enter feedback here]
This document describes how to modify EnabledEmailAddressTemplates and ManagedByFilter, but the sample appears to be incorrect.
Also, Set-EmailAddressPolicy does not have the -ManagedByFilter option.
Sample
Set-EmailAddressPolicy -Name StudentsGroups -EnabledEmailAddressTemplates<EMAIL_ADDRESS>"smtp:students.contoso.com" ManagedByFilter {Department -eq 'Students'} -Priority 2

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

ID: 54783558-94f0-24ad-0fa3-1461a608fd10
Version Independent ID: 53ebf483-a8ef-e242-9a2c-c285bbce65da
Content: Choose the domain to use when creating Microsoft 365 groups
Content Source: microsoft-365/solutions/choose-domain-to-create-groups.md
Service: o365-solutions
GitHub Login: @MikePlumleyMSFT
Microsoft Alias: mikeplum

@tokitamo-ms Thank you for your feedback. We have made changes to the document via pR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/10971
Once the author approves, the changes will be live.
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @tokitamo-ms Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

@yogkumgit @msbemba Thank you for your work.


V1.1 tag analyzer links

add entities links
feat: v1.1-tag-analyzer-links - filter entities by selected tag key/value
display entities with missing tags
in Tag Analyzer tab change selected tag's row background color
change the selected row on the right if different tag selected from dropdown on the left
entity display options - show entities based on options selected on top
add header info to Entity tab to indicate what is displayed
change selected row's background color
performance improvement

fix: add fix for updating tagHierarchy tagKeys when tags are added or removed in the policy


cannot install lumi package

cram/cram_io.c:53:10: fatal error: bzlib.h: No such file or directory
53 | #include <bzlib.h>
|          ^~~~~~~~~
compilation terminated.
make[1]: *** [Makefile.Rhtslib:135: cram/cram_io.o] Error 1
make[1]: Leaving directory '/tmp/RtmpUB64Er/R.INSTALL5fa55ea1a1b/Rhtslib/src/htslib-1.15.1'
make: *** [Makevars.common:22: htslib] Error 2
ERROR: compilation failed for package ‘Rhtslib’
Is there anynoe can help me with it?

Perhaps you need to install libbz2-dev like sudo apt install libbz2-dev?
I recommend that you ask questions in the following repositories
https://github.com/Bioconductor/Rhtslib


Concatenate items added via multiple calls to precache()

I've come across situations in which I want to call shed.precache() multiple times from different scripts, and currently that will cause the precache list to be overwritten each time. Instead, the change in this PR will concatenate to the existing list each time it's called.
(I am not sure where all those changes to dist/shed.js came from—perhaps I built it with a more recent version of some of the npm dependencies? Do those look okay to you, @wibblymat?)

:+1: Yeah, looks like the other changes are due to an update in the cache polyfill.


Create a new form for registrations without needing a date of birth.

This would require a new Form class (perhaps BaseForm?)
It has 3 fields: username, password, next
The existing RegistrationForm can subclass the BaseForm and add the date of birth field for backwards compatibility.

@smn @miltontony Is this right?

@smn @miltontony I think like that I can update the date of birth anywhere else as well, am I right?

I'm not entirely sure having a separate view (or URL) is a good idea. If people know about this (and they will, it's all open-source) then they'll be able to type in that URL manually and register without a date of birth even though it may be a requirement for the site.
I'm trying to think of ways of making this work differently.

Resolved in PR #9


ARTEMIS-358 topic mistakenly removed with sub

The problem here is that the management notification listener was mistakenly
removing the topic itself instead of just the non-durable subscription. In
general I can't see why StompProtocolManager even needs to keep track of the
destinations when the broker already does that. As far as I can tell it is
redundant and it's clearly error-prone. Therefore I'm removing the destination
tracking from StompProtocolManager altogether.

I think @howardgao should take a look at this before it's merged.

Not sure why this was reported as failed.  Everything looks good to me: https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/962/console.


Add css code which is present in html to style.css

Can I work on this?

@sooraj-gk yes assigning it to you.
Happy coding

i am first timer... what we exactly need to do? i can help with html and css

Add css code which is present in html to style.css #12

Can i work on this?


fix: remove unused imports to fix build on jitpack.io

the worse line here was: import sun.awt.image.MultiResolutionToolkitImage;
Build error log:
https://jitpack.io/com/github/FEOMedia/artemis-odb-orion/cc24bdc77d/build.log

hey there :)
sorry for neglecting/forgetting about this.
:cookie:


Fixes  #6 - Packages with a slash

Now packages with a slash like @company/my-lib are unpacked correctly.

Released in https://github.com/single-spa/self-hosted-shared-dependencies/releases/tag/v1.0.4


June 2022 update

Module: 00
Lab/Demo: 00
Fixes # .
Changes proposed in this pull request:

Updating labs to reflect new 1-day version of the course


Add support for uncertain date formats (ISO 8601-2:2019)

What's your idea for a cool feature that would help you use OHM better.
It would be great to have support for uncertain dates and time ranges.
This uncertainty could accommodate for vague or unknown time starts, approximate dates, etc.
More details can be found at: https://www.iso.org/standard/70908.html
This feature will have significant impacts across OHM, to include data storage, rendering rules, and time slider behavior.
Current workarounds
None - the site currently requires specific, unqualified dates in the old 8601 format.

handling date ranges
Based on discussion in Discord with @padi, we have a feasible way forward here to at least manage these in the near term:

as a first approximation, i think it's ok if the server returns the latest possible start date, i.e. when we are sure the item in question exists

So given an input like DATE..DATE then we would:

split on ..
If start_date take the second item to show it when we have highest confidence the item exists
If end_date take the first item to be conservative about when it's gone.

handling decades
For decades with YYYYs we would:

Drop the s
If start_date assume 1950-01-01 and convert to decimal date
If end_date assume 1959-12-31  and convert to decimal date

why is your suggested behavior for decades distinct from other ranges?

Ah, maybe you'd prefer the more conservative approach of

If start_date assume 1959-12-31 and convert to decimal date
If end_date assume 1950-01-01 and convert to decimal date

I am naturally glib and prefer to see more data with less certainty than vice versa. But very open to the inverse!

I suggested the conservative approach because I don't believe before 1850 should appear at the beginning of time. And then I thought the approach should be consistent, but it could also make sense to treat it differently in the case when both the beginning and the end of a range are known.

Where are we on this, given recent discussions about parsers, etc.?
@danrademacher @rwelty1889 @geohacker @batpad
I'm getting the sense that this may not be as tricky to implement across the stack (e.g. core db, tile filters, stylesheets, etc.) as I had thought. Am I wrong?

Where are we on this, given recent discussions about parsers, etc.?
@danrademacher @rwelty1889 @geohacker @batpad
I'm getting the sense that this may not be as tricky to implement across the stack (e.g. core db, tile filters, stylesheets, etc.) as I had thought. Am I wrong?

A workaround I think might work (even if a workaround is lame) is [foo]_date.edtf =~1976

Unfortunately, I think it might be even more complex if we push the responsibility for parsing EDTF onto the client. The vector tiles currently encode start_date and end_date as decimal numbers to get around the fact that the Mapbox Style Specification’s expression language lacks some important string operations, such as regular expression matching (mapbox/mapbox-gl-js#4089) and string splitting (maplibre/maplibre-gl-js#2064). If the tiles contain EDTF verbatim, the frontend would need to use a fork of GL JS that provides a hook so that the website can extend it with an EDTF-parsing operator. That operator could be implemented using EDTF.js, but a fork of GL JS might come with some unwanted maintenance overhead.
The alternative of parsing within PostgresQL might be feasible. If we aren’t comfortable rolling our own parser in PL/pgSQL, perhaps ohm-deploy could define a Python function that uses python-edtf to do the parsing. Or a Rust function that uses edtf-rs if a Rust driver is installed, etc.


[zoomus] Add new extractor

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Bug fix
[ ] Improvement
[x] New extractor
[ ] New feature

Description of your pull request and other information
This is an extractor for Zoom.us recordings. Example link taken from here: https://github.com/ytdl-org/youtube-dl/issues/16597 .
Other related Issues: https://github.com/ytdl-org/youtube-dl/issues/23573 , https://github.com/ytdl-org/youtube-dl/issues/24643 , https://github.com/ytdl-org/youtube-dl/issues/16597
I don't know how to get the tests working, somehow the md5 is None, even though the file is being downloaded when using --test manually.

Read coding conventions.

@d0u9 I have adjusted the regexes to ignore non important fields and some other code convention stuff.

@Romern Does this PR avoid you having to open 2 separate tabs to dig out the request headers like I outlined here (#23573)?

@sheedy You simply drop the https://zoom.us/recording/play/* link into youtube-dl and add a password using if required.

Works well for me. Thanks @Romern

Hello @Romern,
cloning your repository and running with developer suggestion with python -m youtube_dl but it does not find the right extractor.
J-58_: Requesting header
WARNING: Falling back on generic information extractor.

am I doing something incorrectly? I can help to debug or in the extractor itself.

@o1dnik It seems like your link does not match the pattern, could you post it? If its sensitive, you can censor the id.

I'm not sure, but it should be publicly available. This is a TheEconomist magazine video recording
https://economist.zoom.us/rec/play/7JV4Ibuqrjg3S9XEtgSDBvYoW9XsfKqs1HIfq_oEmRq0VnlSNVChZ7AVNOKcIcCsGRw-mFPuwGMJ-58_

@o1dnik it should now work for arbitrary long ids.

@Romern I confirm, works like charming! 👍

@Romern Tested this with password and it works well.
@kcrkor thoughts on merging?

@karbassi Looks good to me.

@dstftw thoughts on merging?

Continued here: https://github.com/ytdl-org/youtube-dl/pull/27002


generate csv: do not generate a package manifest for bundles

Description of the change:

cmd/operator-sdk/generate: skip package manifest generation if --make-manifests=true (the default)

Motivation for the change: package manifests are not part of bundles
/kind bug

/cherry-pick v0.17.x


Add sample/stack query filter to registry query API

This item is a spin-off item from #403.
Given that our current repo does not support sample vs stack definition yet (pending the work for #279), our existing query API only returns a list of stacks. We can provide a temporary implementation to return a static list of samples, e.g. https://github.com/redhat-developer/devfile-sample, for the time being. The list can be a file stored under https://registry.devfile.io/ for the time being.
When we have done #279, we can then modify the implementation to do a life query on the registry. When querying the list of samples, ideally, we should probably combine the list of samples and the list of starters and return all of them as samples.
For the query syntax, this item covers only the sample/stack filtering:
type:sample (the type of resources that needs to match, the initial supported values are sample and stack)

All the PRs related to this issue are merged, the issue is done.


docs: update badges in readme

Codecov Report

Merging #59 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop      #59   +/-   ##
========================================
  Coverage    99.30%   99.30%
========================================
  Files           22       22
  Lines          723      723
  Branches       163      163
========================================
  Hits           718      718
  Misses           5        5


spawn pty failed: fork/exec /usr/bin/telnet: invalid argument

Using wsl1 (Ubuntu) on windows 10N, I get the following:
[cnd:~/Downloads]$ trzsz telnet <IP_ADDRESS>
spawn pty failed: fork/exec /usr/bin/telnet: invalid argument

[cnd:~/Downloads]$ telnet <IP_ADDRESS>
Trying <IP_ADDRESS>...
Connected to <IP_ADDRESS>.
Escape character is '^]'.
Password:
Welcome to esp32-cam-cb - esp32 Micropython v1.24.0-preview.98.g4d16a9cce on 2024-07-05 on LOLIN_C3_MINI with ESP32-C3FH4

>>>
telnet> q
Connection closed.

[cnd:~/Downloads]$

Not sure what that means, but telnet works fine by itself I know.
The telnet protocol is quite simple - should be possible to let trzsz emulate that without needing to use any external program if that helps?
The problem seems to be with trzsz code, not the program it needs to run - same error no matter what program I try to run:
[cnd:~/Downloads]$ trzsz /usr/bin/perl ~/Downloads/mcu_serial.pl -port $PORT -setdtr -setrts -norts -nodtr
spawn pty failed: fork/exec /usr/bin/perl: invalid argument

[cnd:~/Downloads]$

Which version of trzsz? Is it the Linux version or the Windows version?

trzsz in WSL

trzsz ( Windows version ) + telnet ( Windows version )

The upload speed may be slow, but the download speed should be normal.
Check https://github.com/microsoft/terminal/issues/13594

trzsz ( Linux version ) + telnet ( Windows or Linux version )

You also need to install zenity in WSL.
Older versions of WSL may not support the zenity to open the file dialog.
You may be able to select files only in WSL but not in Windows.

trzsz ( Windows version ) + telnet ( Linux version )

Not support.


go/doc: add fields to Example struct to indicate type/method/suffix

The doc package currently provides:
func Examples(files ...*ast.File) []*Example

Given a set of source files, this only parses out the examples as a flat list.
However, the testing package documents a syntax of how to associate examples with:

A package (e.g., Example or Example_suffix)
A function (e.g., ExampleF or ExampleF_suffix)
A type (e.g., ExampleT or ExampleT_suffix)
A method (e.g., ExampleT_M or ExampleT_M_suffix)

As the number of tools that provide godoc-like functionality increases, the manual logic to parse these example names and associate it with the appropriate top-level declaration is somewhat tedious and easy to get wrong.
Given that this syntax is documented, I propose that the doc package provide first-class support for doing this association. The additional functionality is as follows:

New uses the ast.Package.Files input to produce an internal []Example.
An Examples []Example field is added to the Package, Type, and Func types. They are populated as appropriate according to what the relevant examples are associated with.
Examples that do not follow the example syntax or reference an non-existent declaration could be either ignored or just associated with the entire package.

\cc @griesemer

Some evidence that this is an issue: the two most common godoc implementations don't handle this the same way:

golang/tools/godoc: The stripExampleSuffix function assumes that the suffix may not contain another '_' character.
golang/gddo/doc: The builder.getExamples method assumes that so long as there is a prefix match and the suffix starts with an uppercase, it doesn't care what the rest of the suffix looks like.

Arguably the gddo approach is more correct. The point is that the divergence in behavior is a why the standard library should do this association for the user.

Why do you want to modify go/doc? Is it just so godoc and gddo can share something?
Also we need not change the accessor. We could provide a helper that just takes the string name and returns info about the parsed form of that string name.

Why do you want to modify go/doc?

To have a canonical implementation of the syntax laid on in the testing package. As it currently stands, every godoc-like tool does something slightly different.

Is it just so godoc and gddo can share something?

and additional godoc-like tools that are starting to spring up.

Also we need not change the accessor. We could provide a helper that just takes the string name and returns info about the parsed form of that string name.

I'm not sure what you mean by that. Are you saying we shouldn't alter the doc.Package struct? Modifying the struct makes it easier to pass doc.Package to html/template or text/template. IMO, the helper functions are harder to work with.

I don't think we expect go/doc structs in their current form to be guaranteed to be helpful for any use of template.
I do think that something like
func ParseExampleName(name string) ExampleInfo

// For "ExampleFoo_M_suffix"
type ExampleInfo struct {
    Name string // "Foo"
    Method string // "M"
    Suffix string // "suffix"
}

could be useful for godoc and cmd/doc and other things to share. That would still give you a canonical implementation of the syntax. Or add a few fields to the doc.Example struct:
Name string // "ExampleFoo_M_suffix" (already in struct)
Base string // "Foo"
Method string // "M"
Suffix string // "suffix"

?

That is not sufficient. You need the list of top-level identifiers to disambiguate whether Foo_Bar_baz refers to a method named Foo.Bar or a type named Foo_Bar. It is only a stylistic recommendation that most top-level Go identifiers do not have _ in their name. Thus, classifying by _ delimiter alone is insufficient. The aforementioned godoc tools essentially do this logic (but both do it slightly differently such that the worst-case situation where both Foo.Bar and Foo_Bar exists is handled differently; however that case is rare).
Another ambiguity is whether Foo_bar refers to Foo with a suffix of bar or an actual type named Foo_bar. If we were relying on purely lexical parsing, I would not recommend us adding any logic to go/doc at all since this is trivial to perform on your own.

The ambiguity that @dsnet mentions strikes out the ParseExample func, but it seems like the doc.Example field additions are still fine, since they're returned as part of something that looks at the whole package and knows its types and methods.

OK, it sounds like we should add the fields to the Example struct (the second half of my message from March 5).
And maybe also we should provide the Example slice in the overall Package struct instead of having a second call, although there may be some concerns around opening files during doc.New that were previously not opened (*_test.go).
@dsnet and @grisemer, if you both agree about adding the fields to the Example struct, please mark this proposal-accepted.

Ping @dsnet and @griesemer, waiting on your acceptance.

Spoke to @griesemer, adding fields to the doc.Example struct and extracting top-level declarations from the set of input *ast.File SGTM.
This will require some adjustments to how doc.Examples is called as it seems most usages just pass into only the test files (e.g., here).

And maybe also we should provide the Example slice in the overall Package struct instead of having a second call, although there may be some concerns around opening files during doc.New that were previously not opened (*_test.go).

I support this, but can be a future addition.

#27442 was closed as a duplicate of this. I should note that the unified behavior for example parsing may require an update to the documentation in testing. In particular, the documentation states that the suffix must start with a lowercase letter, however both tools/godoc and gddo both a treat a suffix as anything that isn't an uppercase.

I should note that the unified behavior for example parsing may require an update to the documentation in testing. In particular, the documentation states that the suffix must start with a lowercase letter, however both tools/godoc and gddo both a treat a suffix as anything that isn't an uppercase.

There is a go vet check for example suffixes that requires a lower case letter, as documented in testing:
$ go vet
# example.com/p
./p_test.go:5:1: Example_123Suffix has malformed example suffix: 123Suffix

So I think we can safely update godocs to match what's written in testing documentation as well.

Please take the opportunity to relax that restriction. The suffix used here is for human consumption and is not a Go idenfier label. Making it !uppercase rather than lowercase would be much better.

Thanks for feedback @kortschak. I've looked over #27442 for the rationale presented more closely and will take it into account.

I have talked with @dsnet about the status of CL 94855, and he gave me permission to take its code and make the necessary changes to address code review comments and make progress on resolving this issue. I included a note in the commit message that the code is based on his CL.
I have addressed the code review comments I left on the original CL (here and here). We've been testing the code in that CL as part of documentation rendering for the discovery site (#33654), which has allowed me to detect a problem with the API it attempted to implement. From its commit message:

The new behavior is as such:

New inspects the ast.Package.Files input for any test source files.
It generates a list of examples by parsing the test files.

It turned out to be problematic to try to provide test source files to the go/doc package via ast.Package.Files for the following reason. ast.NewPackage take a map of Go files that it expects to belong to a single Go package. However, external tests have a "_test" suffix in the package name. That means doing the following:
files := map[string]*ast.File{...} // all .go files, including test source files
apkg, _ := ast.NewPackage(fset, files, ...)
p := doc.New(apkg, ...)

Will result in ast.NewPackage potentially encountering a file with "_test" suffix in the package name first, and will incorrectly dismiss other Go files as having a mismatching package name.
We've used a workaround like this:
apkg, _ := ast.NewPackage(fset, goFiles, ...)
for name, f := range testGoFiles {
	apkg.Files[name] = f
}
p := doc.New(apkg, ...)

But that does not seem to be a good API, and it requires doc.New to do the work of splitting Go files into test and non-test ones.
I tried to come up with the least bad new API to resolve this problem, and I have created a new CL 204830 that implements it in order to resolve this issue. Review is welcome.


npm run test Error

vue-cli init webpack testing; cd testing; cnpm install; npm run test;
npm ERR! Darwin 16.3.0
npm ERR! argv "/Users/herely/.nvm/versions/node/v6.9.2/bin/node" "/Users/herely/.nvm/versions/node/v6.9.2/bin/npm" "run" "unit"
npm ERR! node v6.9.2
npm ERR! npm  v4.2.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>unit: cross-env BABEL_ENV=test karma start test/unit/karma.conf.js --single-run
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>unit script 'cross-env BABEL_ENV=test karma start test/unit/karma.conf.js --single-run'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the testing package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     cross-env BABEL_ENV=test karma start test/unit/karma.conf.js --single-run
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs testing
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls testing
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/herely/.npm/_logs/2017-02-10T05_51_51_672Z-debug.log
OS: mac osx 10.12.2
node:  6.9.2
npm: 4.2.0
vue-cli: 2.8.1

Seems like you're having an issue with webpack template. Please report it there.


Correction for raw affiliation Glass Mechanics Department, IPR, UMR 6251, University of Rennes 1 , Campus de Beaulieu, 35042 Rennes Cedex, France; Institut Universitaire de France 3 , France

Correction needed for raw affiliation Glass Mechanics Department, IPR, UMR 6251, University of Rennes 1 , Campus de Beaulieu, 35042 Rennes Cedex, France; Institut Universitaire de France 3 , France
raw_affiliation_name: Glass Mechanics Department, IPR, UMR 6251, University of Rennes 1 , Campus de Beaulieu, 35042 Rennes Cedex, France; Institut Universitaire de France 3 , France
new_rors: 015m7wh34;055khg266;022b0h879
previous_rors: 015m7wh34;055khg266
works_examples: W4383342772
contact: 07f6dae3dfe9b06af7f7fd3ced98590e:43aa3045a9352d142215822bdfaec4fb @ univ-rennes.fr

This issue was accepted and ingested by the OpenAlex team on 2024-10-10. The new affiliations should be visible within the next 7 days.


How to provide sonar.projectVersion?

We are migrating from Gitlab to Github. In our old Gitlab config, we used to invoke sonarqube directly from the commandline, which allowed us to read the current version from the Python package's version file and pass it as a parameter to sonarqube like this:
export CI_VERSION=`cat omnilearn/__version__.py | sed 's/__version__ = "\(.*\)"/\1/g'`
sonar-scanner -Dsonar.projectVersion=${CI_VERSION}

How can we achieve something similar with the sonar-scanner-action?

This should be possible with the action available from sonarsource: https://github.com/SonarSource/sonarqube-scan-action


camel-jta support

This component is required by https://github.com/apache/camel-quarkus/issues/1197, and it could be included in the camel 3.4.0

please assign this issue to me as we have upgrade to camel 3.4.0


Toggleable WireGuard group interface?

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
[x] When the request is meant for an existing plugin, I've added its name to the title.
Is your feature request related to a problem? Please describe.
Should we add the ability to disable/remove the default WireGuard group interface? What's everyone thoughts?
Currently now you can create your own group interfaces in recent versions of OPNsense, I personally think having this default WireGuard group confuses users. which the plugin creates. As they think the interface group is the WireGuard interface but of course its all the WireGuard interfaces, which causes confusion and then wonder why there's a rule page called WireGuard but their interface they assigned is called MyRoadWarrior.
Thoughts?
Describe the solution you'd like
Toggle box or removal of the WireGuard group interface in the plugin.
Describe alternatives you've considered
Ignoring it which is fine for me but I'm thinking about making things more easier for users to understand.
Additional context

^ Group Interface

https://github.com/opnsense/plugins/commit/891cb2a1d0928c9aeee9fe43cd24b4163af35475 - Commit where group interface got added from the looks of it.

I'm not sure what the problem is, it's the same behavior like with OpenVPN and IPsec. What should it be different here?

It's not a problem problem, but having the group interfaces there by default for when people are setting up VPNs leads too confusion for new users of OPNsense. IPsec one may make sense, as it works differently to OpenVPN and WireGuard.People also get confused with OpenVPN group interface when creating VPN clients or servers. You don't hear much about IPsec one due to people usually sticking to OpenVPN and WireGuard it seems when they talk about setting up a VPN tunnel on IRC at least.
I'm not sure about you but I never use the group interface created by OpenVPN or WireGuard on any of my OPNsense installs, I always do it on a per interface level.

And I manage setups with nearly 100 branches connected via OpenVPN S2S, I see different setups about every 2 weeks and I never ever saw an assigned interface in business. And everytime I saw one it was the cause of strange errors why they need professional help. This assigning thing comes from these VPN providers which are mostly used for stuff which might not be legal.
Dont get me wrong, but I think 90% of all use cases dont need assigning and 5% are due to wrong forum posts

Like this? https://github.com/opnsense/plugins/blob/master/net/wireguard/src/etc/inc/plugins.inc.d/wireguard.inc#L64

Yeah that makes more sense, you can tell straight away it's a group interface.
Not sure if it should be like that or maybe a sub headings and under that the group interfaces. So you get all your normally interfaces then you have all your group interfaces, nicely in order.
But what you have there in that screenshot is on the right tracks for sure. 💪

My WireGuard assignments are renamed as;

WG_S2S
WG_RW

.. so I never touch the WireGuard interface. As I do not either with the OpenVPN interface, I just edit the OpenVPN_RW interface.
When I started this venture with pfsense/OPNsense, this was not intuitive at first. But, through learning, trying to add more granular rules, remembering, and finally- reading the documentation ;) - I have now a good rule of thumb that I do not use those interfaces. But for new users? It would probably help adding (Group)- as it might trigger them to read the documentation more thoroughly.
https://docs.opnsense.org/manual/how-tos/wireguard-client.html

Finally, it allows separation of the firewall rules of each WireGuard instance (each wgX device). Otherwise they all need to be configured on the default WireGuard group that OPNsense creates. This is more an organisational aesthetic, rather than an issue of substance

And, maybe, if the documentation (for WireGuard - probably other pages too) could hint back to the Processing order - https://docs.opnsense.org/manual/firewall.html#processing-order it would be easier to comprehend for new users.
I would not like it to have been ignored / removed, but having a (Group) added is fine by me.

@fichtner ok for you to label this line https://github.com/opnsense/plugins/blob/master/net/wireguard/src/etc/inc/plugins.inc.d/wireguard.inc#L64 like the one in https://github.com/opnsense/plugins/issues/2577#issuecomment-943663448

@mimugmail sure, why not


Updated keys and certificates for AE tests with secure enclave

Coverage decreased (-0.03%) to 74.401% when pulling 07f9e00e6a39558c7a8dcca253653c65d4065ca7 on yitam:newCerts into 55e1715f7650a6a92a8bdffa88c4d934f7e31b41 on microsoft:dev.


[Feature] Copy absolute path with line number

First of all, your extension is such a life saver, appreciate it very much.
Just dropping a feature request.

I would build it myself if i had the time to, just dropping it here so if anyone interested can build

Actually the change was pretty simple so i went ahead and opened the PR


Revert "Merge pull request #7974 from vespa-engine/revert-7973-bratse…

…th/search-container-deprecations"
This reverts commit 5767288d80e85940e675f7dd157f2b6c1d2ceeb5, reversing
changes made to 37de7ac33454363489156e06597bffb3422756dc.

@gjoranv this was actually fine as-is. So, you have seen all this already.

👍


The first just positive issue

Inspired by little article I just read I deeply felt the need to just say THANK YOU @mpociot for maintaining this project. I guess it is really hard to find enough time, patience and energy to read issues, comment, discuss, test and so on.
I will also try to think more about the maintainer of an open-source project before writing an a poor issue or PR. (or before contacting Marcel on Slack, like I do a lot :-))

❤ thank you, Christoph!
And just to let you know: It's okay to contact me via Slack :)


Show parameter in the selector

Taken from the old TODO.md
Generally the selector (e.g. fzf) only shows the class and function name, it could improve readability when also showing the parameters. This is just a small improvement and might not even benefit anyone.

Additionally seeing a preview of the location could be nice (similar to how fzf, telescope handle jumping to files or search results)

After implementing a preview in telescope #13 I would say this is not really needed anymore.
For fzf this might still be relevant, but then adding a preview to it might make more sense (as it also shows types, part of the body etc etc.
The only real reason I see for this feature is, to be able to search via the parameters or wanting to parse a detailed representation of all function like functions, which was not the initial reason for this ticket.


unordered_map with vectors won't convert to json?

I have a std::unordered_map<std::string, vector<float>> *valuesMap and am trying to nlohmann::json jstr(valuesMap); but I do get error

error: static assertion failed: could not find to_json() method in T's namespace static_assert(sizeof(BasicJsonType) == 0

Are vectors not supported?

Pointer conversion is not supported as-is, dereferencing valuesMap should work.

Thanks a lot!


Removed run_all_in_graph_and_eager_mode in hamming.

@ssaishruthi
You are owner of some files modified in this pull request.
Would you kindly review the changes whenever you have the time to?
Thank you very much.


Minor Fixes to the Bridge

This PR addresses the expected minor changes to the bridge.
Expected changes include,

Updating examples to use more bridge functionalities
Update Bridge Interface

solve() method returns plan instead of list of actions
set_initial_values() accepts initial_values as an argument to add initial values as default. The method doesn't depend on API functions to set default initial value

PlanDispatcher and Executor will accept only callable from now and no objects.
Chores like fixing tests, format, linting and typechecking

Closes #3

@alexander-sung The changes are ready for review.

This doesn't seem to be minor fixes to me. It's a big pull request with changes to the interface. I don't like introducing Any to the bridge if it can be avoided. Is there need? I need to investigate in detail. Indeed it seems you listed all the intended changes in the description.

Indeed. Initially, it was planned to be minor fixes that I could notice during the paperwork. I can go over the description of the missing issues that are not linked to the PR ATM.

Thanks. I went through your changes.
This pull request remains with two changes.

The example scripts are updated to use bridge functionalities.
The work on set_initial_values() is also a part of this PR. If needed, I can move the changes related to set_initial_values() to a separate pull request.


Unable to get it to work

Hey! I'm sure I'm doing something stupid, but I just can't find it.
I'm getting no errors in the console. I'm loading jQuery 1.11.3, then the min.js and min.css from this cdn. I have an input that I've tried targeting from both the class and selector. When I view the contents of $('.datetimepicker').datetimepicker(); in the console, it returns the jQuery object with the expected elements, as I would expect it to.
Nothing seems broken... it just does nothing when I click in the input. I'm really puzzled. Any suggestions would be very appreciated.

I can get it working here no problem, though! Bah!

Can you help me how to give seconds in the plugin @JasonTheAdams

@sandeepmeenuga I'd start a new issue as that isn't really relevant to my old issue.


hooks.php: deploy:after is not firing on 2.2.1

Is hooks.php obsolete?
I installed rocketeer with composer globally. Run through rocketeer ignite.
I change the shared folders, just the hooks.php as follows:
    'after'  => [
        'setup'   => [],
        'deploy'  => [
            function ($task) {
                echo "asd";
            },
        ],
        'cleanup' => [],
    ],

Deploying with verbose flag gives me the following log: https://gist.github.com/bakroistvan/b6253d04b343213443fb943b23b10dc5

What version is this with?

$ rocketeer
Rocketeer version 2.2.1

Current state
  application     stackup
  configuration   /home/xx/Documents/stackup/.rocketeer
  tasks           /home/xx/Documents/stackup/.rocketeer/tasks
  events          /home/xx/Documents/stackup/.rocketeer/events
  logs            /home/xx/Documents/stackup/.rocketeer/logs

Usage:
  [options] command [arguments]

Options:
  --help           -h Display this help message
  --quiet          -q Do not output any message
  --verbose        -v|vv|vvv Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
  --version        -V Display this application version
  --ansi              Force ANSI output
  --no-ansi           Disable ANSI output
  --no-interaction -n Do not ask any interactive question
  --env               The environment the command should run under.

Available commands:
  check            Check if the server is ready to receive the application
  cleanup          Clean up old releases from the server
  current          Display what the current release is
  deploy           Deploys the website
  flush            Flushes Rocketeer's cache of credentials
  help             Displays help for a command
  ignite           Creates Rocketeer's configuration
  list             Lists commands
  rollback         Rollback to the previous release, or to a specific one
  setup            Set up the remote server for deployment
  strategies       Lists the available options for each strategy
  teardown         Remove the remote applications and existing caches
  test             Run the tests on the server and displays the output
  tinker           Debug Rocketeer's environment
  update           Update the remote server without doing a new release
plugin
  plugin:config    Publishes the configuration of a plugin
  plugin:install   Install a plugin
  plugin:list      Lists the currently enabled plugins

I have some chmod no such file error, but it should not affect hooks.php

That's rather weird, it should fire indeed. Try to put it in before (so you don't have to wait for the whole deploy to see if it works) and do something like $task->run('echo "foobar"') see if that works?

The before deploy.before is firing, but the deploy.after does not:
https://gist.github.com/bakroistvan/b6253d04b343213443fb943b23b10dc5/revisions

I rollbacked to 2.1.0 version. It works fine there.

I rollbacked to 2.1.0 version. It works fine there.

My deploy.after is also not firing.

Deploy.after is not firing for me either.
I have rocketeer deployed globally, and am using the latest code in the dev-master branch

Aight bisect done, 34bf193 is the culprit. Let me see if I can push a 2.2.2 soon