Ogre 1.12.10 upgrade

Continuing on from https://github.com/ros2/rviz/tree/clalancette/ogre-1.12.10-upgrade
The only thing I wasn't sure how to test was the ViewPicker. I'm not quite sure what that does and how to test it.

@clalancette I'll have a look now

The bug was fixed upstream, but looks like we won't get the changes backported to Ogre1.12. I think modifying the test to work around the bug is the best way around as the bug only seems to affect the tests.

@ros-pull-request-builder retest this please

In regards to the windows build failing - I set up a windows VM locally (please tell me if there's an easier way to test these changes) but couldn't reproduce the issue. Let's see if it happens again...

@ros-pull-request-builder retest this please

How do I trigger the tests correctly?

These tests are manually triggered by the ROS 2 team.

Linux
Linux-aarch64
Windows

There's a MSBuild warning coming from OgreRenderSystem.h:983,
'argument': conversion from 'size_t' to 'const T', possible loss of data

I'm not sure this is something we can fix in RViz, or if we should just suppress it with some preprocessor directives.

I'm not sure this is something we can fix in RViz, or if we should just suppress it with some preprocessor directives.

I suspect (but I'm not sure) that it has to do with the argument we are passing in when we actually call one of the Ogre functions.  If that is the case, we can probably fix it in RViz, but it should be investigated one way or another.
That said, this is really close!  Once we fix that issue one way or another, I think we'll be ready for this to land.

The issue seems to be coming from a deprecated method in Ogre that isn't used anywhere, so I just added a patch (C4267.patch) that comments it out. C4267 is the exact windows error code.
In upstream, the issue was fixed in https://github.com/OGRECave/ogre/commit/ba07f9616ad43d43469b50c062c94674338b2aa so it is included in 13.0.0 onwards. This patch can be deleted once we reach 13.0.0.

@clalancette or @jacobperron Could one of you run the CI again please?

Another CI:

Linux
Linux-aarch64
Windows

CI was happy here, and I did some local testing just to ensure that rviz worked properly.  Going ahead and merging, thanks for all of the work here.


Spek tests not runnable from Maven

I've been trying to get Spek to run from Maven for over a day now. I've followed all guides and examples I could find on the internet, but with no luck. I can run them in my IDE (IntelliJ), manually, but cannot get them to automatically run in bulk.
The documentation on how to run Spek from Maven on the official website, is very incomplete in my opinion (http://spekframework.org/docs/latest/#_maven). The pom has to be removed to allow compilation even.
Can anyone lend me a hand on this please? I've attached my entire pom.xml file (but have removed some private values). My tests/specifications have classnames of the form "...Spec.kt".
pom.xml.zip
Thanks in advance!

Ruud

On a sidenote: I was able to run my test manually. Spek just stops working now and throws me a nice "Test framework quit unexpectedly".

@RuudPaulissen have you checked https://github.com/spekframework/spek-maven-sample?

@raniejade I just got it working again. I was using JUnit platform version 1.0.0-M5 instead of M4. (Please mind that the documentation page to which the Spek docs link you under the "Maven" section, being http://junit.org/junit5/docs/current/user-guide/#running-tests-build-maven, specifies version 1.0.0-M5 as well - this is confusing.)
I don't seem to need the junit-jupiter-engine to run it, either. Or maybe I'm not using any features of it, and that's why it allows me to run the tests without.
Thank you for taking the time to help me out, but I'd suggesting making the documentation somewhat more explicit, e.g. link the example you sent me.

Yeah, 1.0.0-M5 was just recently released and it seems they introduced  several breaking changes again.

I've ran into another interesting issue here. If I run the tests manually, in IntelliJ, they all pass and everything is fine. However, if I run them through maven, I get a NullPointerException thrown from the surefire plugin.
Could this be a bug?

Can you paste the stacktrace?

Hi, there is no stack trace, really. In attachment I've added the output of the Surefire test run from Maven. It signals a failure, with a "null" value appearing in the console. That's about all error message I'm getting.

When running it directly, without Maven intervening, all of my tests do pass.

Take back what I last said about there not being a full stack trace: I've been looking into the issue some more and overlooked the "-e" tag for Maven.
Anyways, here is het full stack trace.

Thanks in advance.

I have found an issue with the exact same error and stack trace as me, here in the spek issues catalog. Link: https://github.com/JetBrains/spek/issues/138.
There was no real solution found, besides adding the @runwith(JUnitPlatform::class) annotation to every test class. Is this still the best way to solve this error?

What version of maven are you using?

Maven version 3.3.9, Java 1.8.0_111, Mac OS X 10.12.5

I saw your bug report https://issues.apache.org/jira/browse/SUREFIRE-1388, let's wait for a reply from the surefire team.

@raniejade the error messages I'm having are exactly those the issuer of ticket https://github.com/JetBrains/spek/issues/138 is having. He resolved vis issues by adding the @RunWith annotation, only I don't seem to have the necessary dependecies for JUnitPlatform::class. Do you have any experience with this?

@raniejade the error messages I'm having are exactly those the issuer of ticket https://github.com/JetBrains/spek/issues/138 is having. He resolved vis issues by adding the @runwith annotation, only I don't seem to have the necessary dependecies for JUnitPlatform::class. Do you have any experience with this?

@RuudPaulissen you need org.junit.platform:junit-platform-runner.

No luck, will have to continue playing the waiting game I guess.

Can you upload a sample project (in github) that reproduces the issue? I'll try to test it out again, it's been awhile since I used maven :).

Thank you for willing to take the time to look into it, @raniejade :-)
I'll do my best to prep something in the next few days. The weird thing is that the errors seem to occur in tests that come with external dependencies (e.g. database connectivity, network connectivity, ...) so it's not that straightforward to reproduce I fear.

Hi, I'm also having trouble using spek with latest versions of dependencies. I've created a sample repository to reproduce the issue: https://github.com/inikolaev/kotlin-spek-maven-example
Let me know if you are able to reproduce the issue when running it.

I also added Dockerfile so it would be easier to reproduce it.

Thanks, I'll look into it this weekend!

@inikolaev Looks like there's an issue with JUnit Platform and Surefire 2.20.1. I've tried using 2.19 as mentioned in the JUnit docs and it works. Below is the changes I made (it includes some cleanup).
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.github.inikolaev</groupId>
    <artifactId>spek</artifactId>
    <version>1.0</version>

    <dependencies>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-stdlib</artifactId>
            <version>1.1.50</version>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-reflect</artifactId>
            <version>1.1.50</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-test-junit</artifactId>
            <version>1.1.50</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jetbrains.spek</groupId>
            <artifactId>spek-api</artifactId>
            <version>1.1.5</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter-api</artifactId>
            <version>5.0.0</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.jetbrains.kotlin</groupId>
                <artifactId>kotlin-maven-plugin</artifactId>
                <version>1.1.50</version>
                <configuration>
                    <jvmTarget>1.8</jvmTarget>
                </configuration>
                <executions>
                    <execution>
                        <id>compile</id>
                        <phase>process-sources</phase>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <sourceDirs>
                                <source>src/main/java</source>
                                <source>src/main/kotlin</source>
                            </sourceDirs>
                        </configuration>
                    </execution>
                    <execution>
                        <id>test-compile</id>
                        <phase>process-test-sources</phase>
                        <goals>
                            <goal>test-compile</goal>
                        </goals>
                        <configuration>
                            <sourceDirs>
                                <source>src/test/java</source>
                                <source>src/test/kotlin</source>
                            </sourceDirs>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.6.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>

                <executions>
                    <!-- Replacing default-compile as it is treated specially by maven -->
                    <execution>
                        <id>default-compile</id>
                        <phase>none</phase>
                    </execution>
                    <!-- Replacing default-testCompile as it is treated specially by maven -->
                    <execution>
                        <id>default-testCompile</id>
                        <phase>none</phase>
                    </execution>
                    <execution>
                        <id>java-compile</id>
                        <phase>compile</phase>
                        <goals> <goal>compile</goal> </goals>
                    </execution>
                    <execution>
                        <id>java-test-compile</id>
                        <phase>test-compile</phase>
                        <goals> <goal>testCompile</goal> </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.19</version>
                <dependencies>
                    <dependency>
                        <groupId>org.junit.platform</groupId>
                        <artifactId>junit-platform-surefire-provider</artifactId>
                        <version>1.0.0</version>
                    </dependency>
                    <dependency>
                        <groupId>org.jetbrains.spek</groupId>
                        <artifactId>spek-junit-platform-engine</artifactId>
                        <version>1.1.5</version>
                    </dependency>
                </dependencies>
                <configuration>
                    <includes>
                        <include>**/*Spek.*</include>
                    </includes>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

For reference: https://github.com/junit-team/junit5/issues/809

Looks like it's not an issue w/ Spek. Closing it now, re-open if I miss something.


got issue when ran gprofiler in local and kubernets server cluster

can anyone help me to how to fix this issue
from granulate_utils.linux.elf import get_mapped_dso_elf_id
ImportError: cannot import name 'get_mapped_dso_elf_id' from 'granulate_utils.linux.elf' (/home/ubuntu/Desktop/gprofiler/granulate_utils/linux/elf.py)
from granulate_utils.linux.elf import read_process_execfn
ImportError: cannot import name 'read_process_execfn' from 'granulate_utils.linux.elf' (/home/ubuntu/.local/lib/python3.8/site-packages/granulate_utils/linux/elf.py)

Hi @sridharchary , it looks like gProfiler & its dependencies were not properly installed. Please make sure the granulate-utils submodule is up to date by running git submodule update and re-running the installation (cd granulate-utils && pip install ., in the Python context where you're going to run gProfiler).
Alternatively - you can use the image installation / executable installation, then you don't need to mess around with dependencies :)

I'm closing this ticket as my previous comment explains the needed fix (to update submodules). If the problem persists, feel free to reopen this ticket.


Make it easier to figure out where the data you want lives

Unfortunately /filenames isn't very useful because Tableau names extracts quite opaquely. I've seen temporary/cache-key-looking names pretty typically, although sometimes the filenames make sense, being similar to the names of the datasources shown in Tableau. The filenames in a workbook I've even seen change as the file was saved/reopened/saved, maybe something having to do with how Tableau manages temp files for open workbooks.
Better would be a way to look up data by the data source name exposed in the public visualization, or by column/values contained within the source, or something like this... something you can easily see, rather than something that's Tableau internal implementation detail of storage of hyper files, but which Tableau's Hyper API requires you use.
Then, you'd want to be able to call /data using that name, if less volatile than the filename.

Tableau does have a Python API for working with the workbook itself, which could be helpful for understanding how data sources are named and reference the extracts: https://github.com/tableau/document-api-python

This is fixed, by the new /data?url&name and /datasources?url endpoints. You no longer have to use filenames, you can use the names of the data sources seen in Tableau apps.


downgrade to tooling 1.0

see https://docs.microsoft.com/en-us/dotnet/standard/library
ref https://github.com/fsprojects/Paket/issues/2378

I didn't run any tests locally, let's see what the CI says.

@forki What's up with the build? :D

Can you pick the MSBuild fixes from https://github.com/fsprojects/Paket/pull/2362?
Sorry https://github.com/fsprojects/Paket/pull/2362 is not ready to merge jet, and I need a couple of days to fix ... I will take care of it if you can't

I would prefer to just add the nuget FSharp.Compiler.Tools instead of hardcoding a few different paths. What do you think?

Yes if it works I'm fine with that. nice!

Build now works, but one unit test failed. On it!
The great thing about the nuget is that this will allow compatibility with VS 2015 and F# vLatest. For example, if you use struct tuples, you will get red squiggles in the ide, but can still build and run / debug.

Yes very nice! btw you can test with the appveyor artefact how this change will impact your scenario (sorry i'm on mobile today and tomorrow...) or just build locally obviously

Av is green, travis failed with a weird error.
Please review if the unit test changes are actually correct.

Looks good. Travis failure is not related to this PR.
Merging because this fixes the build with MSBuild 15 in a particular nice way.


Improve support for custom vehicles

Currently we support the WAMV and CORA platforms. We have seen several requests for guidance on adding new vehicles. See:

#434
#465
#476
#472 (discussion)

This issue could be partially resolved with a detailed tutorial, as suggested in #465. However, some aspects of our vehicle model are currently hard-coded to match the WAMV design (e.g. two cylindrical hulls) and even our mono-hull CORA vehicle is using this. In addition, some vehicles may require extending the thruster plugin's capabilities, as proposed in the following PRs:

#479
#480
#481

We should support these features if possible, but we need to be mindful of any potential impacts on VRX competitors--in particular, it would be good to double check that any modifications which will propagate back to the WAMV are faithful to our theory of operations and don't have any unintended effects for the competition, or at least can be disabled if they do.

Thanks for putting up this list @M1chaelM.
Can you also add the following PRs which increase/correct the fidelity of the simulator?

https://github.com/osrf/vrx/pull/427
https://github.com/osrf/vrx/pull/466
https://github.com/osrf/vrx/pull/485

support these features if possible

I think this is evident based on the PRs submitted.

be mindful of any potential impacts on VRX competitors

For sure

double check that any modifications which will propagate back to the WAMV are faithful to our theory of operations

I would be willing to get on call with you to discuss the math behind the PRs

don't have any unintended effects for the competition

All PRs (Besides #427, #485, & #489) retain default values that do not change any behavior. The mentioned PRs fix the correct bearing, (if VRX competitors are using this quantity they would need to add a negative sign to maintain the original behavior in their code), and increase the accuracy in the buoyancy calculation. From the PRs the buoyancy has increased in simulation by about 100N (increase of only about 4%), but the visible behavior change of the vessel is not noticeably at all.

at least can be disabled if they do

Many changes are in the plugins and those portions can be selectively not loaded.
The above two concerns are specific to each feature and the relevant conversation and concerns should be had on the respective PRs/issues for those.


testing

Codecov Report

Merging #6 (249463b) into main (333471c) will increase coverage by 0.09%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main       #6      +/-   ##
==========================================
+ Coverage   71.60%   71.69%   +0.09%
==========================================
  Files        1816     1816
  Lines      115144   115144
  Branches    16672    16695      +23
==========================================
+ Hits        82449    82553     +104
+ Misses      31576    31468     -108
- Partials     1119     1123       +4

Flag
Coverage Δ

e2e-tests
66.52% <ø> (-0.05%)
:arrow_down:

unit-tests
63.59% <ø> (+0.12%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 14 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Switch Song - missing updates in GUI

If I Switch the song via Browser the following Things are not updated on your current trunk Version

Picture
Artist
Song title

Also the blue Background of the active song is not set
Testen on:

Windows IE
Windows Chrome
Windowsphoen IE

I I relaod the page all song ans Artist informations are correct, but no active title is markes with blue background

Unable to reproduce this and the issue is > 2 years old -> closing


"Unknown error" occurs when completing a transaction

When purchasing a course on production, the system records an unknown error. The transaction succeeds, but the user is redirected back to the cart with an error message. It appears the transaction result is falling out the bottom of the process_cybersource_payment_response call. In looking at the transaction details in CyberSource, it seems like it's sending back a response status of TRANSMITTED - the code doesn't know what to do with that, so it displays the generic error message. It should handle this status and, additionally, it should log something when it hits this status so we can have some logs when/if this happens again. The TRANSMITTED state is code 100, which indicates that the transaction was successful; we should process this state like an accepted transaction.
This may require a PR in the ol-django repo to add a constant for the TRANSMITTED status.
I'm not 100% sure about this but CyberSource's ability to process webhooks may have some bearing on why this hasn't popped up on RC or in local instances.
Steps to Reproduce

Add a course to the cart and attempt to check out.
Complete the purchase process. (Payment method does not matter here - it fails with either PayPal or credit card transactions.)

Expected Behavior
You are returned to the dashboard with a success message indicating the purchase was successful.
Actual Behavior
You are returned to the cart with an error message. However, you have been enrolled in the course successfully - it will appear in your dashboard and you'll have a verified enrollment.
Related Issues
#1114 is probably related to this.

Here a screenshot from the ebc for a transaction in this state:


Image overlays  not working

Issue description

Image overlays
reactstrap version #6.5.0
import method umd/csj/es
react version #16.6.3
bootstrap version #4.1.3

What is happening?
Text is not coming as overlapped on image, Instead it is coming below image.
What should be happening?
Text should come overlapped on image

Can you provide a working demo of this issue using https://stackblitz.com/edit/reactstrap-v6?file=Example.js


treewide: load structured attributes in all bash builders consistently

It's hard to put the sourcing of ./.attrs.sh into all builder consistently - mistakes will happen. Thus, load structured attrs once in make-derivation and then source the remaining builder on top.
This should fix quite a few builders with structured attributes in principle. Most importantly it helps substitute / substituteAll, which are required for bootstrap on some platforms.
Part of the overall effort to enable structuredAttrs by default eventually, tracking: https://github.com/NixOS/nixpkgs/issues/205690
As the author of #257919, you might be interested in reviewing this, @ma27?

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

As the author of #257919, you might be interested in reviewing this, @Ma27?

Oh absolutely, can't guarantee that I'll get to it tomorrow, though!

@wolfgangwalther https://github.com/NixOS/nix/pull/12026

So I successfully[1] built a bunch of derivations with __structuredAttrs and confirmed that the changes to the "custom" builders are fine by testing randomly selected builders. As I said, I think we'd either need to fix the part I mentioned above and runInLinuxVM or await the backport I made and bump minver.
Other than that, the change looks pretty good & reasonable, thanks!
[1] Well, glibc-locales ffom the stdenv bootstrap fails with
Build error for `/nix/store/nl1lb52i77bhvq0yyahwd4j100phx0fv-glibc-locales-2.40-36.drv`
mv -f /build/build/Versions.mkT /build/build/Versions.mk
printf "#include <time64-compat.h>\n#ifdef TIME64_NON_DEFAULT\nhave-time64-compat = yes\n#endif" \
| gcc -E -undef    -Iinclude   -I/build/build  -Isysdeps/unix/sysv/linux/x86_64/64  -Isysdeps/unix/sysv/linux/x86_64/include -Isysdeps/unix/sysv/linux/x86_64  -Isysdeps/unix/sysv/linux/x86/include -Isysdeps/unix/sysv/linux/x86  -Isysdeps/x86/nptl  -Isysdeps/unix/sysv/linux/wordsize-64  -Isysdeps/x86_64/nptl  -Isysdeps/unix/sysv/linux/include -Isysdeps/unix/sysv/linux  -Isysdeps/nptl  -Isysdeps/pthread  -Isysdeps/gnu  -Isysdeps/unix/inet  -Isysdeps/unix/sysv  -Isysdeps/unix/x86_64  -Isysdeps/unix  -Isysdeps/posix  -Isysdeps/x86_64/64  -Isysdeps/x86_64/fpu/multiarch  -Isysdeps/x86_64/fpu  -Isysdeps/x86/fpu  -Isysdeps/x86_64/multiarch  -Isysdeps/x86_64  -Isysdeps/x86/include -Isysdeps/x86  -Isysdeps/ieee754/float128  -Isysdeps/ieee754/ldbl-96/include -Isysdeps/ieee754/ldbl-96  -Isysdeps/ieee754/dbl-64  -Isysdeps/ieee754/flt-32  -Isysdeps/wordsize-64  -Isysdeps/ieee754  -Isysdeps/generic   -Ilibio -I. -nostdinc -isystem /nix/store/y6ylhhrkn31fd0sgbx0cwrmbbfijf5ls-gcc-14-20241116/lib/gcc/x86_64-unknown-linux-gnu/14.2.1/include -isystem /nix/store/y6ylhhrkn31fd0sgbx0cwrmbbfijf5ls-gcc-14-20241116/lib/gcc/x86_64-unknown-linux-gnu/14.2.1/include-fixed -isystem no -D_LIBC_REENTRANT  -include include/libc-symbols.h       -DTOP_NAMESPACE=glibc -x assembler-with-cpp - > /build/build/time64-compat.mk.iT
mv -f /build/build/time64-compat.mk.iT /build/build/time64-compat.mk.i
sed '/^[        ]*#/d;/^[       ]*$/d' /build/build/time64-compat.mk.i > /build/build/time64-compat.mkT
mv -f /build/build/time64-compat.mkT /build/build/time64-compat.mk
gawk -v buildlist="iconvprogs iconvdata ldconfig libmemusage libpcprofile librpcsvc locale_programs memusagestat nonlib nscd extramodules libnldbl libsupport testsuite testsuite_internal" -f scripts/gen-libc-modules.awk /build/build/soversions.i > /build/build/libc-modules.T
/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash scripts/move-if-change /build/build/libc-modules.T /build/build/libc-modules.h
touch /build/build/libc-modules.stmp
for dir in /build/build sysdeps/unix/sysv/linux/x86_64/64 sysdeps/unix/sysv/linux/x86_64 sysdeps/unix/sysv/linux/x86 sysdeps/x86/nptl sysdeps/unix/sysv/linux/wordsize-64 sysdeps/x86_64/nptl sysdeps/unix/sysv/linux sysdeps/nptl sysdeps/pthread sysdeps/gnu sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/x86_64 sysdeps/unix sysdeps/posix sysdeps/x86_64/64 sysdeps/x86_64/fpu/multiarch sysdeps/x86_64/fpu sysdeps/x86/fpu sysdeps/x86_64/multiarch sysdeps/x86_64 sysdeps/x86 sysdeps/ieee754/float128 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/wordsize-64 sysdeps/ieee754 sysdeps/generic; do \
  test -f $dir/syscalls.list && \
  { sysdirs='sysdeps/unix/sysv/linux/x86_64/64 sysdeps/unix/sysv/linux/x86_64 sysdeps/unix/sysv/linux/x86 sysdeps/x86/nptl sysdeps/unix/sysv/linux/wordsize-64 sysdeps/x86_64/nptl sysdeps/unix/sysv/linux sysdeps/nptl sysdeps/pthread sysdeps/gnu sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/x86_64 sysdeps/unix sysdeps/posix sysdeps/x86_64/64 sysdeps/x86_64/fpu/multiarch sysdeps/x86_64/fpu sysdeps/x86/fpu sysdeps/x86_64/multiarch sysdeps/x86_64 sysdeps/x86 sysdeps/ieee754/float128 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/wordsize-64 sysdeps/ieee754 sysdeps/generic' \
    asm_CPP='gcc -c    -Iinclude   -I/build/build  -Isysdeps/unix/sysv/linux/x86_64/64  -Isysdeps/unix/sysv/linux/x86_64/include -Isysdeps/unix/sysv/linux/x86_64  -Isysdeps/unix/sysv/linux/x86/include -Isysdeps/unix/sysv/linux/x86  -Isysdeps/x86/nptl  -Isysdeps/unix/sysv/linux/wordsize-64  -Isysdeps/x86_64/nptl  -Isysdeps/unix/sysv/linux/include -Isysdeps/unix/sysv/linux  -Isysdeps/nptl  -Isysdeps/pthread  -Isysdeps/gnu  -Isysdeps/unix/inet  -Isysdeps/unix/sysv  -Isysdeps/unix/x86_64  -Isysdeps/unix  -Isysdeps/posix  -Isysdeps/x86_64/64  -Isysdeps/x86_64/fpu/multiarch  -Isysdeps/x86_64/fpu  -Isysdeps/x86/fpu  -Isysdeps/x86_64/multiarch  -Isysdeps/x86_64  -Isysdeps/x86/include -Isysdeps/x86  -Isysdeps/ieee754/float128  -Isysdeps/ieee754/ldbl-96/include -Isysdeps/ieee754/ldbl-96  -Isysdeps/ieee754/dbl-64  -Isysdeps/ieee754/flt-32  -Isysdeps/wordsize-64  -Isysdeps/ieee754  -Isysdeps/generic   -Ilibio -I. -nostdinc -isystem /nix/store/y6ylhhrkn31fd0sgbx0cwrmbbfijf5ls-gcc-14-20241116/lib/gcc/x86_64-unknown-linux-gnu/14.2.1/include -isystem /nix/store/y6ylhhrkn31fd0sgbx0cwrmbbfijf5ls-gcc-14-20241116/lib/gcc/x86_64-unknown-linux-gnu/14.2.1/include-fixed -isystem no -D_LIBC_REENTRANT -include /build/build/libc-modules.h -DMODULE_NAME=libc -include include/libc-symbols.h       -DTOP_NAMESPACE=glibc -DASSEMBLER  -g -Werror=undef -Wa,--noexecstack      -E -x assembler-with-cpp' \
    /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash sysdeps/unix/make-syscalls.sh $dir || exit 1; }; \
  test $dir = sysdeps/unix && break; \
done > /build/build/sysd-syscallsT
mv -f /build/build/sysd-syscallsT /build/build/sysd-syscalls
make  -C localedata install-locales
make[2]: Entering directory '/build/glibc-2.40/localedata'
Makefile:567: target 'install-archive-C.UTF-8/UTF-8' given more than once in the same rule
Makefile:571: target 'install-files-C.UTF-8/UTF-8' given more than once in the same rule
.././scripts/mkinstalldirs /nix/store/xlq8w798knyvsw1wwfnillggy18y76v2-glibc-locales-2.40-36/lib/locale
mkdir -p -- /nix/store/xlq8w798knyvsw1wwfnillggy18y76v2-glibc-locales-2.40-36/lib/locale
aa_DJ.UTF-8...cannot open locale archive "/nix/store/d5paaz91bbg7ycz3vz2c7mxznmb0zr1j-glibc-2.40-36/lib/locale/locale-archive": Permission denied
make[2]: *** [Makefile:568: install-archive-aa_DJ.UTF-8/UTF-8] Error 1
make[2]: Leaving directory '/build/glibc-2.40/localedata'
make[1]: *** [Makefile:760: localedata/install-locales] Error 2
make[1]: Leaving directory '/build/glibc-2.40'
make: *** [Makefile:9: localedata/install-locales] Error 2
/nix/store/2bd1233710hmlfkdyayrji87rzvc1kvq-bootstrap-stage4-stdenv-linux/setup: line 1759: pop_var_context: head of shell_variables not a function context
/nix/store/2bd1233710hmlfkdyayrji87rzvc1kvq-bootstrap-stage4-stdenv-linux/setup: line 15: pop_var_context: head of shell_variables not a function context

when doing config.structuredAttrsByDefault = true;, but this doesn't look like a new regression, so I fell back to testing individual packages with structured attrs enabled.

@wolfgangwalther NixOS/nix#12026

This is merged (thank you @edolstra!).
So is this the plan?

Tag 2.3.18 in the Nix repository
Open and merge a PR for Nix 2.3.18, likely updating lib/minver.nix at the same time.
Merge this PR

Let me know @Ma27 @wolfgangwalther

Does this mean we need to wait until minVersion > 2.15

Things that will happen before: flakes will be stabilized, I'll finish university.

Am I missing anything?

No, I think you're right. It kinda sucks that this took so long to surface, but that's probably the price we have to pay given that this feature and everything around it was unused for so long and thus got almost no testing.
I see the following options:

bump minver, but still allow 2.3 as an exception now that it behaves correctly.
keep the -f .attrs.sh fallback (meh).

Minver is bumped very conservatively since you'd essentially block people from very old systems to upgrade in one go.
OTOH these versions are just dead and don't receive any support as opposed to Nix 2.3 and at some point you'll have to make a cut and now we have a compelling reason to do so.
I'm not convinced that we'll make the "minver"-call quickly, so my suggestion would be to continue with the -f .attrs.sh for now and defer the other part. That being said, I think it's still worth gathering opinions now to move forward.

cc @mweinelt @infinisil @K900 @emilazy
To summarize the above: we'd like to be able to use NIX_ATTRS_SH_FILE ONLY for __structuredAttrs = true; which points to the location of .attrs.sh (which is not necessarily NIX_BUILD_TOP, e.g. for nix develop). This change is now in the 2.3 release branch of Nix. However, the feature is broken in Nix from 2.4 to 2.15 because it points to the wrong location in the build sandbox[1].
We'd like to get rid of the if [ -f $NIX_ATTRS_SH_FILE ]; then ... elif [ -f .attrs.sh ] stuff (not only in stdenv, but in any derivation using a custom builder). The idea I have is to bump minver aggressively (i.e. to 2.15), but still keep Nix 2.3 as an exception given somewhat popular demand (and the fact that it's still maintained).
This would mean that you'll need to switch to 23.11 first before you can upgrade to 25.05 since that one has 2.18 as default Nix. Upgrades fro 23.05 would still be possible if we allow the latest patch-versions of 2.13 and 2.14.
I decided to just ping a bunch of people who are heavily involved in nixpkgs given that we don't have a real architecture team that I could consult on that.
[1] seems as if it was my patch that introduced the issue, but it took almost two years until it got caught since __structuredAttrs is hardly used. But still, apologies for that!

@Ma27 I'm fine with bumping minver.nix to say 2.15 myself, but with the fallback it sounds like it's not needed anymore, which is even better :D

I see, let's try bumping it then. We should ping relevant parties (all Nix implementations) in the PR doing that and give plenty of time to react.
We could also consider somehow making the distinction between "version needed for eval" and "version needed for building", because we'll leave the former at 2.3, but the latter will be 2.15.

We could also consider somehow making the distinction between "version needed for eval" and "version needed for building", because we'll leave the former at 2.3, but the latter will be 2.15.

I'm pretty opposed to this split. It's not clear to me it provides any value. The Nix deprecation story is messy enough as it is. If we bump lib/minver.nix, it should be a thorough bump, I think.
For another thread/PR, though, I suppose.

The Nix deprecation story is messy enough as it is

I don't think this is strictly related to the Nix deprecation story: minver is supposed to be bumped conservatively to give even older instances a chance to upgrade.
The 2.3 thing just became a very hot topic since 2.4+ are somewhat controversial (tl;dr flakes and a very large diff) which is why I'm a little hesitant to write it off (also, it's still maintained).
I fully agree with what @wolfgangwalther said here, we should stop supporting Nix versions to get rid of workarounds like that (I mean, there are a bunch of places that don't check for both cases, so technically 2.3 is broken there currently) and I think this is the quicker way to achieve that. Also, I think Tvix is targeting Nix 2.3 as baseline?
Anyways, at the end of the day, somebody has to make that call. I think we even had a Nixpkgs architecture team in the past ;-)

We could also consider somehow making the distinction between "version needed for eval" and "version needed for building"

I get the motivation, but wouldn't it be awkward if your Nix is sufficient to evaluate, but not to build nixpkgs?
Anyways, @wolfgangwalther the current state looks reasonable. I'd go through the changes soonish one last time and merge then.

Meh this now needs a rebase @wolfgangwalther. Feel free to merge after that.

Late to the party here, but the Nix minimum version bump that makes sense to me is 2.18, as the “new 2.3” and a reasonable baseline for Nix semantics, given Lix’s explicit choice of it as a base and the year that Nixpkgs was stuck on it. That cuts off 23.05, but the upside is that 23.11 doesn’t just contain 2.18 but also defaults to it, so the story is pretty simple: “upgrade to 23.11 before upgrade to 25.05”.
I don’t think that anyone really cares about the versions between 2.4 and 2.18, and the latter has had an above‐average level of maintenance put into it given its use as the default version across multiple Nixpkgs releases. I know Tvix is aiming for 2.3 compatibility, but I believe that relates to post‐2.3 eval behaviour regressions that Nixpkgs assuming any newer version might run into anyway, and I imagine there is room for adjustment there given the importance of Nixpkgs compatibility. (But of course we should ping representatives of all implementations, and anyone else who might have a stake in the choice, on the PR.)

I'm not really opposed to your suggestion, I just tried to be as conservative as possible to get it through. But I'm not sure I'll follow through now that things got a little more complicated.

Sorry if I contributed to any of the complication :) I do think some bump is a reasonable idea and I’m not too fussy about what exact version.


Error occur randomly on images

net::ERR_INCOMPLETE_CHUNKED_ENCODING and net::ERR_CONTENT_LENGTH_MISMATCH occur randomly on images served via proxy_pass to a static site. Didn't even activate modsecurity in config.
Build:
(commit hashes are all their branches' HEAD atm, listing them down just in case)
Ubuntu 14.04
nginx-1.9.5
libinject - copied from Modsecurity's fecefbe8b4fc628dfef9ebff0317bfb9fd871078 (apache2/libinject directory)
libmodsecurity - 283c8c818db1e11fb496064b6cc1158ebe947d58
ModSecurity-nginx - 1713be9e7ca5c95d5c09df59e3c62e548072af0d

nginx.conf
user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
        worker_connections 2048 ;
        # multi_accept on;
}

http {
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;

        include mime.types;
        default_type application/octet-stream;
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        gzip on;
        gzip_disable "msie6";

        server {
                listen       80;
                server_name  <my server name>;
                location / {
                        proxy_pass http://<my ip>;
                }
        }
}

It happens at random intervals - reloading may make the image load again. Also when encountering the wrong CONTENT_LENGTH_MISMATCH error, Content-Length header was correct, so it's probably the image's body returned that's wrong.

Hi @TrungACZNE,
I was trying to reproduce the problem here without success.
Here is what I was using:
libmodsecurity: 47a62b98bbc486fadb28e62db910195577aea228
nginx: 1.9.12
nginx connector: 221a134181cf316033e36d7573a4c79689f2a835

Do you mind to test it again? with fresh versions?

Hi,
I forgot to close this after awhile. It's a misconfiguration on my side. I don't have exactly the details about my old configuration though, it's been a long time since.
Sorry for wasting your time.

No problem.
Thanks @TrungACZNE


Can flash my code to the ESP32-S3-WROOM-1? (IDFGH-10826)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Hello,
I have an ESP32-S3-WROOM-1-N16 and I am not able to flash my code . It gives error like
A fatal error occurred: Failed to connect to ESP32-S3: No serial data received. I have boot and reset button When I pressed the boot button while flashing code it still gives error. I tried to using lower baud rate but it did not work
How can I flash my code to the chip?

Hello @onurdof,
I need some more information to debug your issue:

How are you connecting to the module? Are you using the TX/RX pins or pins 19/20?
What OS are you on? Do you see your module connected when you list the serial ports?
If you open any serial terminal program (IDF monitor, miniterm or others), connect to the chip and press the reset button, do you see any output?

No serial data received means there is no data coming out of the chip. This can be caused by many reasons, like HW issues, wrong connections, insufficient power supply, and more...

I tried this and did not see any output

That means there is definitely a HW issue. The cp2102 / FTDI chips work, that's why you see a port, but the ESP chip doesn't.
Common reasons:

the connections between the USB-to-UART chip and the ESP are wrong (reversed or disconnected TX/RX?)
the ESP is not getting enough power or none at all
the ESP is being held in RESET (can be caused by shorting EN pin to GND. Bad soldering can cause this
the ESP is fried

Please try to verify these.

Closing this issue. Feel free to reopen it if necessary, thank you.


Fix regular expression for PowerShell DCO check

Signed-off-by: John Stephens<EMAIL_ADDRESS>This corrects the remaining issue from #29494. In PowerShell, the escape character is the grave accent, not the backslash. Therefore, the backslash in this string must not be escaped with another backslash.

Can you sign off with Signed-off-by: John Stephens<EMAIL_ADDRESS>(github: johnstep) ?

LGTM


GH-33143: [C++] Naming and doc/test changes for local_time compute kernel

Rationale for this change
A better naming for local_time kernel was proposed in post merge review of #34208.
What changes are included in this PR?
Change local_time to local_timestamp and related docs/test changes.
Are these changes tested?
Yes.
Are there any user-facing changes?
Changing local_time to local_timestamp is a user facing change. But since it was not yet released we can probably treat it as non-breaking.

Closes: #33143

Could you open a new issue for this?
This is not a MINOR change.
See also: https://github.com/apache/arrow/blob/main/CONTRIBUTING.md#minor-fixes

Sorry @kou this is indeed not minor. @jorisvandenbossche thanks for linking to the original issue, I think this mapping is satisfactory?
I think this is also ready for review.

This looks fine to me.


Can't answer a video phone call from IOS to android

reported by @SolalArmada:matrix.org
https://github.com/matrix-org/riot-android-rageshakes/issues/713

Confirmed, same here. Trying voice/video calls on the following (latest I can get from either .exe/.dmg or repos/stores):
Linux <-> iOS: Works fine
MacOS <-> Windows 10: fine
Linux <-> MacOS: fine
Windows <-> iOS: fine
Android <-> iOS: Voice and video fails to pick up both ways, doesn't matter who calls
Android <-> MacOS: Voice works. Video struggles and freezes after a minute or so


updated model-boiler (2.1.4)

Thank you for the contribution. It was merged directly as e9d04dac2213e9dcc9d4f36ce8e7a462d78b5711 to keep commit history cleaner. Your contribution is still credited to you.


Enhance disconnect method

https://github.com/threefoldtech/tfgrid-sdk-ts/blob/832d4d9ee5e944d677db392f6e015579f55704d2/packages/grid_client/src/client.ts#L124
this line should moved to this.disconnect method

Investigation and Solution

the current solution make the client disconnect twice
will remove event listeners from grid client as each client has its own event listeners.

couldn't reproduce disconnecting twice issue, will check with Hanafy later for this point

the example script on the direct client is not working as the close method has been removed

requested changes are done


[MINOR][SQL] Fix comments styl and correct several styles and nits in CSV data source

What changes were proposed in this pull request?
While trying to create a PR (which was not an issue at the end), I just corrected some style nits.
So, I removed the changes except for some coding style corrections.

According to the scala-style-guide#documentation-style, Scala style comments are discouraged.

/** This is a correct one-liner, short description. */

/**
 * This is correct multi-line JavaDoc comment. And
 * this is my second line, and if I keep typing, this would be
 * my third line.
 */

/** In Spark, we don't use the ScalaDoc style so this
  * is not correct.
  */

Double newlines between consecutive methods was removed. According to scala-style-guide#blank-lines-vertical-whitespace, single newline appears when

Between consecutive members (or initializers) of a class: fields, constructors, methods, nested classes, static initializers, instance initializers.

Remove uesless parentheses in tests

Use mapPartitions instead of mapPartitionsWithIndex().

How was this patch tested?
Unit tests were used and dev/run_tests for style tests.

Test build #54698 has started for PR 12109 at commit f56e748.

Test build #54698 has finished for PR 12109 at commit f56e748.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/54698/
Test PASSed.

The doc changes are actually good. Going to merge this in master. Thanks.


Preview function in creation page with auto sync

These commits resolve #20.
There are some notable changes in this PR.

We use Ace editor as markdown editor instead of textarea
Disable the document level scrollbar. Only markdown editor and preview have the scrollbar
Markdown editor and preview resize itself to fit in browser height
The preview scroll itself automatically to sync with current caret position of markdown editor

It will not scroll if the slide of current caret is fully visible

Oops.. there is a critical bug. I'll fix it. Abort review and merging.

OK the problem is solved. Please review!

LOL for gif... I will review this night


run IDA tests in CI

Do you test IDA backend in the CI by any chance?

we don't, and it's definitely a source of bugs. so, we should. we haven't yet because headless install and scripting with IDA is rather painful. though, since we're ([un]fortunately) heavy IDA users, we exercise the IDA/capa integration manually pretty frequently.
Originally posted by @williballenthin in https://github.com/mandiant/capa/issues/1343#issuecomment-1463760956

we could provide the IDA resources via AES encrypted blobs to GH Actions and decrypt with a strong key provided via GH Actions  Secrets. the IDA resources and resulting analysis would not be available to anyone (including us, actually) but would merely show that the IDA backend works as intended.

its a little tricky to invoke all the tests today, because they expect to be run against a bunch of different input samples and assert that features are extracted. we'll need to find a way to structure the tests such that they're easy to invoke in CI.


Avoid indexing the table twice for Cross Tab

The current cross-tab implementation first indexes the table for the group_by columns.
It then creates an index for the name columns.
This can be simplified to do a single index across the group_by and name columns combined.
We can then get the name from the last part of the index.

It looks straightforward to use a combined index to calculate the aggregates for each superkey (grouping + name columns), then for each set of aggregates, using subkeys to determine the row and columns to put them in.
I am concerned that calculating the row + column to put the aggregates in will being doing a lot of hashing, which is probably a large part of the time to build the original indices, so I'll run benchmarks.

Benchmark results:
For small tables (25 or 250 rows), the two approaches are about the same. For larger tables (2500 or 25000 rows), there is a clear improvement in all cases but one (the second-to-last).

After running the bad benchmark again, it was still a bit higher, but only about 11%.

Comparing my (composite index) approach with Radek's (nested index) approach:
For small tables, nested is faster; for larger tables, composite is equal or faster.
old 25--size-(Count '')/one index average: 0.58ms
new 25--size-(Count '')/one index average: 0.26ms
old 25--type-(Count '')/one index average: 0.14ms
new 25--type-(Count '')/one index average: 0.12ms
old 25--store-(Count '')/one index average: 0.12ms
new 25--store-(Count '')/one index average: 0.12ms
old 25-type-size-(Count '')/one index average: 0.14ms
new 25-type-size-(Count '')/one index average: 0.13ms
old 25-store-size-(Count '')/one index average: 0.1ms
new 25-store-size-(Count '')/one index average: 0.1ms
old 25-size-store-(Count '')/one index average: 0.1ms
new 25-size-store-(Count '')/one index average: 0.1ms
old 25-size-store-(Count '')+(Sum 'price' '')/one index average: 0.67ms
new 25-size-store-(Count '')+(Sum 'price' '')/one index average: 0.42ms
old 250--size-(Count '')/one index average: 0.17ms
new 250--size-(Count '')/one index average: 0.12ms
old 250--type-(Count '')/one index average: 0.12ms
new 250--type-(Count '')/one index average: 0.11ms
old 250--store-(Count '')/one index average: 0.12ms
new 250--store-(Count '')/one index average: 0.12ms
old 250-type-size-(Count '')/one index average: 0.15ms
new 250-type-size-(Count '')/one index average: 0.15ms
old 250-store-size-(Count '')/one index average: 0.18ms
new 250-store-size-(Count '')/one index average: 0.16ms
old 250-size-store-(Count '')/one index average: 0.19ms
new 250-size-store-(Count '')/one index average: 0.16ms
old 250-size-store-(Count '')+(Sum 'price' '')/one index average: 0.42ms
new 250-size-store-(Count '')+(Sum 'price' '')/one index average: 0.44ms
old 2500--size-(Count '')/one index average: 0.4ms
new 2500--size-(Count '')/one index average: 0.42ms
old 2500--type-(Count '')/one index average: 0.38ms
new 2500--type-(Count '')/one index average: 0.45ms
old 2500--store-(Count '')/one index average: 0.41ms
new 2500--store-(Count '')/one index average: 0.48ms
old 2500-type-size-(Count '')/one index average: 0.55ms
new 2500-type-size-(Count '')/one index average: 0.64ms
old 2500-store-size-(Count '')/one index average: 0.64ms
new 2500-store-size-(Count '')/one index average: 0.7ms
old 2500-size-store-(Count '')/one index average: 0.62ms
new 2500-size-store-(Count '')/one index average: 0.73ms
old 2500-size-store-(Count '')+(Sum 'price' '')/one index average: 2.37ms
new 2500-size-store-(Count '')+(Sum 'price' '')/one index average: 2.51ms
old 25000--size-(Count '')/one index average: 3.1ms
new 25000--size-(Count '')/one index average: 3.53ms
old 25000--type-(Count '')/one index average: 3.38ms
new 25000--type-(Count '')/one index average: 3.92ms
old 25000--store-(Count '')/one index average: 3.54ms
new 25000--store-(Count '')/one index average: 4.17ms
old 25000-type-size-(Count '')/one index average: 4.48ms
new 25000-type-size-(Count '')/one index average: 5.82ms
old 25000-store-size-(Count '')/one index average: 5.9ms
new 25000-store-size-(Count '')/one index average: 6.22ms
old 25000-size-store-(Count '')/one index average: 5.42ms
new 25000-size-store-(Count '')/one index average: 6.34ms
old 25000-size-store-(Count '')+(Sum 'price' '')/one index average: 22.23ms
new 25000-size-store-(Count '')+(Sum 'price' '')/one index average: 22.39ms


Incorrect variable name

Was reading through the example usage with sequelize and noticed that the variable name was incorrectly labelled as sequelize when it was obviously meant to be service.

Thanks!


The project Id is displayed under Team Name column for some resources

Description:
Under the Team Name column, I am able to see projectID displaying instead of Team name for some resources.

@sandhiyakavi I cannot reproduce this issue. Do you know any steps on how to reproduce it? If you could reproduce it again, could you please check the DevTool console log and see what error do you see there.
PS. I suspect that it was some temporary issue with Projects API.

@maxceem Yes, I am not able to reproduce the issue, The Team name's are correctly displaying now.

@maxceem It is happening for the BookingManager role


Rewrite

Will probably need to add a section on upgrading to this version but let me know if you have any thoughts or suggestions on any of this.
Thanks!

Tagging #113

Hi @RyanJarv!
I just cloned this down and took it for a spin. It looks like there's an issue with the varnish41-ubuntu-1404 test:
       Failures:

         1) Command "curl localhost:6081" exits zero
            Failure/Error: expect(subject.exit_status).to eq 0

              expected: 0
                   got: 127

              (compared using ==)
              env PATH="/sbin:/usr/sbin:/bin:/usr/bin" /bin/sh -c curl\ localhost:6081

Hm.. I'm not getting that error, How you're running the tests and what is the output of that curl command?
I guess my last commit adding comments to the varnishlog init script did break varnish3-ubuntu-1404 though so will have to fix that as well.

Yeah -- ended up with:
>>>>>>     Converge failed on instance <varnish3-ubuntu-1404>.  Please see .kitchen/logs/varnish3-ubuntu-1404.log for more details
>>>>>>     Converge failed on instance <varnish3-ubuntu-1204>.  Please see .kitchen/logs/varnish3-ubuntu-1204.log for more details
>>>>>>     Verify failed on instance <varnish4-ubuntu-1404>.  Please see .kitchen/logs/varnish4-ubuntu-1404.log for more details
>>>>>>     Verify failed on instance <varnish41-ubuntu-1404>.  Please see .kitchen/logs/varnish41-ubuntu-1404.log for more details

It looks like, for Ubuntu, curl simply isn't installed. Once I do that, the tests all pass. I will note that:
       Command "curl localhost:6081"
         exits zero

However:
root@varnish41-ubuntu-1404:~# curl localhost:6081 -I
HTTP/1.1 503 Backend fetch failed

Ah ok, curious how old your vagrant box is and if updating it fixes it. Thinking it might be better to leave out the curl install out if it's just caused by an old ubuntu version (assuming the change wasn't too recent at least). The 503 is because there isn't actually a backend configured in the tests but I think that would be good to add along with maybe some varnishtest cases.
Added the fixes for the varnish3-ubuntu-1404 thing and will probably have some time next week to add some notes on upgrading and get a test w/ nginx running. Other then that I think it should be good for a non-published version.

Updating vagrant boxes, plus pulling your additional commits, seems to fix the remaining failures 👍

Ok awesome. So did a bit of looking around and it looks like wget is installed by default on the earlier ubuntu images and from what I'm reading it's more commonly available by default, anyways probably doesn't matter much either way. Thanks for getting this merged! I'm assuming the permission denied error is something on the CircleCi side of things but let me know if need to do anything there.


odo logs: Do not panic when no access to cluster/podman

What type of PR is this:
/kind bug
What does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #6555
PR acceptance criteria:

[ ] Unit test

[ ] Integration test

[ ] Documentation

How to test changes / Special notes to the reviewer:

/override Kubernetes-Integration-Tests/Kubernetes-Docs-Integration-Tests
Flake:

  user-guides/quickstart/docs-mdx/java/java_odo_dev_output.mdx
  Expected
      <string>:   (
        	"""
        	... // 10 identical lines
        	âœ“  Added storage m2 to component
        	âš   Pod is Pending
      - 	âœ“  Pod is Running
        	âœ“  Syncing files into the container [1s]
        	âœ“  Building your application in container (command: build) [1s]
        	... // 9 identical lines
        	[Ctrl+c] - Exit and delete resources from the cluster
        	[p] - Manually apply local changes to the application on the cluster
      + 	âœ“  Pod is Running
        	```
        	"""
        )

  to be empty
  In [It] at: /go/odo_1/tests/documentation/user-guides/doc_user_guides_quickstart_test.go:256


replace != with !== in csrf checks

Change suggested by Toshi.
!= casts to same type and might lead to unexpected results.

It's an excellent suggestion.  != (and ==) does "approximate" comparisons where data type doesn't have to be the same.  So, in PHP, something like (0 == "0") evaluates as true.  ("0" == false) also evaluates as true.  Using !== (and ===) ensures that both datatype and value are considered, so the aforementioned conditionals evaluate to false.  Security checks should check both value and datatype.
The code you changed is very straightforward and so that's one vote for merging to master.  :+1:

Technically not a worry as any $_GET or $_POST requests are treated as strings within PHP (and HTTP in general) so even if you were to post a boolean true for csrf_token, it'll end up as string "true" which is the only case we need to worry about (as "string" == true evaluates to true in PHP, but "string" == "true" would be false). It'll actually always do a string comparison.
Doesn't negatively affect performance so I don't care.

Yes, Toshi noted he didn't think there was a potential problem.  But its good practice for code in php.


Error with wrong indices in loops

The following MFE presents some cases in which the indexes used to access functions are not defined correctly. All these cases produce more than one time-iteration loop and that's when the error appears.
from devito import (Eq, Operator, Grid, TimeFunction)

grid = Grid(shape=(10,10))
x, y = grid.dimensions
t = grid.stepping_dim

f = TimeFunction(name="f", grid=grid, space_order=2, time_order=2)
g = TimeFunction(name="g", grid=grid, space_order=2, time_order=2)

eqn = []
eqn.append( Eq( f.forward, f + 1 ) )

# Case 1 - Compilation error (t0 undeclared on the second loop, t0+2 should be replaced by t2)
# eqn.append( Eq( g.forward, f[t+2,x,y] ) )

# Case 2 - Segfault (t0 is declared, but t0+3 attempts to access wrong index, t0+3 should be replaced by t2)
eqn.append( Eq( g, f[t+3,x,y] ) )

# Case 3 - No error (t0+2 should be replaced by t2)
# eqn.append( Eq( g, f[t+2,x,y] ) )

op = Operator(eqn)

op.apply(time_M=10)

It seems substitutions of SteppingDimensions by ModuloDimensions in  _lower_stepping_dims(iet) (devito/ir/iet/scheduler.py) are being done in a misleading manner: All expressions in iet have their indices replaced with uindices (eg. t+2 -> t0+2) available in the first iteration tree, which in these examples is the first time-iteration loop. That way, when we get to the second time-iteration loop, indices that were supposed to be replaced (eg. t+2 -> t2) are not found because they have already been replaced (eg. t+2 -> t0+2) and so they remain that way in the code, resulting in compilation or execution errors. This is because the second time-iteration loop may not even have that t0 indice (Case 1) or if it has t0 it can attempt to access wrong index (Case 2) since indexes are miscalculated (eg. t0+2 != t2, because t0 = (time)%(3), t2 = (time+2)%(3), so t0+2 could reach 4, out-of-bounds, as soon as t0==2). Also, that could even not produce any errors at all, but still mess up the numerical result (Case 3).

I think we can solve this issue changing _lower_stepping_dims(iet) (devito/ir/iet/scheduler.py) definition by making substitutions to occur only at child expressions of each iteration at a time, thus building a mapper which further transforms the entire iet. I've tested this and got no problems of declaration missing or segfaults anymore. All indices in expressions are in accordance with its iteration loop.
def _lower_stepping_dims(iet):
    imapper = {}
    for i in FindNodes(Iteration).visit(iet):
        if not i.uindices:
            # Be quick: avoid uselessy reconstructing nodes
            continue
        # In an expression, there could be `u[t+1, ...]` and `v[t+1, ...]`, where
        # `u` and `v` are TimeFunction with circular time buffers (save=None) *but*
        # different modulo extent. The `t+1` indices above are therefore conceptually
        # different, so they will be replaced with the proper ModuloDimension through
        # two different calls to `xreplace`
        mindices = [d for d in i.uindices if d.is_Modulo]
        groups = as_mapper(mindices, lambda d: d.modulo)
        for k, v in groups.items():
            mapper = {d.origin: d for d in v}
            rule = lambda i: i.function.is_TimeFunction and i.function._time_size == k
            replacer = lambda i: xreplace_indices(i, mapper, rule)
            # iet = XSubs(replacer=replacer).visit(iet)
            imapper[i] = XSubs(replacer=replacer).visit(i)

    return Transformer(imapper).visit(iet)

yes, this looks about right.
nitpicking: imapper -> subs (for maximum code homogeneity -- when the name 'mapper' is already taken, the next favourite one to keep track of substitutions is 'subs' )
could you open a PR plus test(s) ? please, update the tests so as to assert against some expected values

# Case 1 - Compilation error (t0 undeclared on the second loop, t0+2 should be replaced by t2)
# eqn.append( Eq( g.forward, f[t+2,x,y] ) )

# Case 2 - Segfault (t0 is declared, but t0+3 attempts to access wrong index, t0+3 should be replaced by t2)
eqn.append( Eq( g, f[t+3,x,y] ) )

# Case 3 - No error (t0+2 should be replaced by t2)
# eqn.append( Eq( g, f[t+2,x,y] ) )

But these are all invalid and should throw an error not be converted.
For time_order=2, and any given time index, only three indices are defined, t-1, t, t+1 every other is either already forgotten or doesn't exist yet. What you are infering from the C code is not what you think it is and comes from the shift in indices to avoid computing modulo on negative values (t- 1 can be negative which would be problematic but (t-1)%3  = (t+2)%3 so we compute the latest).

copy-pasting example posted on Slack by @mloubout for future reference
consider
f = TimeFunction(time_order=2)
g = TimeFunction(time_order=2)
Eq(f, time)
Eq(g, f[t-2])

Then the corect values for f are 1,2,3,4…..  and for g are 0, 0, 1,2,3,4,…. but if you replace f[t-2] by f[t2] then that’s not what you get. The fact that the modulo index makes it a non-segfault index doesn’t mean it’s a valid index expression-wise (edited)
also this is related to: https://github.com/devitocodes/devito/issues/602 (which I've just updated with further info)

Sorry for being so wordy!
I understand that t+2 (or t+3), with a time dimension of 2, does not have a right meaning, but again if loop stepping indices are assigned like that, shouldn't expressions do the same? The only case I could reproduce such behavior (two time loops) without using out of bound indices was that one with an intermediary non-time function, which again I'm not certain if it has any meaningful application (I suppose not). I also understand that avoiding these situations by throwing exceptions would do the job, although I think maybe this could still be a flaw in the code. I’m sorry if I missed something from your messages. I’m going to review that more carefully.
The patch I've proposed makes expressions to be built in accordance with their loops and by doing this, it avoids critical errors like segfault and declaration missing. I could assert values from a time marching operator, even with these out of bound indices, since we know they would point to some time buffer (due to %(3)). And yes, I understand that would not have the right meaning for any real application.
The only tests that are failing with the proposed patch are:

tests/test_dimension.py::TestBufferedDimension::test_multi_buffer
tests/test_dimension.py::TestBufferedDimension::test_multi_buffer_long_time

I noticed these are the only tests which use save=Buffer(N), with N > 2 (With N=2 tests have passed, eg.: tests/test_save.py::test_buffer_api).
I couldn't find the reason yet (still look into that), but with save=Buffer(N) for with N > 2, indices are not replaced as expected, and parameter t gets no value. See code produced and apply error, below:
for (int time = time_m, t0 = (time + 1)%(2), t1 = (time)%(3); time <= time_M; time += 1, t0 = (time + 1)%(2), t1 = (time)%(3))
  {
    struct timeval start_section0, end_section0;
    gettimeofday(&start_section0, NULL);
    /* Begin section0 */
    for (int x = x_m; x <= x_M; x += 1)
    {
      #pragma omp simd aligned(f,g:64)
      for (int y = y_m; y <= y_M; y += 1)
      {
        f[t + 1][x + 1][y + 1] = 1;
        g[t1][x + 1][y + 1] = f[t + 1][x + 1][y + 1];
      }
    }
    /* End section0 */
    gettimeofday(&end_section0, NULL);
    timers->section0 += (double)(end_section0.tv_sec-start_section0.tv_sec)+(double)(end_section0.tv_usec-start_section0.tv_usec)/1000000;
  }

Traceback (most recent call last):
  File "mfe3.py", line 44, in <module>
    op.apply(time_M=3)
  File "/home/victor.leite/lde/devito-issues/devito/operator/operator.py", line 640, in apply
    args = self.arguments(**kwargs)
  File "/home/victor.leite/lde/devito-issues/devito/operator/operator.py", line 526, in arguments
    raise ValueError("No value found for parameter %s" % p.name)
ValueError: No value found for parameter t

This is a draft for the test I've mentioned above.
    @pytest.mark.parametrize('expr,result', [
        ('[Eq(g, f[t+1, x, y])]',[(10.,11.,9.)]),
        ('[Eq(g, f[t+2, x, y])]',[(11.,9.,10.)]),
        ('[Eq(g, f[t+3, x, y])]',[(9.,10.,11.)]),
        ('[Eq(g.forward, f[t+2, x, y])]',[(10.,11.,9.)]),
    ])
    def test_lower_stepping_dimentions(self, expr, result):

        grid = Grid(shape=(4,4))
        x, y = grid.dimensions
        t = grid.stepping_dim

        f = TimeFunction(name="f", grid=grid, space_order=2, time_order=2)
        g = TimeFunction(name="g", grid=grid, space_order=2, time_order=2)

        f.data[:] = g.data[:] = 0.

        op = Operator([Eq(f.forward, f + 1)] + eval(expr))

        exprs = FindNodes(Expression).visit(op)
        assert isinstance(exprs[0].expr.lhs.indices[0],ModuloDimension)
        assert isinstance(exprs[0].expr.rhs.args[1].indices[0],ModuloDimension)
        assert isinstance(exprs[1].expr.lhs.indices[0],ModuloDimension)
        assert isinstance(exprs[1].expr.rhs.indices[0],ModuloDimension)

        op.apply(time=10)

        result = [(9.,10.,11.)] + result

        for i in range(3):
            assert np.all(f.data[i, :, :] == result[0][i])
            assert np.all(g.data[i, :, :] == result[1][i])

I admit I haven't touched the Buffer stuff in a while, but it feels like you're on the right track?

I guess this doesn't invalidate this issue. E.g.: If loop stepping indices are assigned like that, shouldn't expressions do the same? I’m sorry if I missed something here. I’m going to review that more carefully.

I do agree. Though I think that what @mloubout was saying is that we shouldn't actually get that far in compilation. But yes, this is a symptom, as you correctly pointed out, that something is off

We could move forward with that MFE using an intermediary (non-time dependent) function, which is the only case I could reproduce such behavior (two time loops) without using out of bound indices.

I think it boils down to whether the MFEs are fundamentally different or they're just triggering the very same bug through different constructs. In the former case, I'd like to have all the MFEs; in the latter case, just one would be fine.
I think you were on the right track with the initial patch, but yeah, we need to figure out why the Buffer tests would now break
Thanks!

I think it boils down to whether the MFEs are fundamentally different or they're just triggering the very same bug through different constructs. In the former case, I'd like to have all the MFEs; in the latter case, just one would be fine.

I think we're dealing with the latter: we're triggering the same situation from different constructs. I think the problem is the code does not expect more than one iteration at the same level with different modulo dimensions. Those MFEs make it happen with time.

I think you were on the right track with the initial patch, but yeah, we need to figure out why the Buffer tests would now break

That was actually my fault. When I change the flow of transformations to prevent them all to get the whole iet, I must assure the inner loop transformations remain cumulative, and not with respect to the same input, as I did before. It would also break also with different time_order values in functions of the same operator.
That fixes it:
def _lower_stepping_dims(iet):
    subs = {}
    for i in FindNodes(Iteration).visit(iet):
        if not i.uindices:
            # Be quick: avoid uselessy reconstructing nodes
            continue
        mindices = [d for d in i.uindices if d.is_Modulo]
        groups = as_mapper(mindices, lambda d: d.modulo)
        i_org = i
        for k, v in groups.items():
            mapper = {d.origin: d for d in v}
            rule = lambda i: i.function.is_TimeFunction and i.function._time_size == k
            replacer = lambda i: xreplace_indices(i, mapper, rule)
            subs[i] = XSubs(replacer=replacer).visit(i)
        #     i = XSubs(replacer=replacer).visit(i)
        # subs[i_org] = i

    return Transformer(subs).visit(iet)

I think it boils down to whether the MFEs are fundamentally different or they're just triggering the very same bug through different constructs. In the former case, I'd like to have all the MFEs; in the latter case, just one would be fine.

I think we're dealing with the latter: we're triggering the same situation from different constructs. I think the problem is the current code does not expect more than one iteration loop at the same level with different modulo dimensions. Those MFEs make it happen with time.

I think you were on the right track with the initial patch, but yeah, we need to figure out why the Buffer tests would now break

That was actually my fault. When I change the flow of transformations to prevent them all to get the whole iet, I must assure the inner loop transformations remain cumulative, and not with respect to the same input, as I did before. It would also break with different time_order values in functions of the same operator.
That fixes it:
def _lower_stepping_dims(iet):
    subs = {}
    for i in FindNodes(Iteration).visit(iet):
        if not i.uindices:
            # Be quick: avoid uselessy reconstructing nodes
            continue
        mindices = [d for d in i.uindices if d.is_Modulo]
        groups = as_mapper(mindices, lambda d: d.modulo)
        i_org = i
        for k, v in groups.items():
            mapper = {d.origin: d for d in v}
            rule = lambda i: i.function.is_TimeFunction and i.function._time_size == k
            replacer = lambda i: xreplace_indices(i, mapper, rule)
            i = XSubs(replacer=replacer).visit(i)
        subs[i_org] = i

    return Transformer(subs).visit(iet)

@FabioLuporini, I opened the draft PR #1504 for your review.
The added test would result in an assertion error like the one shown below without this correction:
E           assert {t0, t0 + 1} == {t1, t0}
E             Extra items in the left set:
E             t0 + 1
E             Extra items in the right set:
E             t1
E             Full diff:
E             - {t1, t0}
E             + {t0, t0 + 1}


[9_VAE] About reparameterization

I have a question about reparameterization. My understanding is that z∼N(μ,σ) is random so it is indifferentiable, but ϵ in z=μ+σ⋅ϵ takes out the randomness which makes it differentiable. Is my understanding correct?

Yes, you are correct. By using the reparameterization trick, the randomness in ￼ is addressed. In ￼, where ￼, the randomness comes solely from ￼, which is sampled from a fixed distribution. This allows the gradients with respect to ￼ and ￼ to be computed, making the process differentiable.


Descriptions

Changes made by jacwah. Take a look and see if it is a good approach.

I think #402 should be included in this one

@Zomis #402 was what prompted me to do this refactoring in the first place :)

I do like #433 better than this one.


openai prompt format supported?

Hello (and first 'bravo' for all the Albert work!),
Is openai prompt format really supported ?
Looking in file pyalbert/prompt/prompt.py it seems managed by format_messages_prompt function, but when using the openai prompt_format, the following error occurs :
TypeError: format_messages_prompt() got an unexpected keyword argument 'add_generation_prompt'

Thanks in advance if you can help setting up a PoC with albert (i work for an OPSN, asked for the public API access, but my emails get ghosted :/ )

Hi @RomainLLC,
How did you raise this error ? The pyalbert code is not in this repo and is being refactored at the moment.

Hi @dtrckd ,
thanks for your answer, and yes sorry seems i opened the issue in the wrong repo :/
This error raised trying the "openai" prompt config param in prompt_config.yml. I also tried llama2-cpp / llama-cpp but answers are empty. Frustrating as all the bricks successfully run and communicate.

Closing this issue as : wrong repo + pyalbert refactoring being done.


new chart stable/mysqldump

Helps the user backup mysql databases to a persistent volume

Please use the mysqldump.chart named template and add app labels.

/assign

thanks @unguiculus I actually skipped setting an app label as I wasn't sure if it was appropriate due to this being purely a job/cronjob.  I'll go back and add it in.

Any news on this?
I'm really interested to undunrstand if the official charts will also allow us to PR ways to dump and backup databases.

/lgtm


fix: props is initialized but never used

The props variable which holds the authentication tokens from the external provider, is initialized in line 247 but never actually used. Changed line 269 to use it.
Fixes #26651

Change is just above How to add additional custom tokens

Public review  of the doc build:

download the HTML files
unzip
view HTML file in a browser.
For links outside the doc, remove the review. from URL.

@paviad  can you take a quick look at the public review or maybe just the image I posted?
Public review  of the doc build:

download the HTML files
unzip
view HTML file in a browser.
For links outside the doc, remove the review. from URL.

It looks good, print it! :)

@paviad much appreciated.
Thanks for the contribution. Be sure to check out your name as a contributor about the 3rd of next month on the What's new page in the Community contributors section at the bottom.


Change libuv.dll to a multithreaded one

System.Net.Libuv was deleted as part of https://github.com/dotnet/corefxlab/pull/2244.


Cant use python venv boto3 version (interaction w awsvault?)

Describe the bug
When using aws-vault and python and uv there's bad interaction between versions of boto3.
even though im using a uv venv, it still uses the nix store version of boto3, even though a version of boto3 in the venv is available.
which python -> venv
uv pip show boto3 -> venv version
When running the python client (venv) and trying to use boto3, it is using the version of the store.
Not sure if this is a devenv bug, but anyways im putting it here (maybe interactions with aws vault somehow?)
To reproduce
{ pkgs, lib, config, inputs, ... }:

{
  # https://devenv.sh/packages/
  packages = [ pkgs.git pkgs.aws-vault pkgs.yarn pkgs.awscli2];

  languages = {
    python = {
      enable = true;
      uv.enable = true;
    };
    javascript = {
      # For cdk
      yarn.enable = true;
      # For cameo-concierge
      npm.enable = true;
    };
  };

  # NOTE: giving issues because it loads environments with extra quotes
  # dotenv.enable = true;
  # dotenv.filename = ".env";
  difftastic.enable = true;
  cachix.enable = false;
  aws-vault = {
    enable = true;
     profile = "project"; # btw also doesnt activate profile
     package = pkgs.aws-vault;
   };

  enterShell = ''
  cat logo.txt
  '';
}

Version
1.0.8

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."


RSDK-3276/RSDK-3277: Update cartographer for data replay

Summary
This PR covers the following two tickets:

RSDK-3276: viam-cartographer should read from sensor even when use_live_data = false, and not wait 200 ms
RSDK-3277: Cartographer should keep polling for new data even when use_live_data=false

It also modifies an existing test for offline mode that was broken by my change.
Manual Testing
I tested with a dataset of about ~1000 images and confirmed all of the images were downloaded (by looking at the data directory) and fed into cartographer (by printing this out - technically all but the last one are fed in, which is expected given my implementation). I confirmed that the time taken to build the map is similar to offline mode (a couple seconds) and that the map is built correctly.

@EshaMaharishi you can hold off on this review for now as I realize there are still C++ tests that need to be fixed. My apologies!

@dmhilly no worries, sounds good!


[WIP] Add network and storage device support to LenovoSystem

This PR adds methods to the LenovoSystem class that retrieve details about network and storage devices.

Lint report for commit 1eb2659d3c6ad52413b2d73285ab7e8ab3a5cfaa:
wrapanapi/lenovo.py:

:bangbang: Line 29:101: E501 line too long (101 > 100 characters)
:bangbang: Line 30:101: E501 line too long (101 > 100 characters)
:bangbang: Line 371:101: E501 line too long (114 > 100 characters)
:bangbang: Line 376:101: E501 line too long (114 > 100 characters)
:bangbang: Line 388:101: E501 line too long (114 > 100 characters)
:bangbang: Line 393:101: E501 line too long (114 > 100 characters)
:heavy_exclamation_mark: Line 405:21: W291 trailing whitespace
:bangbang: Line 408:101: E501 line too long (110 > 100 characters)
:bangbang: Line 411:46: E272 multiple spaces before keyword
:bangbang: Line 415:101: E501 line too long (110 > 100 characters)
:bangbang: Line 418:52: E272 multiple spaces before keyword
:bangbang: Line 434:31: E711 comparison to None should be 'if cond is None:'

:scream: You might like to check the lint of your code :point_up:
No commit flaws detected.

CFME QE Bot

Lint report for commit 6fc173057adf48c45bea2b224858eb0418052216:
wrapanapi/lenovo.py:

:bangbang: Line 30:39: E131 continuation line unaligned for hanging indent
:bangbang: Line 32:39: E131 continuation line unaligned for hanging indent

Please, rectify these issues :smirk: .
No commit flaws detected.
CFME QE Bot

Lint report for commit 24a060029d869d79bec78e081bde7aaa62f0c01c:
wrapanapi/lenovo.py:

:bangbang: Line 30:44: E131 continuation line unaligned for hanging indent
:bangbang: Line 32:44: E131 continuation line unaligned for hanging indent

Please, rectify these issues :smirk: .
No commit flaws detected.
CFME QE Bot

@psav Could you look at this PR when you get a chance? Thanks

Moved back to RFR after merging #250 and since @skovic has added new commits.

@mshriver @bsquizz I think I've made all of your recommended changes. Please let me know if I missed anything. Thanks

@mshriver @bsquizz Is this PR ready to go? Any other changes needed? Thanks

It looks good to me, I approved a few days ago, it needs get approval from another reviewer, @mshriver should be able to take a look soon..

Just looking for additional documentation and a very slight code change (public methods) otherwise this looks great. @skovic please ping (@ - me) when you've added some documentation/comments and I can merge + release for your MIQ integration_tests PR.

@mshriver I added some comments to the code and made the new methods public. Please let me know if I missed anything. Thanks


BC 15.x Invoke-RestMethod causes Remote Server Error 401 not authorized

PS C:\Users\administrator> New-NavContainer -containerName bcsdbxmasterde -imageName bcinsider.azurecr.io/bcsandbox-master:de -accept_eula  -includeAL -updateHosts  -licenseFile \Swap\docker.flf -alwaysPull -auth Windows -Credential (get-credential -credential MyUser) -accept_outdated
NavContainerHelper is version <IP_ADDRESS>
Host is Microsoft Windows Server 2016 Standard - ltsc2016
Docker Client Version is 17.06.2-ee-7
Docker Server Version is 17.06.2-ee-7
Pulling image bcinsider.azurecr.io/bcsandbox-master:de-ltsc2016
de-ltsc2016: Pulling from bcsandbox-master
Using image bcinsider.azurecr.io/bcsandbox-master:de-ltsc2016
Removing C:\ProgramData\NavContainerHelper\Extensions\bcsdbxmasterde
Creating Container bcsdbxmasterde
Using license file \HP_KK\Swap\docker.flf
Version: 15.0.34648.0-de
Platform: 15.0.34329.0
Generic Tag: <IP_ADDRESS>
Container OS Version: 10.0.14393.3025 (ltsc2016)
Host OS Version: 10.0.14393.3025 (ltsc2016)
Using locale de-DE
Using process isolation
Disabling the standard eventlog dump to container log every 2 seconds (use -dumpEventLog to enable)
Files in C:\ProgramData\NavContainerHelper\Extensions\bcsdbxmasterde\my:

AdditionalOutput.ps1
license.flf
MainLoop.ps1
updatehosts.ps1
Creating container bcsdbxmasterde from image bcinsider.azurecr.io/bcsandbox-master:de-ltsc2016
a952d2c16c4c8c41a0d382bc21c2fd6e38f67cf8f4942c53801b1c0090de487c
Waiting for container bcsdbxmasterde to be ready
Initializing...
Starting Container
Hostname is bcsdbxmasterde
PublicDnsName is bcsdbxmasterde
Using Windows Authentication
Starting Local SQL Server
Starting Internet Information Server
Modifying Service Tier Config File with Instance Specific Settings
Starting Service Tier
Registering event sources
Creating DotNetCore Web Server Instance
Enabling Financials User Experience
Using license file 'c:\run\my\license.flf'
Import License
Creating http download site
Creating Windows user MyUser
Setting SA Password and enabling SA
WARNING: Caution: Your program license expires in 13 days.
WARNING: This license is not compatible with this version of Business Central.
Creating SUPER user
WARNING: Caution: Your program license expires in 13 days.
WARNING: This license is not compatible with this version of Business Central.
WARNING: Caution: Your program license expires in 13 days.
WARNING: This license is not compatible with this version of Business Central.
Container IP Address: 172.xx.xxx.xxx

Container Hostname  : bcsdbxmasterde
Container Dns Name  : bcsdbxmasterde
Web Client          : http://bcsdbxmasterde/BC/
Dev. Server         : http://bcsdbxmasterde
Dev. ServerInstance : BC
Files:
http://bcsdbxmasterde:8080/AL-15.0.34329.0.vsix
Initialization took 217 seconds
Ready for connections!
Reading CustomSettings.config from bcsdbxmasterde
Creating Desktop Shortcuts for bcsdbxmasterde
Downloading app: BaseApp
Url : http://172.xx.xxx.xxx:7049/BC/dev/packages?publisher=Microsoft&appName=BaseApp&versionText=&tenant=default
Invoke-RestMethod : Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
In C:\Program Files\WindowsPowerShell\Modules\navcontainerhelper\<IP_ADDRESS>\AppHandling\Get-NavContainerApp.ps1:101 Zeichen:5
Invoke-RestMethod -Method Get -Uri $url @AuthParam -OutFile $appF
+ CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

This is likely because of Windows Authentication.
if you switch to userpassword, it probably just works.
I will try this with Windows Auth.

This should work, I did the exact same last night, also with Windows authentication.
Did you specify the -UseDefaultCredentials switch for the Invoke-RestMethod call?

Yes, the Get-NavContainerApp should do this
https://github.com/microsoft/navcontainerhelper/blob/master/AppHandling/Get-NavContainerApp.ps1
Kai, did you provide the hosts windows credentials when creating the container?

Yes, the first thing that comes up is this window where I type these in:

Solved:
If I use my own personal credentials is works.

At first created the container with a commonly shared user that we use internally so that anyone in the firm can access the container if required with a shared login, but this user is not part of the active directory. In older BC versions this method works, but apparently not anymore.

Yes, so using Windows Auth. you need to use the currently logged on credentials.


add PT-BR language support

I'm closing this to open a new one following the contributing instructions.


Implementing Admin Panel

The creation of admin panel will make the data more dynamic and help the admin to apply all CRUD application related to the user, the rental data related to it,
Moreover it will be made in nextJS itself so it will be utilising the features of NextJS more efficiently
Please assign this task to me.
And label this as Gssoc-ext
@SaranshBangar

@0vai5 You can proceed with it. Please remember to -

Send a photo here of of the new design before raising a PR
Follow the proper file structure
Star the repo :)

All the best!

Hey @SaranshBangar,
After reviewing the requirements, I believe an admin panel isn't necessary, as the project mainly needs a backend to handle user data, posts, and a functional registration and authorization system. Let me know if I can proceed with implementing the backend.


SubHeader

Closes #26

@WieFel Can you please document BackdropSubHeader. I tried but failed to describe it properly.

I looked at it and I think it is good. I have two improvements though:

There should be a bool to not show the subHeader when the FrontPanel is visible
There should be a bool to hide the FloatingActionButton when the BackPanel is visible (since it overlays sometimes)

I just implemented both of my proposed changes here

@felixwortmann We are planning to give callbacks in #30 so that this changes could be handled by user itself.

@WieFel Please review this PR.

@daadu that might be an even better way to handle this.

@daadu still the things that I commented on are missing.
Should I make those changes?

LGTM.
What about you ? @WieFel  @felixwortmann

Same

This feature has landed in v0.3.4 in pub.dev.


Invalid call. Nonexistent 'Int' constructor

Godot version
3.2.3.stable
System information
Arch Linux aarch64, GLES2
Issue description
I'm developing a Progressbar95 clone in Godot and this error pops up
Steps to reproduce
var systemlist = [
	"Progressbar 3.14",
	"Progressbar 95",
	"Progressbar 98",
]
onready var itemList = get_node("ItemList")
func ready():
	for i in range(systemList):
		itemList.add_item(systemList[i])
		itemList.set_item_tooltip_enabled(i, false)

Minimal reproduction project
No response

The error is a bit vague, but you can't make range from a node.


Refactor MemoryDB and ElastiCache e2e tests to use ACK default testing framework

Currently, the MemoryDB and ElastiCache controllers rely on a custom test framework for their end-to-end (E2E) tests. However, this approach presents some challenges for maintaining the custom libraries alongside frequent runtime and security patches.
To speed-up the release process, and simplify patching these two controllers, we can consider re-wrting the e2e tests using the common acktest library. This way it would be easier for the ACK maintainers and contributors to navigate and debug blocked release PRs.

Indeed @jose-fully-ported
/close


Can't complete alchemy "Essentia Smelting" research

Unable to craft smelter block for some reason? Prior research remains incomplete (metallurgy) due to not having completed the forbidden research. Is this the cause or have I missed something?

You CAN actually craft the smeltery at this point, even though it tells you otherwise.
Recipe is:
Brass Plate, Crucible, Brass Plate
Cobble, Furnace, Cobble
Cobble, Cobble, Cobble

BTW, I just want to throw it out there that I am very appreciative of proper beta testing like this. Most people just seem to use the beta access for a way of previewing TC6  :p


samples: Added README File for ethernet Sample Application

Tittle:
Add README File for Ethernet Sample Application (#27805)
Description:
This pull request addresses issue #27805 by adding a README file to the Ethernet sample application. The README provides essential information and usage instructions for the Ethernet sample.
Changes Made:

Added a README.md file to the samples/boards/esp32/ethernet directory.
Included detailed documentation on how to build, configure, and test the Ethernet functionality on an ESP32 device using Zephyr RTOS.

Related Issues:
Closes #27805
Additional Notes:

Please review and provide feedback.
Let me know if any further changes or adjustments are needed.

Thank you @harshavardhan-b20 for your contribution, well done! Please address some of the compliance issues, such as signing off your commit.  Also, I'm not sure if the README files should be restructured text instead of markdown since most of them are .rst. I couldn't find this info in the contribution guidelines.


Register ordering, byte-based sizes, OAM additions, general cleanup

I'm not a fan of the 'o'-named register EQUs (for offset), but couldn't think of anything else.

I have a local change (not committed yet) related to the bootup values:
;***************************************************************************
;*
;* CPU values on bootup (a=type, b=qualifier)
;*
;***************************************************************************

BOOTUP_A_DMG    EQU $01 ; Dot Matrix Game
BOOTUP_A_CGB    EQU $11 ; Color GameBoy
BOOTUP_A_MGB    EQU $FF ; Mini GameBoy (Pocket GameBoy)

; if a=BOOTUP_A_CGB, bit 0 in b can be checked to determine if real CGB or
; GBA in GBC mode
BOOTUP_B_CGB    EQU %00000000
BOOTUP_B_AGB    EQU %00000001

Thoughts on including this in the PR? Thoughts in general?

I've included them (plus OAM changes) in the PR for commenting there.

Bump :)

Suggestion: BOOTUP_B_OTHER -> BOOTUP_B_AGB, because you can summarize all of the GBA platforms with that.

Wow, this went a long way. I like the changes.
Thank you for sticking with this, @BlitterObjectBob and @ISSOtm !


Space after an open parenthesis

Having a space after the opening parenthesis causes failure.
background-color: rgba( $mainBlue, 0.3 ); // with space after (.
resutls in
background-color: rgba( #2f5572, 0.3 )
background-color: rgba($mainBlue, 0.3 ); // no space after (.
results in
background-color: rgba(47,85,114, 0.3 ) // what happened to the semicolon?

Added a possible fix in #26. cc @seaneking


Fix launcher unit tests not passing because of containers

Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

Description of the bug
If #1238 gets approved, the launcher module will be almost fully operative.
But there will be some tests not passing.
Test not passing.

==================================================== short test summary info =====================================================
FAILED tests/test_launcher.py::test_invalid_mode - IndexError: list index out of range
FAILED tests/test_launcher.py::test_license_type_keyword - Failed: DID NOT WARN. No warnings of type (<class 'UserWarning'>,) w...
FAILED tests/test_launcher.py::test_license_type_keyword_names - AssertionError: assert 'Ansys Mechanical Enterprise Solver' in...
FAILED tests/test_launcher.py::test_license_type_additional_switch - Failed: DID NOT WARN. No warnings of type (<class 'UserWar...
==================================== 4 failed, 19 passed, 5 skipped, 1094 deselected in 7.11s ====================================

They need further investigation (probably access to the license server?)
Also the can_start_instance needs to be removed. It has been put there because get_start_instance needs to be re-worked.
Steps To Reproduce
N/A
Which Operating System are you using?
Linux
Which Python version are you using?
3.8
Installed packages
N/A

Closing this because #1238  has been abandoned.


【Celo Gallery】Celo Toolkit - web interface for managing Celo accounts

Description
Celo Toolkit is the web interface for managing Celo accounts. It will lower the barrier for developers and newbies. Phone number or app downloads are not necessary.
It's LIVE.
Github
Tested
No tests. It's a web portal (user interface) to make it easy for new developers and newbies.
Other changes
No
Related issues
No.
I've dapp experience on Ethererum, EOS, Tron. When I develop with the current Celo Network SDK, I still found few things frustrated.

Celo app cannot be downloaded in my country, and it took me some time to get around this.
The process of invitation code and Celo registration is not stable in Asia area.

It took me an hour but it might take more time for developers new to blockchain. So we build the web wallet help the reduce the cost for celo developers or newbies.
Backwards compatibility
It's a new feature.

@nategraf Would you mind having a look on this?
It's a PR from Celo Camp Community :)

Greetings from MugglePay@Celo Camp! We are building a web toolkit with celo sdk. It's open sourced and live. We are contributing to the Celo apps. @prasincs @jeanregisser @mrsmkl @ashishb @nategraf
Live: http://celo.mugglepay.com/
Github: https://github.com/MugglePay/celo-toolkit

@critesjosh Thanks for the review.
I've removed the changes in main.md and added only to the Dapp Gallery in the other PR. Close this thread as DUPLICATE.
https://github.com/celo-org/celo-monorepo/pull/3726/files


[master] Upgrade to latest dependencies

Produced via:
./hack/update-deps.sh --upgrade
./hack/update-codegen.sh

/cc we don't use Prow
/assign we don't use Prow

Codecov Report

Merging #114 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #114   +/-   ##
=======================================
  Coverage   96.18%   96.18%
=======================================
  Files          16       16
  Lines         446      446
=======================================
  Hits          429      429
  Misses         15       15
  Partials        2        2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 98b428d...19ed363. Read the comment docs.


Refactor extensions

Related to:

#5850

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Toomsie

Related issue

What changes does this PR do?
Changed my name again. I guess
Screenshots (If any)
Questions

@toomsie Are you sure this is correct? Because there was a conflict with "David Xuy" as your name, if you can confirm this once, we can merge this PR.


modify cdc owner & scheduler

What problem does this PR solve?
modify cdc's owner & scheduler codes for tikv cdc
What is changed and how does it work?
/cdc/cdc/owner files and /cdc/cdc/scheduler files
Code changes

Has exported function/method change
Has exported variable/fields change
Has interface methods change
Has persistent data change
No code

Check List for Tests
This PR has been tested by at least one of the following methods:

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Possible performance regression, WHY: TBD
Increased code complexity, WHY: TBD
Breaking backward compatibility, WHY: TBD
No side effects

Related changes

Need to cherry-pick to the release branch
Need to update the documentation
Need to be included in the release note
No related changes

@pingyu PTAL~


Add OS_VERSION redaction to pixel param removal

Task/Issue URL: https://app.asana.com/0/488551667048375/1206484244032140/f
Description
Add os version to redaction list
Steps to test this PR
QA optional, code review and test pass

develop

#4171   👈

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @aitorvs and the rest of your teammates on  Graphite


Add manual example on includes

Just had a student burn a whole bunch of time - turns out he was using include('Mailchimp.php'); which worked locally, but we needed include('./Mailchimp.php'); on his server.
Hopefully this helps someone in the future!

Thanks Wes!


Can't save screenshot files when the file name includes a backslash

What is your Scenario?
Include in a test name a backslash.
For example: 'Verify that we can select something from the list apple/house/banana'
What is the Current behavior?
In our tests, we take screenshots (png files) when they fail, and many of our tests include a backslash.
When testcafe tries to save the file, the “/” is being broken into another dir and when our plugin tries to upload the file it doesn't find it.
What is the Expected behavior?
Testcafe should take into account that every character in the test name is a part of the name.
What is your public website URL? (or attach your complete example)
no public website URL
What is your TestCafe test code?
Include in a test name a backslash.
For example: 'Verify that we can select something from the list apple/house/banana'
Your complete configuration file
No response
Your complete test report
No response
Screenshots
No response
Steps to Reproduce
Include in a test name a backslash.
For example: 'Verify that we can select something from the list apple/house/banana'
TestCafe version
1.18.1
Node.js version
v16.14.0
Command-line arguments
testcafe chrome --debug-on-fail
Browser name(s) and version(s)
No response
Platform(s) and version(s)
No response
Other
No response

Special characters like /:*?"<>| on Windows are forbidden. This means that TestCafe cannot create files with such symbols in their names on Windows anyway.
While it is possible to use '/' on Linux and OS-X, it is still highly not recommended to use it in file naming.
I advise against backslashes in test names. However, if using such symbols on macOs and Linux is important for your use case, you can modify TestCafe's open source behavior - your PR is welcome. The entry point is the getPath method.


Add worldmap tooltip to Ruins of Ullek mine and rare trees #15415

Added the mining location and the rare tree location to worldmap plugin.
Fixes #15415

23d74b5 is second commit. fixed the indentation on line 192 of MiningSiteLocation.java

This looks like a duplicate of #15271, which is still waiting for review.