ASWebAuthenticationSession.prefersEphemeralWebBrowserSession to false

set prefersEphemeralWebBrowserSession to false.
The behaviour is different from android implementation where the cookies/login information is persisted between getAuthorizationCode flows.
It means on android the second time the user doesn't have to enter their username/password, while on iOS the user has to do it every time.

Thinking again about this, it might be even better to offer a parameter for ios targets.

Hi, thanks for your PR!
You're right, the behaviour is currently not the same on both platforms. This should be fixed, the default should be the same, but I'd also like to have a parameter (just like useWebView in the Android Factory).
One of my use cases required epheremal session = true, and in fact, this is why useWebView exists (which clears all cookies to have the same experience).
I need to sanitize this part, too. useWebView on Android should not automatically behave like an epheremal session by default.

closing this PR in favour of https://github.com/kalinjul/kotlin-multiplatform-oidc/pull/29


create contour plots with quadrupole deformed potential for given set of parameters. export to pdf

The single-particle potential Vsp parametrized for beta, gamma was properly implemented in this commit


Error 522 - Maven could not get resource

https://mvn.mchv.eu/repository/mchv/it/tdlight/tdlight-java/3.171.43/tdlight-java-3.171.43.pom
It seems your maven has fallen, I can't download the dependency.

Fixed


vanilla install, cannot find str.zig when running rocLovesZig.roc

am following the installation instructions, got this far:
👉  ./roc examples/platform-switching/rocLovesZig.roc
🔨 Rebuilding platform...
An internal compiler expectation was broken.
This is definitely a compiler bug.
Please file an issue here: https://github.com/roc-lang/roc/issues/new/choose
thread '<unnamed>' panicked at 'cannot find `str.zig`. Check the source code in find_zig_str_path() to show all the paths I tried.', crates/compiler/build/src/link.rs:242:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'Failed to (re)build platform.: Any { .. }', crates/cli/src/build.rs:342:46

zig is installed:
👉  ll `which zig`
lrwxrwxrwx 1 harry harry 38 Dec  7 05:22 /home/harry/.local/bin/zig -> /home/harry/zig-linux-x86_64-0.9.1/zig

Hi @hjwp, I'll look into this error and set up some tests to prevent from happening again in the future.

The fix will be in tomorrow's nightly @hjwp :)


Error building on VCPKG 2022 x86_64... trying build on #544

Hello, libjxl community. I have a problem of build failed on libjxl.
I tried build libjxl of cjxl and djxl, I build all using keyboard shortcut CTRL + SHIFT + B.
During building, I got my build all failed. See the error log:
https://pastebin.com/wkKFqWPx
Visual Studio version: 2022 (17.10.2)
Windows (winver): Windows Server 2022 (Version Dev OS Build 22483.1011)
System type: x86_64
Clang version: 13.0.0
VCPKG version: 2022-03-09-1affd32f93b299d5a907816c328ca3ededb73a7e
Cmake version: 3.23.0-rc2
Cmake configure and generation finished log:
https://pastebin.com/PxF72Uzi
Is there any possible to fix?
I followed the docs of libjxl and vcpkg on Github.

Install vcpkg on C:/src/vcpkg, used .bat Microsoft/vcpkg
Install packages with vcpkg and integrated with Visual Studio 2022
Git cloned libjxl with checking out code.
Open libjxl folder with Visual Studio, right clicked CMakeLists.txt, changed from debug to Clang Release x64
Clicked edit json and saved file before editor pop up... replaced json with JSON Example
Waiting for configuring and generating in Cmake. https://pastebin.com/PxF72Uzi
I pressed F7, but nothing happened. I pressed CTRL + SHIFT + B as Build all.
Log file error: https://pastebin.com/wkKFqWPx

Update 25th February 2022 18:53 (AEDT)
I used configure, build and install and it worked without GUI.
Configure:
cmake -Bbuild -H. -A x64 -DBUILD_TESTING=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=C:/Users/Administrator/Downloads/libjxl/prefix -DCMAKE_TOOLCHAIN_FILE=C:/src/vcpkg/scripts/buildsystems/vcpkg.cmake -DJPEGXL_ENABLE_OPENEXR=OFF -DJPEGXL_ENABLE_PLUGINS=OFF -DJPEGXL_ENABLE_TCMALLOC=OFF -DJPEGXL_ENABLE_VIEWERS=OFF -DVCPKG_TARGET_TRIPLET=x64-windows-static -DJPEGXL_BUNDLE_GFLAGS=ON

Build:
cmake --build build --config Release

Install:
cmake --build build --config Release --target install

I will test sec if EXIF works...

Message to @jonsneyers
Nope not quite success, the issue is compiler crash since effort 5 to 9. But less 5, three and four effort made success, others are not tested yet. I tried minimum threads, but it did not work from effort 5 to 9.
cjxl INPUT.jpg RESAMPLING2E4.jxl -e 4 -d 3 --resampling=2 -v
JPEG XL encoder v0.7.0 2ddc687 [AVX2,SSE4,SSSE3,Scalar]
Read 8000x6000 image, 179.9 MP/s
Encoding [Container | VarDCT, d3.000, cheetah | 904-byte Exif], 16 threads.
Compressed to 660294 bytes (0.110 bpp).
8000 x 6000, 10.03 MP/s [10.03, 10.03], 1 reps, 16 threads.
Average butteraugli iters:       0.00
Total layer bits headers          0.001837%        97
Total layer bits TOC              0.057994%      3063
Total layer bits quantizer        0.000284%        15
Total layer bits quant tables     0.000038%         2
Total layer bits order            0.004147%       219   [c/i:  1.00 | hst:       1 | ex:       5 | h+c+e:      28.255]
Total layer bits DC              23.903302%   1262467
Total layer bits ControlFields    0.003976%       210
Total layer bits AC               0.279842%     14780   [c/i: 97.00 | hst:    1829 | ex:       0 | h+c+e:  494209.810]
Total layer bits ACTokens        75.623182%   3994083
Total layer bits modularGlobal    0.107109%      5657   [c/i: 30.00 | hst:     707 | ex:       0 | h+c+e:  149859.779]
Total layer bits modularTree      0.018290%       966   [c/i:  2.00 | hst:      20 | ex:      28 | h+c+e:     118.717]
Total image size              5281559   [c/i:130.00 | hst:    2558 | ex:   14554 | h+c+e:  658736.686]
Including container: 661250 bytes (0.110 bpp).
Allocations: 730 (max bytes in use: 1.547541E+09)

Could you check that this problem still exists at the current head?

We have replaced both cjxl and djxl with new versions using the API, so I am closing this now. Please reopen if you still experience problems.


Add option to proxy carbon-react

What will this achieve?
Satisfy teams' requirement to have a single way to install both carbon-react and ibm-cloud-cognitive.

How will success be measured?
Internal testing, as well as production team confirmation/test.

Additional information
Contacts for Security and Cloud PAL who have achieved this in their libraries are @SimonFinney and Timea Stein, respectively. We should be in sync.
Goal for this is by end of Q2.

A convenience proxy is possible via something like export * from 'carbon-components-react', but I can't recommend pursuing this much further than this as while the concept was beneficial for Security in scaling Carbon adoption initially, it added additional maintenance and support overhead, coupled the packages closer than they needed to be, and warped consumer mental model of the Carbon ecosystem.

Agree with Simons comment regarding the appropriateness of doing this.
What we have done instead is establish a release pattern that keeps versions in sync so that multiple packages can be easily combined.


_BitScanForward64 is listed as supported on ARM

The definition of _BitScanForward64 doesn't exist for ARM builds, even though the docs claims so. My guess would be that it exists for ARM64, but not for ARM...

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

ID: 8b9a85d1-fd99-7639-14ca-78f241efb69d
Version Independent ID: 6f8cda00-2028-7de7-0afe-a7b8835b4e1c
Content: _BitScanForward, _BitScanForward64
Content Source: docs/intrinsics/bitscanforward-bitscanforward64.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

This article doesn't list _BitScanForward64 as supported on ARM:
https://docs.microsoft.com/en-us/cpp/intrinsics/arm-intrinsics?view=vs-2019

Checking further, according to intrin0.h, this is only defined for X64 and ARM64. So it seems the docs are indeed wrong here.

@kusma
Thanks for looking into that. It turns out that there are many other intrinsics that are incorrect in similar ways. I've made an update that should address those, and it will appear in a couple of days.


Clean up log functions

We first need to fix https://github.com/gtk-rs/glib/issues/616.
cc @sdroege @EPashkin

As reference, here's the C code:
#include <glib.h>
#include <stdio.h>

#define G_LOG_DOMAIN "osef"

void log_handler(const gchar *log_domain, GLogLevelFlags log_level, const gchar *message, gpointer user_data) {
  printf("[%s:%d] [%s]\n", log_domain, log_level, message);
}

int main() {
  g_log_set_handler(G_LOG_DOMAIN, G_LOG_LEVEL_MASK, log_handler, NULL);
  g_log(G_LOG_DOMAIN, G_LOG_LEVEL_INFO, "hello!");
  g_log(G_LOG_DOMAIN, G_LOG_LEVEL_DEBUG, "hello!");
  return 0;
}

compiled with:
$ gcc test.c `pkg-config --cflags glib-2.0` `pkg-config --libs glib-2.0`

As reference, here's the C code:

Works fine for me without crashes, warnings or valgrind warnings. Trying the Rust code now.

Updated!

Updated!

You want to run cargo fmt, otherwise we're good here now.


:tada: Add openvasxml parser #8761

See linked Issue.

Hi @Maffooch,
why is this PR failing?

@manuel-sommer I thought it might the the chrome / chrome driver issue that cropped up earlier today but it looks like it's something else.
I went ahead and re-kicked the tests to see if it was a transitory issue or something else.

@manuel-sommer Yup, it's the chrome/chrome-driver issue. There's a PR to fix this happening now.

Thank you for investigating

@manuel-sommer OK, we got the Github actions happy again. Mind rebasing so those tests will run correctly (and pass)

@mtesauro, @Maffooch, @devGregA ready to review.

Something is up with the commit history here. Please take a look

Now, everything shoule be fine @Maffooch. Let's squash the commits when we merge this MR

@mtesauro please review

@blakeaowens and @devGregA please approve

@cneill could you please approve this PR?

@damiencarol could you approve this PR?

Can you merge it @grendel513 ?


Remove "Gradle" from CI job step names

We only build with Gradle, so we don't need that info in the step name.  No code affected.

No, this is just changing job step names, not job names, fortunately


Minor spelling fix in Build/scripts/run_build.ps1

Just a small spelling update/fix for a comment in run_build.ps1 :)

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


Can Selenium test scripts in Python work with EasyRepro?

Hello, can test scripts written in Python or Java work with EasyRepro framework?
Or should the test scripts be written in C#?
Thank you for your time and guidance

up


Update TPIE to latest version

One ought to make unit tests also run on changes to the external folder.


PM: Add serial suspension

-LOGUART need to be suspended before entering sleep
-Added suspension logic in serial
TBD: Check for MICOM UART port

@edwakuwaku I see the hang-up behavior after wake-up after applying this commit as well.
I pulled the latest commit, applied this PR as a patch, built hello_8M config, flashed and booted the board.
The logs stop as described in https://github.com/ziyik/TizenRT/pull/1#issuecomment-1765779336
I suspected it may be because of connection problems with Windows Virtual Box so I tried on Physical Linux machine, but unfortunately behavior remains same.
I am using 15,00,000 baud rate with 8-N-1 stop bits.

Is the difference in our observations due to difference in board versions, or something else?

It is too difficult to make any conclusion at this point of time, but there is a few experiment that you might want to give it a try.

Change another UART JIG to try
Erase the flash before downloading the image

Dear @amogh-samsung ,
We have verified with BLE Adv as wakeup interrupt source, it is working fine on our side.
PR: https://github.com/ziyik/TizenRT/pull/3
For this PR, it is a workaround fix for a hardfault if there is any operation being executed at PM_SLEEP state, a hardfault will occur, and it seems to be happening from kernel which the sched module is trying to remove a tcb but somehow ntcb is already NULL at the time being.
Could you help to take a look on our fix? So that we could bring the discussion further.
Attached figure is the hardfault snippet:

Thank you~

Dear @amogh-samsung ,
May I know what is the situation on your side? Is the hang issue resolved?
Thank you.

Dear @amogh-samsung ,
I have tested the EVB with using both our own trace tool and tera term, I am still unable to reproduce your situation.
We currently suspect that the problem might be coming from the board, we will try with more other evb and see whether the hang is reproducible.
Thank you.

Hi @edwakuwaku
Sorry for the delayed response and thanks for the update.
I will try out a few more scenarios and get back to you after some time please.
As of now I have tried with 2 different EVBxJIG pairs and on different machines.
Hence, I want to ask you again, maybe our boards are different versions or something like that?

Hi @amogh-samsung ,
I have reproduced your situation with another EVB, we can eliminate the possibility of UART JIG as problem source.
I tried 3 EVB in total, 2 is samsung evb, and one is our own evb, and both the samsung evb we received is the same batch, but only one is working, and our own evb is also hanging.
This situation is very unusual, maybe I should investigate on the hardware part of it.
I will update you again if there is any progress.
Thank you.

Hi @amogh-samsung ,
Could you share with us the download time taken for downloading the images to the EVB?
Thank you.

Hi @amogh-samsung ,
Could you share with us the download time taken for downloading the images to the EVB?
Thank you.

Approximate download times
km4_boot_all -> 5 secs
kernel trpk -> 45 secs
bootparam -> 1 sec

Hi @amogh-samsung ,
Thank you for the information. We have conducted some long run for power save throughout the weekend, I will share the logs with you via email. For the hang issue on other boards, we are still investigating and trying to come out with some solution to compromise.
Thank you.

Hi @amogh-samsung ,
I think as the file size is too big (~41Mb), it has been rejected by your internal system. Please let me know how should I share the file with you if you need it.
Thank you!

Hi @amogh-samsung ,
There is some fix that might be able to resolve the hang issue you are facing.
Thank you~

Hi @amogh-samsung ,
I think as the file size is too big (~41Mb), it has been rejected by your internal system. Please let me know how should I share the file with you if you need it.
Thank you!

You can share a google drive link with me for viewing

Hi @amogh-samsung ,
There is some fix that might be able to resolve the hang issue you are facing.  We have tried some other boards, some of the boards which is failing previously, seems to be working fine now. But there is still some EVB facing the same issue. I have tried on 3 8th gen EVB and 1 4th gen EVB, 1 RTK EVB. Results: 1 8th gen EVB, 1 4th gen EVB and 1 RTK EVB will not hang 2 8th gen EVB faced hang
Thank you~

@edwakuwaku Sorry for being the bearer of bad news, I tried with 2 boards, both of them still hang up after
INFO:    ARM GICv2 driver initialized
HEAD @ 4efc0f42b5c9829fe5c2d502a27a330dabd5435b

Hi @amogh-samsung ,
Here is the link: https://drive.google.com/file/d/1Va7yBKLQYPV1lO9ZzlDZx1Ury1IFC6C7/view?usp=drive_link

Hi @amogh-samsung ,
There is some fix that might be able to resolve the hang issue you are facing.  We have tried some other boards, some of the boards which is failing previously, seems to be working fine now. But there is still some EVB facing the same issue. I have tried on 3 8th gen EVB and 1 4th gen EVB, 1 RTK EVB. Results: 1 8th gen EVB, 1 4th gen EVB and 1 RTK EVB will not hang 2 8th gen EVB faced hang
Thank you~

@edwakuwaku Sorry for being the bearer of bad news, I tried with 2 boards, both of them still hang up after INFO: ARM GICv2 driver initialized HEAD @ 4efc0f42b5c9829fe5c2d502a27a330dabd5435b

Sorry for the hang issue, we are still trying to conduct more test on different boards, this situation is a really weird case and I hope for the understanding from you and your team. We are still trying to figure out some solutions to compromise with such cases, at least to help you move on further to verify the power save feature.
Thank you very much!

Hi @amogh-samsung ,
Here is the link: https://drive.google.com/file/d/1Va7yBKLQYPV1lO9ZzlDZx1Ury1IFC6C7/view?usp=drive_link

Hi @amogh-samsung ,
There is some fix that might be able to resolve the hang issue you are facing.  We have tried some other boards, some of the boards which is failing previously, seems to be working fine now. But there is still some EVB facing the same issue. I have tried on 3 8th gen EVB and 1 4th gen EVB, 1 RTK EVB. Results: 1 8th gen EVB, 1 4th gen EVB and 1 RTK EVB will not hang 2 8th gen EVB faced hang
Thank you~

@edwakuwaku Sorry for being the bearer of bad news, I tried with 2 boards, both of them still hang up after INFO: ARM GICv2 driver initialized HEAD @ 4efc0f42b5c9829fe5c2d502a27a330dabd5435b

Sorry for the hang issue, we are still trying to conduct more test on different boards, this situation is a really weird case and I hope for the understanding from you and your team. We are still trying to figure out some solutions to compromise with such cases, at least to help you move on further to verify the power save feature.
Thank you very much!

@edwakuwaku We understand and appreciate your efforts, please keep us updated :)

Hi @amogh-samsung ,
Here is some quick updates. Despite of the hang issues on several boards, we have verified with MICOM UART as wakeup interrupt source, using EVB which is not facing hang issue.
Thank you.

Hi @amogh-samsung ,
There is a new commit which seems to fix the hang issue, can you checkout this commit and try? https://github.com/Samsung/TizenRT/commit/306ad982f9023d076e0cec3edd3b441378dc9352
This can fix the hang issue I am facing on some of the evb on my side, hope it could fix yours too.
Actually in assembly layer, the system has already faced crash, but as in we just come back from sleep mode, it is still in the phase for restoring the registers, so it will just hang instead of crash and dump the systems logs, which made it more difficult to locate the rootcause. I will check more on why it is resulting crash on some of the evbs.
Thank you~

Hi @amogh-samsung ,
That scenario is common, as I have set the interrupt count to run a fixed amount of sleep/wake cycle. You may check it from amebasmart_idle.c~ Other than the hang, the main point is too confirmed that the tash is also working fine on your side~ When the sleep/wake cycle has stopped as per your observation, you may try to input any command, it will go back to normal, and do state transition again.
Thank you~

Hi @amogh-samsung ,
Can I have a quick update of the status on your side?
Here is some status update from our side.
Recently when we are trying to add in some other driver modules (such as wifi) into the whole system (pushing forward to mimic actual scenarios). We found that the workaround we provided will cause some memory misalignment issue happening, resulting system crash. So, we are trying to resolve this issue at the highest priority, as in the later stage, we will expect a more complicated scenario coming in during the real application.
Additionally, this part is closely related to system architecture, which in our case is (cortex-A32), and I am checking back to the armv7-A arch codes from Nuttx, which some of the assembly operation regarding system registers has to be revised accordingly to be compatible with A32 core.
Please share with us if you have any idea on this.
Thank you~

Hello @edwakuwaku , I have been on leave for a couple of days due to sickness.
No new updates from my side. As you mentioned and we observed, the PM module is working fine after you suggested some changes in the assembly code.
Please let me know if you want me to look into something specific.

Hello @amogh-samsung ,
I hope you have recovered well through the past few days.
For this crash issue due to the assembly operation, I am checking through the armv7-A arch codes, although the A32 chip can backward compatible with v7-A family. But down to system register layer, we still have to follow cortex-A32 specification.
For the time being, I heard that Samsung application layer will also register to the PM domain. So, I will prepare a guide for that, and also the PM logic workflow together in a PPT. I will share a problem we have found and the workaround fix, that problem seems to be related to PM module from Nuttx. The rough description for the problem is that when the state drop to PM_STANDBY, PM_SLEEP, if we are going to execute some operations at those states, it might cause a crash. And after checking, it seems like there is an assert happening from the tcb part. The workaround is to create a task to execute the required operation, to avoid the tcb to be empty, which it was trying to clean something from empty block.
I will provide the findings together, I hope you could help to check on that matter for the time being if you have the time to do so~
Thank you.
Best Regards,
Edward.

Hi @amogh-samsung ,
I have shared the PPT in the email loop, but after considering, I didn't share the crash problem happening as mentioned above. It is because it might not be that high priority to check that since we have stable workaround for that at the moment. But, if Samsung App face such condition when undergoing some operation during PM states (in the callback API), we should put some effort to check this problem by then.
Thank you~

Hi @edwakuwaku
One point of information. It may not be suitable to start new operations from the idle_thread as calling blocking functions within the operations from here can lead to crashes (If current thread is blocked, context cannot be switched to any other thread since current thread i.e. idle is the only thread). This might be why you observed a crash.
Also, I would like to understand what exactly you refer to by Samsung App (maybe which layer exactly, wifi/ble manager, or PM module control flow in idle.c?). I understand that all the layers above yours could be App for you, and there has been discussion about Samsung App being able to control SLEEP behavior of board.

Hello @amogh-samsung ,
This crash is not only observed in the idle loop, when there is a state change ongoing, the module will go to check through all the registered callback structures, and if there is operation needed to be executed, it might also face crash. Do you mean that anything starting from the idle loop will have the possibility to face such condition (as there are included in the idle loop thread)?
(ie. pm_changestate.c -> rtk_bt_power_control.c)
Basically the codes under path os/arch/arm/amebasmart should be controlled by us, and also os/board/rtl8730e/src/component, remaining level other than these few would be out of our scope. Definitely the usage of PM_RELAX, PM_STAY, PM_ACTIVITY should be utilized by the Application level to control the PM behavior. The Samsung App are referring to the upper layer applications (perhaps for the apps in the loadable_apps config?), for the wifi/ble/serial, these can be controlled at driver layer, so it might not be necessary to change anything from you side.

Hi @edwakuwaku
Thankyou for the update
Could you share the crash logs and an explanation of the crash scenario via mail please? If we have any insights, we will share with you.
I understand the second point above, thankyou.

Hi @amogh-samsung ,
Here is some quick updates. Despite of the hang issues on several boards, we have verified with MICOM UART as wakeup interrupt source, using EVB which is not facing hang issue.
In conclusion, 3 types of wakeup source which are timer, uart, and ble adv has been verified from our side. I will keep you posted with the hang issue.
Thank you.

Hi @amogh-samsung ,
Sorry for informing, we found that there is some issue when verifying using PA4, PA5 for MICOM UART as wakeup source, we are checking it at the moment, and will keep you posted. I apologize again for sharing this information.
Thank you.

Hi @edwakuwaku, thankyou for sharing the information.
Please keep us posted with any further updates.

Hello @amogh-samsung ,
This crash is not only observed in the idle loop, when there is a state change ongoing, the module will go to check through all the registered callback structures, and if there is operation needed to be executed, it might also face crash. Do you mean that anything starting from the idle loop will have the possibility to face such condition (as there are included in the idle loop thread)? (ie. pm_changestate.c -> rtk_bt_power_control.c)
Basically the codes under path os/arch/arm/amebasmart should be controlled by us, and also os/board/rtl8730e/src/component, remaining level other than these few would be out of our scope. Definitely the usage of PM_RELAX, PM_STAY, PM_ACTIVITY should be utilized by the Application level to control the PM behavior. The Samsung App are referring to the upper layer applications (perhaps for the apps in the loadable_apps config?), for the wifi/ble/serial, these can be controlled at driver layer, so it might not be necessary to change anything from you side.

Hi @edwakuwaku , regarding the first point above.
"Do you mean that anything starting from the idle loop will have the possibility to face such condition (as there are included in the idle loop thread)"
Sorry for the delayed response, but basically, yes.
If whatever is started from here, leads to a function call that blocks this task itself, then the scheduler will try to pre-empt the current task and bring in a new one. However, since this is the idle thread and there is no other task to bring in, we face a problematic situation, as is checked here ( https://github.com/Samsung/TizenRT/blob/4cced9a8944514cac4c28a2aab2717138b1e474b/os/kernel/sched/sched_removereadytorun.c#L120 )
So when you create a different task, that task can get block and pre-empted and idle task can come back in, and hence it works fine.

Dear @amogh-samsung ,
Thank you for your explanation, I have the similar observation as you, that's why I come out with this solution to mitigate such condition.

Could I understand it as this current workaround is feasible for such condition?
1a) If yes, does it means in the future if there is any related crash, we should follow this fix?
1b) If no, do your side have any idea on how can we overcome this condition? (We could discuss more during the meeting on Friday)~

Thank you!!

Hi @edwakuwaku
It would be preferred to find out the exact source/reason of the context switch, i.e. the blocking function if any that is causing the idle task to get switched out, hence leaving us with a crash.
Then, if possible, we should replace it with a non-blocking function.
The current implementation, is yes a workaround. It may be feasible here, we should check a bit more and conclude (I mean it may be the way to solve this problem case here).
However it would NOT be correct to say that this should be the method to always follow in the future in such a situation. We will try to get you an update by Friday during our meeting as you mentioned.

Hello @amogh-samsung ,
Yes, I definitely agree with your points. Additionally, I heard from Mr.Chang that the PR for SMP armv7-A will be merged to master soon, so it will be good if you could provide a clear usage of application to integrate with the PM module, so I can provide a wrapper api for your operation, and you could proceed to test on some simple application. How do you think?
Thank you~

Hi @amogh-samsung ,
The crash issue has been resolved in this commit, please take a look for your reference~
https://github.com/Samsung/TizenRT/commit/141d206b0818621e259c98d5284f172efc5b88d0
Besides, we will move on to finalize and submit for PR, by the time, you may also checkout the PR and verify the wakeup source requested. Additionally, as discussed in the last meeting, we would like to ask if there is any input from your side regarding the timer interrupt usage?
Thank you~

@edwakuwaku
Thankyou for the update. Can I pull the power_save branch now for the latest changes and test?
I will share details about the PM state control from the APP side soon. pm_stay and pm_relax should be able to do most of the work as discussed before.
However, in loadable apps environment, apps may not have access to these functions directly. I will elaborate more on these in a separate communication.

Hi @amogh-samsung ,
Yes, you may pull to the latest commit and test, which is under my repo.
Understood, I will checkout the PR from you.
Ok, I think we could figure out a way round to fulfil your requirement.
Thanks~


[WCAG 2.2] [Windows Terminal - Multiple Tab]: No single pointer alternative is provided to move the tabs.

Windows Terminal version
1.22.2362.0
Windows build number
27695.1000
Other Software
Test Environment:
OS: Windows 11 Version Dev (OS Build 27695.1000)
App: Windows Terminal Preview
Steps to reproduce
Repro steps:

Open the 'windows terminal' application.
Open Multiple tabs and navigate among the tabs.
Now, verify whether any single pointer alternative is provided to move the tabs or not.
Observe the issue.

User experience:
Users who struggle with performing dragging movements will feel difficulty to move tabs, if there is no single pointer alternative is provided to perform the action.
WCAG Reference Link:
Understanding Success Criterion 2.5.7: Dragging Movements | WAI | W3C
Attachment:
No single pointer alternative is provided to move the tabs.zip
Expected Behavior
A single pointer alternative mechanism should be provided to the users to move the tabs.
Actual Behavior
User can be able to move the tabs here & there by using mouse, but no alternative method is available for the user to perform action using single pointer.

This is a /dup of #16717.
Please refer to the discussion in that thread for further details.

@carlos-zamora,
Having keyboard shortcut to move the tabs cannot be consider as a single pointer alternative.
Suggestion: A button can be defined in a context menu of tabs using which users can move the tab.

Is there precedent for something like this in Edge?
Expanding out "Move tab to new window" to "Move Tab > {To new window, To the left, To the right, ...}" as a nested menu might be an option here


Any chance of a hex release?

I've been banging my head on the table trying to work out how to get the current rule state out of flippant so they can be displayed on a frontend, turns out I needed the unreleased breakdown/0 if you could release 0.3 that would be awesome, then we don't have to point directly to the git repo :)

Hex release made! Thanks for asking, it's great to know people are using it. For what its worth, I've been working on a frontend plug component but haven't had much time lately. I'd be curious to see what you/your team come up with, if you're willing to share.
https://hexdocs.pm/flippant/0.3.0


[SPARK-34212][SQL] Fix incorrect decimal reading from Parquet files (vectorized part)

This is complementary to https://github.com/apache/spark/pull/31319 and fixes the bug in vectorized parquet reader.

Test build #134507 has started for PR 31347 at commit 471095a.

Test build #134507 has started for PR 31347 at commit 471095a.

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

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

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

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

GA passes, so I think this patch should be safe, closing as it's already included in #31319

GA passes, so I think this patch should be safe, closing as it's already included in #31319


[WIP][GWS]chorg enhancements

Coverage increased (+0.01%) to 80.261% when pulling d0af0af5e5205ab4e9eca6b445539682ad9ce45d on sunny4381:features/gws-chorg-enhancements into ff831fab518d80ab67816a09b03ff198921af2ef on shirasagi:dev/gws.

Changes Unknown when pulling 26e26bf28a49b578c9684edb2ada0aca9bcdd5e9 on sunny4381:features/gws-chorg-enhancements into ** on shirasagi:dev/gws**.

Coverage decreased (-0.06%) to 80.207% when pulling 395bc4650e6b16c90156eca823bdf2bbe5f235c9 on sunny4381:features/gws-chorg-enhancements into a3c45e69ffd62d223fa14f485185a88dc01c578d on shirasagi:dev/gws.


Bad twiddle-wakka in metadata

https://github.com/hardening-io/chef-apache-hardening/blob/master/metadata.rb#L9
When trying to upload to my chef server I get:
E, [2015-06-02T15:01:52.801568 #76059] ERROR -- : Ridley::Errors::HTTPBadRequest: {"error":["Invalid value '~ 2.0.0' for metadata.dependencies"]}

I assume this ought to be ~> instead?

@cmjosh I am sorry for the typo. Thank you very much for pointing this out.


Calendar Displaying All Days on Left Hand Side.

Do you want to request a feature or report a bug?
What's the current behavior?
Hello, I'm having a strange issue where all of the days and events in the calendar are pushed to the left side of my window.
I thought the issue may be related to the need for a defined height on the container of the Calendar, but even after giving the container both a height and width value the issue persists.
This is what my code looks like:
const localizer = momentLocalizer(moment);

export const Hello: CcAppComponent = () => (
    <Segment style={{height: '1000px', width: '1000px'}}>
    <Calendar
        height={100}
        localizer={localizer}
        events={events}
        step={60}
        showMultiDayTimes
        startAccessor="start"
        endAccessor="end"
      />
      </Segment>
);

And this is how it renders.

I was not able to find a similar report, so if there is another similar post that has a solution, a link would be greatly appreciated.
Thank you for any assistance on this.
What's the expected behavior?

import the css

https://github.com/intljusticemission/react-big-calendar#custom-styling

This did it. Thank you for the quick response. Feel silly for not realizing I was missing this.


Style footer

Hi Shreyansh, this is a nice footer! However, please edit the about section to the following -
Women in Technology empowers women and young girls wanting to pursue Computer Science all around the world by increasing visibility of resources and opportunities, sharing inspirational stories of successful professionals in STEM and through our amazing Discord community of women uplifting each other.

Also, what is in Privacy Policy and the Copyright section?
I just added those links, just in case in the future you wanted to edit those

Hey @shreyshreyansh please do this corrections:

add footer bgcolor #ffcc66
about section : Women in Technology empowers women and young girls wanting to pursue Computer Science all around the world by increasing visibility of resources and opportunities, sharing inspirational stories of successful professionals in STEM and through our amazing Discord community of women uplifting each other.
text color to be in black.


Validation bug

Hello,
i followed the exact steps as you described in readme file and got the following error.

I can not reproduce this (see below).  From the error it looks like the saved model parameters are the wrong shape for the configured network(s) - have you made any changes to the code/scripts from the main branch?  Is this a fresh run on a new VM, or is there any chance of local changes having an effect?  In my case, a fresh set-up on a VM (with a GPU on GCP, so no changes to the provided Dockerfile) following the README gives me the below.

doing a fresh start solved the problem thanks :)


x/exp/io/gpio: user facing mapping API

The gpio package should expose a friendly way for the user to redefine pin mapping outside of the pre-defined set of supported boards configuration.
Current only the driver.Conn expose the Map method and the Conn is hidden by the gpio package from the public facing API.

Closing, gpio is not a part of the io packages anymore.


killport: init at 0.7.0

Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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

[x] 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/)
23.05 Release Notes (or backporting 22.11 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.

https://github.com/jkfran/killport/releases/tag/v0.7.0 has been released in the meantime :)
Also, does not build on aarch64-darwin and x86_64-darwin (see ci checks/ofborg).

https://github.com/jkfran/killport/releases/tag/v0.7.0 has been released in the meantime :)
Also, does not build on aarch64-darwin and x86_64-darwin (see ci checks/ofborg).

Anyway, I updated to 0.7.0. later I'll check that this can't build on aarch64-darwin and x86_64-darwin

https://github.com/jkfran/killport/releases/tag/v0.7.0 has been released in the meantime :)
Also, does not build on aarch64-darwin and x86_64-darwin (see ci checks/ofborg).

Anyway, I updated to 0.7.0. later I'll check that this can't build on aarch64-darwin and x86_64-darwin

I managed to do something about aarch64-darwin, but I couldn't figure out about x86_64-darwin (since I don't have a machine with that architecture to begin with), can someone please do something about that?

Summoning @wegank who knows darwin (and because I don't want to ping the whole darwin-maintainers team).
But you could probably just add meta.broken = stdenv.isDarwin && stdenv.isAarch64 or even platforms = platforms.linux; and call it a day :^)

Some minor formating nit:
diff --git a/pkgs/tools/misc/killport/default.nix b/pkgs/tools/misc/killport/default.nix
index 1c2b3bf884e..ca862ad6323 100644
--- a/pkgs/tools/misc/killport/default.nix
+++ b/pkgs/tools/misc/killport/default.nix
@@ -3,6 +3,7 @@
 , fetchCrate
 , llvmPackages
 }:
+
 rustPlatform.buildRustPackage rec {
   pname = "killport";
   version = "0.7.0";
@@ -20,8 +21,6 @@ rustPlatform.buildRustPackage rec {
     description = "A command-line tool to easily kill processes running on a specified port";
     homepage = "https://github.com/jkfran/killport";
     license = licenses.mit;
-    maintainers = with maintainers; [
-      sno2wman
-    ];
+    maintainers = with maintainers; [ sno2wman ];
   };

Anyway, I've squashed these commit, and ready to merge.

@ofborg build killport killport.passthru.tests


Test gcloud authentication

Test PR.
There is something weird going on with google authentication.
https://storage.googleapis.com/knative-prow/pr-logs/pull/knative-sandbox_eventing-kafka-broker/2300/channel-integration-tests-sasl-plain_eventing-kafka-broker_main/1536398575720730624/build-log.txt
We authenticate properly as you can see on 8, but further down, you get errors about Workload Identity which we haven't enabled yet.

/retest


angular-cli  Cannot find name 'map'

Bug Report or Feature Request (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.
@angular/cli: 1.2.0
node: 8.0.0
os: win32 x64
@angular/animations: 4.2.6
@angular/common: 4.2.6
@angular/compiler: 4.2.6
@angular/core: 4.2.6
@angular/forms: 4.2.6
@angular/http: 4.2.6
@angular/platform-browser: 4.2.6
@angular/platform-browser-dynamic: 4.2.6
@angular/router: 4.2.6
@angular/cli: 1.2.0
@angular/compiler-cli: 4.2.6
@angular/language-service: 4.2.6
The log given by the failure.
ERROR in E:/ng/pushdata/src/app/services/data.service.ts (12,4): Declaration or statement expected.
ERROR in E:/ng/pushdata/src/app/services/data.service.ts (12,5): Cannot find name 'map'.
Desired functionality.
import 'rxjs/add/operator/map';
can't usning Rxjs. Writes me .map() Cannot find name 'map'

Please could you help me figure it out. Thanks!


fix: [Async Method name is not async] in [FocusAsync]

🐛 Bug Report
As you can see from the following screenshot, the FocusAsync method is not async because it does not return a Task

🤔 Expected Behavior
In my opinion it should return a Task if needed, otherwise the Async postfix should be removed because it is misleading.
😯 Current Behavior
Since the method name ends in Async I have tried to await it and marked the method as async but the compiler issues an error.
🌍 Your Environment

OS & Device: Windows 11 Home
Browser Edge
.NET and FAST Version 8.0.2 and 4.4.1

This is know and on the list already.
As noted in the source code:     [SuppressMessage("Style", "VSTHRD200:Use Async suffix for async methods", Justification = "#vNext: To update in the next version")]


Update kind image

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/test all

will merge once I update test-infra


feat: add kusion mod login and pull sub-command

What type of PR is this?

/kind feature
What this PR does / why we need it:
This PR implements the kusion mod login and kusion mod pull sub-command for Kusion CLI to login and pull kusion modules declared in kcl.mod file from a private oci registry.
Which issue(s) this PR fixes:

Fixes #1255
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

0 of 161 (0.0%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 48.002%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/cmd/mod/mod.go
0
2
0.0%

pkg/cmd/generate/generate.go
0
5
0.0%

pkg/engine/api/generate/run/run.go
0
5
0.0%

pkg/cmd/mod/login.go
0
65
0.0%

pkg/cmd/mod/pull.go
0
84
0.0%

Totals

Change from base Build<PHONE_NUMBER>8:
-0.4%

Covered Lines:
10545

Relevant Lines:
21968

💛  - Coveralls


Fix display error in doc

Coverage remained the same at 40.638% when pulling 5feb9294524822c0d0226d5fc5e976bf12779075 on r41d:patch-1 into d1ee747ad0797652343bbd20104fced9b480dc16 on sammchardy:master.

Thanks @r41d


fix wrong usage calculation for enum value model property

All changed packages have been documented.

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/508/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/508/


Getting 301 error during tests

Hi, I am doing a fresh test of this.
I deployed all the components with:
KUBE_ROOT="https://raw.githubusercontent.com/kubernetes/contrib/master/ingress/controllers/nginx"

kubectl create -f "${KUBE_ROOT}/examples/default-backend.yaml"
kubectl expose rc default-http-backend --port=80 --target-port=8080 --name=default-http-backend
kubectl create -f "${KUBE_ROOT}/examples/default/rc-default.yaml"
kubectl run echoheaders --image=gcr.io/google_containers/echoserver:1.3 --replicas=1 --port=8080
kubectl expose deployment echoheaders --port=80 --target-port=8080 --name=echoheaders-x
kubectl expose deployment echoheaders --port=80 --target-port=8080 --name=echoheaders-y
kubectl create -f "${KUBE_ROOT}/examples/ingress.yaml"

Everything seems to run, the ingress rule is there
$ kubectl get ing
NAME      RULE          BACKEND   ADDRESS        AGE
echomap   -                       <IP_ADDRESS>   48m
          foo.bar.com
          /foo          echoheaders-x:80
          bar.baz.com
          /bar          echoheaders-y:80
          /foo          echoheaders-x:80

But I am getting 301 errors:
root@foobar:~# curl -v http://<IP_ADDRESS>:80/foo -H 'Host: foo.bar.com'
* Hostname was NOT found in DNS cache
*   Trying <IP_ADDRESS>...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 80 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.35.0
> Accept: */*
> Host: foo.bar.com
>
< HTTP/1.1 301 Moved Permanently
* Server nginx/1.9.13 is not blacklisted
< Server: nginx/1.9.13
< Date: Thu, 14 Apr 2016 21:43:04 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Location: https://foo.bar.com/foo
<

<title>301 Moved Permanently</title>

301 Moved Permanently

nginx/1.9.11

* Connection #0 to host <IP_ADDRESS> left intact

The echo headers app seem to be working fine.
root@foobar:~# curl <IP_ADDRESS>:80
CLIENT VALUES:
client_address=<IP_ADDRESS>
command=GET
real path=/
query=nil
request_version=1.1
request_uri=http://<IP_ADDRESS>:8080/

SERVER VALUES:
server_version=nginx: 1.9.11 - lua: 10001

HEADERS RECEIVED:
accept=*/*
host=<IP_ADDRESS>
user-agent=curl/7.35.0
BODY:
-no body in request-

Not sure where to look, the nginx conf file on the ingress controller seems to be fine.

Hey I ran into the same issue.  Turns out this http->https redirect was added in 1.3 of the echoserver app:  https://github.com/kubernetes/contrib/commit/08077babdb78a80626629b0866d0f2771d29a432
Installing version 1.2 via:
kubectl run echoheaders --image=gcr.io/google_containers/echoserver:1.2 --replicas=1 --port=8080  allows the test to complete.

Sorry, this seems to have affected more people that I'd expected. I should probably fork echoserver to another version. Let me know if you'd prefer to use eg: latest or something in your tests and I'll do that. @bsheats @runseb

changing the image name to 1.2 as mentioned by @bsheats does it. thanks
@bprashanth I think it is fine, you probably just need to update the README:
https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx


Miniproject 1 Solution

So you are basically changing the regressor file that was provided in the question itself right ?

Yeah... It's the same file.

If you are adding a new file, regressor.py I am not sure if the test_script will work. I like the idea of adding a new file and not changing the 'sample_submission' file. Can you do that and comment out the part of the code in the test_script that reads from sample_submission and have it read from a file that you wrote ?
This way, the original question will still be preserved as it is and your solution will be added as a new file to the codebase. While you comment out the sample_submission code in the test_script you make a note that it is your solution and add your license to the code as well.
-R

Do you want me to upload the test_script as well?

Ok, I made a new commit to the miniproject 1 solution. Check that and submit your code accordingly. Make sure you have your license on your code.
-R

I have deleted regressor.py and added best_solution.py with MIT License.

Ok, I'll merge this.


Recheck OKHTTP and Feign plugin, can they log exception?

Seem this is a potential issue. If remote service is off, do the plugins log exception.
@pengys5 Please recheck first.

fix it. close it.
Ref: #382


[hiccup] error: x.toHiccup is not a function when drawing hiccup shapes

I have created a couple of shapes as specified in here , when I print them to the console they have the following structure:

But when I try to draw them to the canvas with the Hiccup draw functions, I get the error that x.toHiccup is not a function when drawing hiccup shapes. Is there something i'am missing?

Hi @Jonaskouwenhoven - could you please upload a minimal example to codesandbox/codepen etc.? Alas, I can't tell what's wrong from what you provided... Thanks!

Managed to figure it out, thanks for the fast reply!


WiX: remove extraneous architecture in search path

Adjust the location of the swift modules to overlap across SDKs.  The
directory form of the swift module can easily overlap and co-exist.  Now
that the driver has learnt to scan the non-architecture dependent location
in addition to the architecture location dependent path, we can unify
the swiftmodule content in the SDK to a simpler layout.  The layout now
is:
SDKROOT
  `- usr
      `- lib
          `- swift
              `- [platform]
                  +- [module].swiftmodule
                  |   `- [triple].{swiftdoc,swiftmodule,swiftinterface}
                  `- [arch]
                      `- [import library]

On Windows, it would be preferable to further remove the intermediate
platform as we have that information earlier in the path.
Subsequent work remains to now ensure that the package manager will
similarly allow the XCTest swift modules to collapse.
While in theory it is possible to create a multi-architecture import
library, it is valuable to support user-selectable SDK installation
which requires that the we create the import libraries on the fly for
the selected architectures.  It is more convenient from a distribution
perspective to simply make the content static and as such continue to
use the architect dependent directory for the import library unlike the
swift module.
This is dependent on apple/swift#42419.

@compnerd is this ready to be merged?

Yes, I believe it is; I really wish that we could kick off toolchain builds that we could easily test with the changes.

You can using the cross PR testing

Hmm, it seems that it still doesn't report the generated installer - is there a way to get that to test?

Hmm, it seems that it still doesn't report the generated installer - is there a way to get that to test?

You should be able to download it now. I started a build over the weekend.

Bleh, seems to be missing a change in swift-driver; thanks for setting up the download!

Just verified, this is ready to go.  Thanks for the ping on this @shahmishal!  This is actually going to help make the 5.7 release for Windows even better :)


First release checklist

This is the list of blockers for getting the new site live. There's plenty of additional things to do to improve the website, this list is only things that MUST be done in order to go live.
Content

[x] Docs.md (main docs page content)
[x] versions.json w/ all io.js and node.js releases
[x] https://iojs.org/api/ -> https://new.nodejs.org/api/
[ ] Google Analytics

What else?

Move/link API docs from iojs.org to (new.)nodejs.org

https://new.nodejs.org/download/release/index.json
https://new.nodejs.org/download/release/index.tab
or
https://new.nodejs.org/dist/index.json
https://new.nodejs.org/dist/index.tab
Note that this server is now populated with all of the old node dist directory
I wasn't planning on merging the two but I'm getting the impression that that's being suggested.

@rvagg Can you sort the list by date? If merging both lists is a problem at the moment, we could do this at build time as well.

"date" is kind of hard to determine, which file do you test and what is that date indicating anyway?
Instead, I've pulled in node-semver and used it to compare for a sort, hope that helps

I've turned on CloudFlare for new.nodejs.org and am going to bed, let me know if anything odd turns up but we're getting very close to this being ready. I did want to switch iojs.org over to this new server but it's too late and I don't want to be switching it just before I head off to sleep so I'll do it tomorrow.

@rvagg Wrote a little script load-versions.js which merges the two files for our release list.

Okay, I'm calling it a day as well. ;)

You can do https://iojs.org/api/ -> https://new.nodejs.org/api/ now, it's active
Also, I don't know if it helps at all but I'm putting latest-v0.10.x, latest-v0.12.x, latest-v4.x etc. in all of the download directories (/dist/ a.k.a. /downoads/release/, /download/nightly/, /download/rc/, etc.), these'll get updated on each release. But you have the index.json data you can do that from anyway.

@rvagg I still end up on the Node.js v0.12.7 docs instead of the iojs docs.

well, that's appropriate for nodejs.org where 0.12 is the "latest", as soon as v4 drops it'll switch to 4.0.0 docs

Okay, felt a bit odd at first when you're redirected to the old site. ;)
I'll go through the site and change all links later.

Link is updated.

I spent the entirety of my day being intimate with the new server and am not as close as I hoped. Most of the pieces are in place now, there's a little bit of testing to do but remaining items are:

[ ] Re-enable proper http support for the resources that need it, as per #42, this is not as easy as it sounds
[ ] Put in the redirects that @fhemberger listed for me somewhere in this repo
[ ] Do a final catalogue of the non-4xx hits in the existing logs on the old nodejs.org to see what resources are actually being used. There's a lot of cruft in there and I'm hesitant to just cut the cord on it all without having an idea of what's being used. If anyone wants to help look over the list to see if there are any goodies, here it is: https://gist.github.com/rvagg/b2e76ef6c8217530d313
[ ] Upgrade the server to something with a little more grunt
[ ] Get a proper log rotation archive scheme in place so the server doesn't fill but but we don't lose valuable analytics data (this can wait till after launch, but I shouldn't leave it too long!)

@rvagg Found them! https://github.com/nodejs/new.nodejs.org/issues/20#issuecomment-130218243

To be honest, looking at the staging (I assume that's what it is) site, the index looks kind of meager, as in, the page does not scroll at all. Shouldn't we add a little more information than that? (Apologies if that's already being worked on)

"latest" on the front page is v3.2.0, are we OK with that? I'd say in the interests of transition we go with 0.12.7 until v4 is out later this week. Or is this a remnant of the fact that you've only had io.js' index.json to go with till now?

@fhemberger & @mikeal I'm going to look to you two for sign-off on the switch to the new site, I'll get my pieces done today but need you to let me know when you're comfortable with the move.

Can we add:

[ ] Google Analytics

To the checklist please? I see it in the prefetch list but not inline at all. Since we are relying on CF to serve most of the website content we're not going to be able to do anything useful with the server logs except for /dist & /download files. Make sure that any Analytics setup is shared with enough of the website team to make it useful.

OK, redirects are mostly done, but very painful. I've put in @fhemberger's list mostly as is for nodejs.org:
    rewrite ^/about/advisory-board/(.*)$                          https://$server_name/en/about/organization/ permanent;
    rewrite ^/advisory-board/(.*)$                                https://$server_name/en/about/organization/ permanent;
    rewrite ^/about/organization/tsc-meetings/$                   https://$server_name/en/foundation/tsc/minutes/ permanent;
    rewrite ^/about/organization/tsc-meetings/(.*?)/minutes.html$ https://$server_name/en/foundation/tsc/minutes/$1/ permanent;
    rewrite ^/about/security/$                                    https://$server_name/en/security/ permanent;
    rewrite ^/contribute/$                                        https://$server_name/en/get-involved/ permanent;
    rewrite ^/contribute/accepting_contributions.html$            https://github.com/nodejs/dev-policy permanent;
    rewrite ^/contribute/becoming_collaborator.html$              https://$server_name/en/get-involved/ permanent;
    rewrite ^/contribute/code_contributions/$                     https://$server_name/en/get-involved/ permanent;
    rewrite ^/contribute/code_contributions/workflow.html$        https://$server_name/en/get-involved/ permanent;
    rewrite ^/documentation/(.*)$                                 https://$server_name/en/docs/ permanent;
    rewrite ^/foundation/blog.html$                               https://$server_name/en/blog/ permanent;
    rewrite ^/foundation/members.html$                            https://$server_name/en/foundation/members/ permanent;

    rewrite ^/images/foundation-visual-guidelines.pdf$            https://$server_name/static/documents/foundation-visual-guidelines.pdf permanent;
    rewrite ^/images/logos/js-black(.*)$                          https://$server_name/static/images/logos/js-black$1 permanent;
    rewrite ^/images/logos/nodejs-(.*)$                           https://$server_name/static/images/logos/nodejs-$1 permanent;
    rewrite ^/images/node-foundation-by-laws.pdf$                 https://$server_name/static/documents/node-foundation-by-laws.pdf permanent;
    rewrite ^/images/.*trademark-policy.pdf$                      https://$server_name/static/documents/trademark-policy.pdf permanent;
    rewrite ^/video/(.*)$                                         https://$server_name/static/video/$1 permanent;

and put in the blog ones to blog.nodejs.org but because you're now listing by category a bulk redirect no longer works! So I had to do some hackery with a program to work it all out, see https://gist.github.com/rvagg/c9ef9dfc9dbe23ac0f7e for my program and data files to get this mapping. I've ended up with:
  '"$status" $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for"';

server {
    listen 80 default_server;
    listen [::]:80;
    server_name www.nodejs.org nodejs.org;

    access_log /var/log/nginx/nodejs.org-access.log;
    error_log /var/log/nginx/nodejs.org-error.log;

    keepalive_timeout 60;
    server_tokens off;

    gzip on;
    gzip_static on;
    gzip_disable "MSIE [1-6]\.";
    gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    root /home/www/nodejs;
    default_type text/plain;
    index index.html;

    if ($host ~* ^www\.){
        rewrite ^(.*)$ http://$server_name$1;
    }

    location ~ ^/(dist/?.*$|.+\.json$) {
      rewrite ^ https://$server_name$request_uri permanent;
    }

    location / {
        location ~ \.json$ {
            add_header access-control-allow-origin *;
        }
    }

    location /dist {
        alias /home/dist/nodejs/release/;
        autoindex on;
        default_type text/plain;

        location ~ \.json$ {
            add_header access-control-allow-origin *;
        }
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name blog.nodejs.org;

    rewrite ^/\d+/\d+/\d+/(?:node-v(?:ersion-)?|version-)(\d+)[-\.](\d+)[-\.](\d+).*o$ https://nodejs.org/en/blog/release/v$1.$2.$3/ permanent;

    rewrite ^/2014/01/17/nodejs-road-ahead/$ https://nodejs.org/en/blog/nodejs-road-ahead/ permanent;
    rewrite ^/2013/12/03/bnoordhuis-departure/$ https://nodejs.org/en/blog/uncategorized/bnoordhuis-departure/ permanent;
    rewrite ^/2015/05/08/transitions/$ https://nodejs.org/en/blog/community/transitions/ permanent;
    rewrite ^/2015/05/08/next-chapter/$ https://nodejs.org/en/blog/community/next-chapter/ permanent;
    rewrite ^/2013/02/08/peer-dependencies/$ https://nodejs.org/en/blog/npm/peer-dependencies/ permanent;
    rewrite ^/2012/12/21/streams2/$ https://nodejs.org/en/blog/feature/streams2/ permanent;
    rewrite ^/2012/09/30/bert-belder-libuv-lxjs-2012/$ https://nodejs.org/en/blog/video/bert-belder-libuv-lxjs-2012/ permanent;
    rewrite ^/2012/05/08/bryan-cantrill-instrumenting-the-real-time-web/$ https://nodejs.org/en/blog/video/bryan-cantrill-instrumenting-the-real-time-web/ permanent;
    rewrite ^/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/$ https://nodejs.org/en/blog/vulnerability/http-server-security-vulnerability-please-upgrade-to-0-6-17/ permanent;
    rewrite ^/2012/05/02/multi-server-continuous-deployment-with-fleet/$ https://nodejs.org/en/blog/module/multi-server-continuous-deployment-with-fleet/ permanent;
    rewrite ^/2012/04/25/profiling-node-js/$ https://nodejs.org/en/blog/uncategorized/profiling-node-js/ permanent;
    rewrite ^/2012/03/28/service-logging-in-json-with-bunyan/$ https://nodejs.org/en/blog/module/service-logging-in-json-with-bunyan/ permanent;
    rewrite ^/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/$ https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/ permanent;
    rewrite ^/2011/12/15/growing-up/$ https://nodejs.org/en/blog/uncategorized/growing-up/ permanent;
    rewrite ^/2011/10/26/version-0-6/$ https://nodejs.org/en/blog/uncategorized/version-0-6/ permanent;
    rewrite ^/2011/10/05/an-easy-way-to-build-scalable-network-programs/$ https://nodejs.org/en/blog/uncategorized/an-easy-way-to-build-scalable-network-programs/ permanent;
    rewrite ^/2011/09/23/libuv-status-report/$ https://nodejs.org/en/blog/uncategorized/libuv-status-report/ permanent;
    rewrite ^/2011/09/08/ldapjs-a-reprise-of-ldap/$ https://nodejs.org/en/blog/uncategorized/ldapjs-a-reprise-of-ldap/ permanent;
    rewrite ^/2011/08/29/some-new-node-projects/$ https://nodejs.org/en/blog/uncategorized/some-new-node-projects/ permanent;
    rewrite ^/2011/08/12/the-videos-from-node-meetup/$ https://nodejs.org/en/blog/uncategorized/the-videos-from-node-meetup/ permanent;
    rewrite ^/2011/08/03/node-meetup-this-thursday/$ https://nodejs.org/en/blog/uncategorized/node-meetup-this-thursday/ permanent;
    rewrite ^/2011/07/11/evolving-the-node-js-brand/$ https://nodejs.org/en/blog/uncategorized/evolving-the-node-js-brand/ permanent;
    rewrite ^/2011/05/01/npm-1-0-released/$ https://nodejs.org/en/blog/npm/npm-1-0-released/ permanent;
    rewrite ^/2011/04/29/trademark/$ https://nodejs.org/en/blog/uncategorized/trademark/ permanent;
    rewrite ^/2011/04/28/node-office-hours-cut-short/$ https://nodejs.org/en/blog/uncategorized/node-office-hours-cut-short/ permanent;
    rewrite ^/2011/04/07/npm-1-0-link/$ https://nodejs.org/en/blog/npm/npm-1-0-link/ permanent;
    rewrite ^/2011/04/05/development-environment/$ https://nodejs.org/en/blog/uncategorized/development-environment/ permanent;
    rewrite ^/2014/12/05/listening-to-the-community/$ https://nodejs.org/en/blog/advisory-board/listening-to-the-community/ permanent;
    rewrite ^/2014/12/03/advisory-board-update/$ https://nodejs.org/en/blog/advisory-board/advisory-board-update/ permanent;
    rewrite ^/2011/03/25/jobs-nodejs-org/$ https://nodejs.org/en/blog/uncategorized/jobs-nodejs-org/ permanent;
    rewrite ^/2011/03/24/npm-1-0-global-vs-local-installation/$ https://nodejs.org/en/blog/npm/npm-1-0-global-vs-local-installation/ permanent;
    rewrite ^/2011/03/24/office-hours/$ https://nodejs.org/en/blog/uncategorized/office-hours/ permanent;
    rewrite ^/2011/03/18/npm-1-0-the-new-ls/$ https://nodejs.org/en/blog/npm/npm-1-0-the-new-ls/ permanent;
    rewrite ^/2011/03/18/welcome-to-the-node-blog/$ https://nodejs.org/en/blog/video/welcome-to-the-node-blog/ permanent;
    rewrite ^/2014/07/31/v8-memory-corruption-stack-overflow/$ https://nodejs.org/en/blog/vulnerability/v8-memory-corruption-stack-overflow/ permanent;
    rewrite ^/2014/07/29/building-nodejs-together/$ https://nodejs.org/en/blog/community/building-nodejs-together/ permanent;
    rewrite ^/2014/06/11/notes-from-the-road/$ https://nodejs.org/en/blog/uncategorized/notes-from-the-road/ permanent;
    rewrite ^/2015/05/08/transitions/$ https://nodejs.org/en/blog/community/transitions/ permanent;
    rewrite ^/2015/05/08/next-chapter/$ https://nodejs.org/en/blog/community/next-chapter/ permanent;
    rewrite ^/2012/12/21/streams2/$ https://nodejs.org/en/blog/feature/streams2/ permanent;
    rewrite ^/2012/05/02/multi-server-continuous-deployment-with-fleet/$ https://nodejs.org/en/blog/module/multi-server-continuous-deployment-with-fleet/ permanent;
    rewrite ^/2012/03/28/service-logging-in-json-with-bunyan/$ https://nodejs.org/en/blog/module/service-logging-in-json-with-bunyan/ permanent;
    rewrite ^/2013/02/08/peer-dependencies/$ https://nodejs.org/en/blog/npm/peer-dependencies/ permanent;
    rewrite ^/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/$ https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/ permanent;
    rewrite ^/2011/05/01/npm-1-0-released/$ https://nodejs.org/en/blog/npm/npm-1-0-released/ permanent;
    rewrite ^/2014/06/11/notes-from-the-road/$ https://nodejs.org/en/blog/uncategorized/notes-from-the-road/ permanent;
    rewrite ^/2012/04/25/profiling-node-js/$ https://nodejs.org/en/blog/uncategorized/profiling-node-js/ permanent;
    rewrite ^/2011/12/15/growing-up/$ https://nodejs.org/en/blog/uncategorized/growing-up/ permanent;
    rewrite ^/2011/10/26/version-0-6/$ https://nodejs.org/en/blog/uncategorized/version-0-6/ permanent;
    rewrite ^/2012/09/30/bert-belder-libuv-lxjs-2012/$ https://nodejs.org/en/blog/video/bert-belder-libuv-lxjs-2012/ permanent;
    rewrite ^/2012/05/08/bryan-cantrill-instrumenting-the-real-time-web/$ https://nodejs.org/en/blog/video/bryan-cantrill-instrumenting-the-real-time-web/ permanent;
    rewrite ^/2011/03/18/welcome-to-the-node-blog/$ https://nodejs.org/en/blog/video/welcome-to-the-node-blog/ permanent;
    rewrite ^/2014/07/31/v8-memory-corruption-stack-overflow/$ https://nodejs.org/en/blog/vulnerability/v8-memory-corruption-stack-overflow/ permanent;
    rewrite ^/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/$ https://nodejs.org/en/blog/vulnerability/http-server-security-vulnerability-please-upgrade-to-0-6-17/ permanent;
    rewrite ^/(.*)$ https://nodejs.org/en/blog/ permanent;

with the following mapping not working yet:
(200) /2015/05/16/node-leaders-are-building-an-open-foundation/ -> https://nodejs.org/en/blog/
(200) /2015/05/16/the-nodejs-foundation-benefits-all/ -> https://nodejs.org/en/blog/
(200) /2014/01/15/the-next-phase-of-node-js/ -> https://nodejs.org/en/blog/
(200) /2013/11/26/npm-post-mortem/ -> https://nodejs.org/en/blog/
(200) /2013/10/22/cve-2013-4450-http-server-pipeline-flood-dos/ -> https://nodejs.org/en/blog/
(404) /2013/02/07/node-v0-9-9-unstable/ -> https://nodejs.org/en/blog/release/v0.9.9/
(200) /2011/06/24/porting-node-to-windows-with-microsoft%e2%80%99s-help/ -> https://nodejs.org/en/blog/
(200) /2014/06/16/openssl-and-breaking-utf-8-change/ -> https://nodejs.org/en/blog/
(200) /2013/07/16/download-statistics/ -> https://nodejs.org/en/blog/
(200) /2015/05/16/node-leaders-are-building-an-open-foundation/ -> https://nodejs.org/en/blog/
(200) /2015/05/16/the-nodejs-foundation-benefits-all/ -> https://nodejs.org/en/blog/
(200) /2013/11/26/npm-post-mortem/ -> https://nodejs.org/en/blog/
(200) /2014/06/16/openssl-and-breaking-utf-8-change/ -> https://nodejs.org/en/blog/
(200) /2013/10/22/cve-2013-4450-http-server-pipeline-flood-dos/ -> https://nodejs.org/en/blog/

They'll have to be manually done because you've gone and changed their names.

(edited previous comment to remove unnecessary nginx fluff)

Edited post and program after adding manual mappings and now I'm down to three not-working redirects and I'm moving on. If you want me to add any new redirects for the blog then let me know.

@schisma Let's rather have less, precise content than just filling the page just to make it scroll. ;)

"latest" on the front page is v3.2.0, are we OK with that?

We're pulling the first element (= highest semver release) from the index.json. Fortunately @phillipj put that into a separate variable, so this can be changed easily: https://github.com/nodejs/new.nodejs.org/blob/master/build.js#L55

What also comes to my mind for the list: Are we okay with the content? We mostly just moved everything from nodejs.org over, but does it reflect the current situation? E.g. getting involved, code contributions, etc.
At least before we start translating everything, we should try to weed out and shorten some of the texts. Otherwise they will be had to maintain and become outdated quickly in the future.

re content, I'm not fussed if we start with existing and update over time, the important part is to migrate to the new server so we can iterate quicker.
re redirects, it turns out we're still pretty far off but I'd really like to get this into a state where we can switch over today if at all possible.
What I've done is taken a scrape through the 1 month of logs on the old server and found all of the URLs that get hit that don't 404, then sorted by number of hits. Then I've run those URLs against the current server to see what happens and weeded out all of the 200's and remove everything with "nightlies" in it (a lot of them). I've fixed up a bunch of them (the whole /docs/ directory was missing from my config) but I'm left with quite a lot.
See full gist for gory details: https://gist.github.com/rvagg/f4a24312053af1195824#file-statuses_non200-txt
Or jump to the pruned list of non-200's that we should look at and resolve where possible, particularly at the higher end of the list: https://gist.githubusercontent.com/rvagg/f4a24312053af1195824/raw/54b5cc6d37c1b92ce6791bf26dbe7dc0494a386a/statuses_non200.txt

@rvagg Working on it!

Lots of docs, prior to the late v0.10.x docs restyle, are missing https://nodejs.org/images/logo-light.png when viewed on the new site, e.g. https://nodejs.org/docs/v0.10.30/api/, can we put that one into this repo or should I make a special alias just for this and store it somewhere else?

@rvagg Just added the logo as well.
Now, moar redirects:
# Website

rewrite ^/about/$                           https://nodejs.org/en/about/ permanent;
rewrite ^/about/advisory-board/$            https://nodejs.org/en/about/organization/ permanent;
rewrite ^/about/advisory-board/members/$    https://nodejs.org/en/about/organization/ permanent;
rewrite ^/about/organization/$              https://nodejs.org/en/about/organization/ permanent;
rewrite ^/about/organization/tsc-meetings/(\d{4}-\d{2}-\d{2})/$                https://nodejs.org/en/foundation/tsc/minutes/$1/ permanent;
rewrite ^/about/organization/tsc-meetings/(\d{4}-\d{2}-\d{2})/minutes.html$    https://nodejs.org/en/foundation/tsc/minutes/$1/ permanent;
rewrite ^/about/releases/$                  https://nodejs.org/en/about/releases/ permanent;
rewrite ^/about/resources/$                 https://nodejs.org/en/about/resources/ permanent;
rewrite ^/about/security/$                  https://nodejs.org/en/security/ permanent;
rewrite ^/about/trademark/$                 https://nodejs.org/en/about/trademark/ permanent;
rewrite ^/blog/$                            https://nodejs.org/en/blog/ permanent;
rewrite ^/community/$                       https://nodejs.org/en/get-involved/ permanent;
rewrite ^/foundation/$                      https://nodejs.org/en/foundation/ permanent;

# All the release blog posts should be covered by this one
rewrite ^/\d{4}/\d{2}/\d{2}/(?:node-v(?:ersion-)?|version-)(\d+)[-\.](\d+)[-\.](\d+).*$ https://nodejs.org/en/blog/release/v$1.$2.$3/ permanent;

# Other blog posts
rewrite ^/\d{4}/\d{2}/\d{2}/(.*)$      https://nodejs.org/en/blog/$1 permanent;
rewrite ^/\d{4}/(\d{2}/)?(\d{2}/)?$    https://nodejs.org/en/blog/ permanent;

# Not sure about this one (Staging releases v0.10.40 and v0.12.6)
rewrite ^/dist/staging/(.*)$         https://nodejs.org/dist/$1 permanent;

# FIXME: Wrong redirects in existing list!
rewrite ^/documentation/api/(.*)$    https://nodejs.org/api/$1 permanent;

# What should happen with links to node.js < v0.8.x?
rewrite ^/docs/v\d+\.\d+\.\d+/$            https://nodejs.org/api/ permanent;
rewrite ^/docs/v\d+\.\d+\.\d+/api/(.*)$    https://nodejs.org/api/$1 permanent;

# API docs redirects
rewrite ^/docs/api$               https://nodejs.org/api/ permanent;
rewrite ^/docs/api/(.*)$          https://nodejs.org/api/$1 permanent;
rewrite ^/addons.html$            https://nodejs.org/api/addons.html permanent;
rewrite ^/assert.html$            https://nodejs.org/api/assert.html permanent;
rewrite ^/buffer.html$            https://nodejs.org/api/buffer.html permanent;
rewrite ^/child_process.html$     https://nodejs.org/api/child_process.html permanent;
rewrite ^/cluster.html$           https://nodejs.org/api/cluster.html permanent;
rewrite ^/console.html$           https://nodejs.org/api/console.html permanent;
rewrite ^/crypto.html$            https://nodejs.org/api/crypto.html permanent;
rewrite ^/debugger.html$          https://nodejs.org/api/debugger.html permanent;
rewrite ^/dgram.html$             https://nodejs.org/api/dgram.html permanent;
rewrite ^/dns.html$               https://nodejs.org/api/dns.html permanent;
rewrite ^/documentation.html$     https://nodejs.org/api/documentation.html permanent;
rewrite ^/domain.html$            https://nodejs.org/api/domain.html permanent;
rewrite ^/errors.html$            https://nodejs.org/api/errors.html permanent;
rewrite ^/events.html$            https://nodejs.org/api/events.html permanent;
rewrite ^/fs.html$                https://nodejs.org/api/fs.html permanent;
rewrite ^/globals.html$           https://nodejs.org/api/globals.html permanent;
rewrite ^/http.html$              https://nodejs.org/api/http.html permanent;
rewrite ^/https.html$             https://nodejs.org/api/https.html permanent;
rewrite ^/modules.html$           https://nodejs.org/api/modules.html permanent;
rewrite ^/net.html$               https://nodejs.org/api/net.html permanent;
rewrite ^/os.html$                https://nodejs.org/api/os.html permanent;
rewrite ^/path.html$              https://nodejs.org/api/path.html permanent;
rewrite ^/process.html$           https://nodejs.org/api/process.html permanent;
rewrite ^/punycode.html$          https://nodejs.org/api/punycode.html permanent;
rewrite ^/querystring.html$       https://nodejs.org/api/querystring.html permanent;
rewrite ^/readline.html$          https://nodejs.org/api/readline.html permanent;
rewrite ^/repl.html$              https://nodejs.org/api/repl.html permanent;
rewrite ^/stream.html$            https://nodejs.org/api/stream.html permanent;
rewrite ^/string_decoder.html$    https://nodejs.org/api/string_decoder.html permanent;
rewrite ^/synopsis.html$          https://nodejs.org/api/synopsis.html permanent;
rewrite ^/timers.html$            https://nodejs.org/api/timers.html permanent;
rewrite ^/tls.html$               https://nodejs.org/api/tls.html permanent;
rewrite ^/tty.html$               https://nodejs.org/api/tty.html permanent;
rewrite ^/url.html$               https://nodejs.org/api/url.html permanent;
rewrite ^/util.html$              https://nodejs.org/api/util.html permanent;
rewrite ^/v8.html$                https://nodejs.org/api/v8.html permanent;
rewrite ^/vm.html$                https://nodejs.org/api/vm.html permanent;
rewrite ^/zlib.html$              https://nodejs.org/api/zlib.html permanent;

# Somebody seems to link npm packages (340 of them) to nodejs.org
rewrite ^/nodejs/dist/?$        https://www.npmjs.com/ permanent;
rewrite ^/nodejs/dist/(.*)$     https://www.npmjs.com/package/$1 permanent;

# RSS Feeds
rewrite ^/(atom|feed|rss)(/|\.xml)$       https://nodejs.org/en/feed/blog.xml permanent;
rewrite ^/feed/release/$                  https://nodejs.org/en/feed/releases.xml permanent;
rewrite ^/feed/vulnerability/$            https://nodejs.org/en/feed/vulnerability.xml permanent;

# Asset rewrites
rewrite ^/robots.txt$                 https://nodejs.org/static/robots.txt permanent;
rewrite ^/.*favicon\.ico$             https://nodejs.org/static/favicon.ico permanent;
rewrite ^/apple-touch-icon.*\.png$    https://nodejs.org/static/apple-touch-icon.png permanent;
rewrite ^/trademark-policy.pdf$       https://nodejs.org/static/documents/trademark-policy.pdf permanent;

rewrite ^/logos/                      https://nodejs.org/static/images/logos/ permanent;
rewrite ^/logos/monitor.png           https://nodejs.org/static/images/logos/monitor.png permanent;
rewrite ^/logos/nodejs(.*)$           https://nodejs.org/static/images/logos/nodejs$1 permanent;

# Foundation member logos
rewrite ^/images/logos/apigee_logo_md.png$     https://nodejs.org/static/images/foundation/apigee_logo_md.png permanent;
rewrite ^/images/logos/codefreshLogo.png$      https://nodejs.org/static/images/foundation/codefreshLogo.png permanent;
rewrite ^/images/logos/codefreshLogo2.png$     https://nodejs.org/static/images/foundation/codefreshLogo2.png permanent;
rewrite ^/images/logos/digitaloceanLogo.png$   https://nodejs.org/static/images/foundation/digitaloceanLogo.png permanent;
rewrite ^/images/logos/famousLogo.jpg$         https://nodejs.org/static/images/foundation/famousLogo.jpg permanent;
rewrite ^/images/logos/famousLogo.png$         https://nodejs.org/static/images/foundation/famousLogo.png permanent;
rewrite ^/images/logos/fidelityLogo.png$       https://nodejs.org/static/images/foundation/fidelityLogo.png permanent;
rewrite ^/images/logos/godaddyLogo.png$        https://nodejs.org/static/images/foundation/godaddyLogo.png permanent;
rewrite ^/images/logos/grouponLogo.png$        https://nodejs.org/static/images/foundation/grouponLogo.png permanent;
rewrite ^/images/logos/ibmLogo.png$            https://nodejs.org/static/images/foundation/ibmLogo.png permanent;
rewrite ^/images/logos/intelLogo.png$          https://nodejs.org/static/images/foundation/intelLogo.png permanent;
rewrite ^/images/logos/joyentLogo.svg$         https://nodejs.org/static/images/foundation/joyentLogo.svg permanent;
rewrite ^/images/logos/microsoftLogo.png$      https://nodejs.org/static/images/foundation/microsoftLogo.png permanent;
rewrite ^/images/logos/microsoftLogo2.png$     https://nodejs.org/static/images/foundation/microsoftLogo2.png permanent;
rewrite ^/images/logos/modulusLogo.png$        https://nodejs.org/static/images/foundation/modulusLogo.png permanent;
rewrite ^/images/logos/nearformLogo.png$       https://nodejs.org/static/images/foundation/nearformLogo.png permanent;
rewrite ^/images/logos/nearformLogo2.png$      https://nodejs.org/static/images/foundation/nearformLogo2.png permanent;
rewrite ^/images/logos/nodesourceLogo.png$     https://nodejs.org/static/images/foundation/nodesourceLogo.png permanent;
rewrite ^/images/logos/npmLogo.png$            https://nodejs.org/static/images/foundation/npmLogo.png permanent;
rewrite ^/images/logos/paypalLogo.png$         https://nodejs.org/static/images/foundation/paypalLogo.png permanent;
rewrite ^/images/logos/sapLogo.png$            https://nodejs.org/static/images/foundation/sapLogo.png permanent;
rewrite ^/images/logos/saucelabsLogo.png$      https://nodejs.org/static/images/foundation/saucelabsLogo.png permanent;
rewrite ^/images/logos/saucelabsLogo2.png$     https://nodejs.org/static/images/foundation/saucelabsLogo2.png permanent;
rewrite ^/images/logos/strongloopLogo.png$     https://nodejs.org/static/images/foundation/strongloopLogo.png permanent;
rewrite ^/images/logos/yldLogo.png$            https://nodejs.org/static/images/foundation/yldLogo.png permanent;
rewrite ^/images/logos/yldLogo2.png$           https://nodejs.org/static/images/foundation/yldLogo2.png permanent;

rewrite ^/images/(.*)               https://nodejs.org/static/images/$1 permanent;

Those should cover most cases of the statuses_non200.txt list.

Some people have subscribed to release and vulnerability feeds. We should continue those.
Is everybody okay that blog post URLs won't be prefixed with /YYYY/MM/DD any longer? At least we should show the date on the blog overview page.

I'm +1 on releasing now in the current state, the only thing I'd like to see added is Google Analytics but since we don't seem to even have that on the old site then I guess we're not missing anything by making the switch as is.
@mikeal, @fhemberger, what's your call?

I'm +1 but will defer to @fhemberger since he's been more involved than I have.

@fhemberger fwiw I think moving away from /YYYY/MM/DD is a good call, although I would have ditched the categories too but it's not as big a deal. Re the vulnerability feed, I didn't know about it but I'll try and make sure it gets used properly. Might be worth documenting in our security docs though.

oh, remaining nit - latest needs to be v0.12.7 not v3.2.0

There actually is a Google Analytics snippet on the old website:
https://github.com/nodejs/nodejs.org/blob/master/doc/tracking.js
a) Do we want to continue using this exact same tracking ID in the future?
b) I don't know who has access to the anlalytics backend.

Removed the io.js releases for now, latest is now v0.12.7.
As soon as Google Analytics is added and working for the site, I'm fine with switching.

Mikeal is sorting an analytics account right now

Great, will be AFK now for a while … I'll check this thread again later.

Oh, one thing to consider: When we go live, we need to have the new navigation on the Docs pages as well.

Yeah, we can't edit what's already there unfortunately, we have to maintain it (note to @nodejs/documentation: please make all docs/ self-contained, JS, CSS etc. included, preferably not with too much integration with the rest of the site).
Check out https://nodejs.org/docs/latest/ which is v0.12.7, this will remain along with previous versions of the same styling, e.g. https://nodejs.org/docs/v0.12.7/ so we have to maintain it. I'm seeing

https://nodejs.org/pipe.css
https://nodejs.org/sh_vim-dark.css
https://nodejs.org/lfcollab.css
https://nodejs.org/static/images/walmart-thumb.jpg

So we should probably put these in somewhere permanent, either in /static/whatever, or I can put them in /docs/ somewhere, and we can put a redirect for them.
Too late for me to do anything now, gotta :zzz: and will make the switch if we're ready in ~9h or so. @fhemberger if you want to tackle these docs issues then by all means, you could check previous versions too if you can be bothered. Otherwise I can take that one. The Analytics code is the most important thing on your list I think.

I've added analytics, let me know what your google accounts are so I can add you to it.

@rvagg I think we should put those files in /static/legacy for now and redirect to that.
I don't really get why the "docs" so far have been a complete copy of the entire website, instead of just the API docs. It would be great if we could update them to use the same look and feel as https://iojs.org/api/

let's write off old docs and make sure @nodejs/documentation changes the way we ship /docs/ in the future. I'll get those legacy files in and the redirects up, I want to launch this thing in the next couple of hours

@nodejs/collaborators I've just flipped the DNS switch to the new site, please tune in to any potential issues that you may experience out there in userland given all the dependencies on the site working in very particular ways. I'll be around to fight fires if anything comes up but please make sure they are surfaced either on this repo or the main nodejs/node repo.
Also, if you don't like the new site, then don't complain, contribute here.

@snostorm Do we still need the following files/dirs?
public/index.html
scripts/tasks/*
gulpfile.js

I'm thinking about moving a few things:
plugins -> scripts/plugins
build.js -> scripts/build.js
load-versions.js -> scripts/load-versions.js (and add npm task for it)
source/versions.json -> scripts/versions.json (as it is fetched by load-versions.js)

@mikeal Can you add me to Google Analytics please? My email address is on the readme: https://github.com/nodejs/new.nodejs.org/blob/master/README.md
(And as we're online now, I'm closing this issue)

@fhemberger added, sorry that it took so long :(

@mikeal No worries! Wasn't sure you got my mail.


feat: initializing industry preferences

Changes

Create two dependent dropdowns for filters.
Found and changed all occurrences of IndustryBear to Aspire within documents such as the Code of Conduct and Contributing files.

Note

The background needs to be coded to be responsive. I will create another PR for this task.

UI

A lot of changes have been made since this PR has opened and the mockup has been updated. Therefore, let's close this.


[backport] Add ability to access aws ssh keys to EKS

backport of https://github.com/rancher/rancher/issues/14598

UI issue is here: https://github.com/rancher/rancher/issues/21433

UI not merged yet

The feature is validated on Rancher:v2.2-head 8268cd5f
Steps:

provision an EKS from Ranch, and during the configuration, choose a key pair from the drop-down list

Result:

the EKS cluster is up
check the instances in AWS console and confirm that the key pair name is the same as I chose.
can ssh to the instances by using  the key I chose (this step requires configuring the security group)


Try to ignore path dependencies for depndabot

Depndabot failed because it couldn't find the dependencies. They're path dependencies that we assume will be in ./cedar, but that's not populated for dependabot. Don't know if this will work. AFAIK the only way to check is merging

tried this on a for and it didn't work


Default feature label/geom options

The app currently has the following options for adding a "zone" to the street:

'Parking'
'No Parking'
'Stopping'
'No Stopping'
'Loading'
'Standing'
'No Standing'
'Travel Lane'

Let's try out the following for our first round of testing. I know this is a mix of assets and regs, but let's give it a go anyway. I've included the geometry type in parentheses.

Parking (span)
No parking (span)
Loading (span)
No stopping (span)
Curb cut (span)
Paint (span)
Other zone (span)
Payment device (position)
Fire hydrant (position)
Other point (position)

Button to add these should be "add feature" instead of "add zone"

note: there could be instances where a feature fits into more than one category. that's fine - it doesn't really matter which label someone uses (it's just for sorting later). there just always needs to be at least one label for whatever someone sees on the street.

starting on this now -- flagging that this is a major lift, as it breaks the previous span-only framework for data, rolling behavior, available actions, and progress bar UI, in order to accommodate positions

okay. this is something we could bump to a later version if you want to prioritize other things.

Nah, the sooner we tackle this piece the better. I've implemented a lot of the changes in this commit:
Semantics and data

Transition from "zone" to "feature" terminology:  but the presence of position things means that not everything is a zone anymore. Not comprehensive yet, but moving toward "curb feature" or "feature".

Updated feature types: the constants have been modified from a list to an object distinguishing positions from spans.

New handling of data: each feature now has a type attribute of "position" or "feature". When added positions will immediately terminate, with an end time the same as the start. This will continue to change a bit as @morganherlocker helps me adopt the backend data model on the front side here.

UI

Updated "add Feature" modal: the above constants will populate the "buttons screen". Buttons are now full-width to accommodate odd numbers of feature types.

New progress bar indicator: diamond to denote positions, differentiating from spans.

New feature actions: previously, users could delete/photograph/complete a span until they complete it, at which time all these options disappear. Lacking a span distance, the new position type immediately completes itself upon adding, making it impossible to add a photo of it.

To avoid the complexity of different action UIs for different feature types, all features can now be deleted and photographed throughout the survey, even after spans are completed:

After completion:

https://github.com/sharedstreets/curb-wheel/pull/68


An unhandled exception has ocurred.

Issue Description
I get a stack trace when I startt the client.
Reproduction Steps

Start King Phisher Server
Start King Phisher Client
Login with my Credentials, and start connection with server OK.
Few seconds later, appears this :

Error Details / Stack Trace
Copy details from the logs or client dialog here.
daemon=False)

Stack Trace:
Traceback (most recent call last):
  File "/usr/share/king-phisher/king_phisher/client/tabs/campaign.py", line 393, in loader_idle_routine
    self.logger.debug('idle loader routine called')
  File "/usr/lib/python2.7/logging/__init__.py", line 1147, in debug
    self._log(DEBUG, msg, args, **kwargs)
  File "/usr/lib/python2.7/logging/__init__.py", line 1277, in _log
    record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
  File "/usr/lib/python2.7/logging/__init__.py", line 1251, in makeRecord
    rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func)
  File "/usr/lib/python2.7/logging/__init__.py", line 285, in __init__
    self.threadName = threading.current_thread().name
  File "/usr/lib/python2.7/threading.py", line 1151, in currentThread
    return _active[_get_ident()]
TypeError: Couldn't find foreign struct converter for 'cairo.Context'

This looks to me like a duplicate of a bug we filed with the Kali project on their bug tracker. It also looks like you're using v1.1.0 which is out of date. Can you please verify that you're using the latest version provided by Kali?
Updating would be the ideal fix, otherwise you can work around the issue by manually installing python-gi-cairo and restarting the client.

apt-get update && apt-get upgrade .....and problem SOLVED!!! Thanks a lot for your support.


[Homepage] Update resource cards to 3-wide layout

[x] Span with 3 resource cards across.

current

expected

FYI @jeanservaas

@mjabbink Are we making this change of 3 resource across to the entire site? Or just to the Homepage?

Just the homepage.
In the content pages the two site nicely inside the 8-column body text.

Closing as this has been implemented https://carbondesignsystem.com/


CDN can not delivery compressed checkout.js

Description
Merchants of our ecommerce platform complain to us that the PayPal checkout button is not displayed for a long time. Customers don't know how to pay and leave the store. We found out reason - it's a slow download checkout.js.
For some regions paypal CDN can not delivery compressed content. So checkout.js has excessive size.
Steps to reproduce
For example when I change DNS server to <IP_ADDRESS>:
nslookup OUTPUT:

host-57:~ user$ nslookup www.paypalobjects.com
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53
Non-authoritative answer:
www.paypalobjects.com	canonical name = geo.paypalobjects.com.akadns.net.
geo.paypalobjects.com.akadns.net	canonical name = pprussia.www.direct.paypalobjects.com.akadns.net.
Name:	pprussia.www.direct.paypalobjects.com.akadns.net
Address: <IP_ADDRESS>

curl OUTPUT:

host-57:~ user$ curl -I 'https://www.paypalobjects.com/api/checkout.min.js' --compressed
HTTP/1.1 200 OK
Server: Apache
Last-Modified: Thu, 15 Mar 2018 15:58:01 GMT
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Content-Type: application/x-javascript
Connection: Keep-Alive
Date: Fri, 16 Mar 2018 14:07:02 GMT
Age: 3314
Content-Length: 902909
host-57:~ user$ curl -s -w "Takes %{time_total}s, downloaded %{size_download} bytes\n" 'https://www.paypalobjects.com/api/checkout.min.js' -H 'Content-Type: application/x-javascript;charset=utf-8' --compressed -o /dev/null
Takes 18,628747s, downloaded 902909 bytes

Pay attention to the Content-Length header ~ 882KB. Also content is not compressed (response have no header content-encoding = gzip). And finally download js took 18.6s - it's too much.
When I change DNS server to <IP_ADDRESS> everything gets better
nslookup OUTPUT:

host-57:~ user$ nslookup www.paypalobjects.com
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53
Non-authoritative answer:
www.paypalobjects.com	canonical name = geo.paypalobjects.com.akadns.net.
geo.paypalobjects.com.akadns.net	canonical name = hotspot.paypalobjects.com.akadns.net.
hotspot.paypalobjects.com.akadns.net	canonical name = www.paypalobjects.com.edgekey.net.
www.paypalobjects.com.edgekey.net	canonical name = e3691.g.akamaiedge.net.
Name:	e3691.g.akamaiedge.net
Address: <IP_ADDRESS>

curl OUTPUT:

host-57:~ user$ curl -I 'https://www.paypalobjects.com/api/checkout.min.js' --compressed
HTTP/1.1 200 OK
Server: Apache
Last-Modified: Thu, 15 Mar 2018 15:58:01 GMT
Accept-Ranges: bytes
Content-Type: application/x-javascript
Content-Encoding: gzip
Content-Length: 134866
Cache-Control: max-age=86400
Expires: Sat, 17 Mar 2018 14:34:56 GMT
Date: Fri, 16 Mar 2018 14:34:56 GMT
Connection: keep-alive
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
host-57:~ user$ curl -s -w "Takes %{time_total}s, downloaded %{size_download} bytes\n" 'https://www.paypalobjects.com/api/checkout.min.js' -H 'Content-Type: application/x-javascript;charset=utf-8' --compressed -o /dev/null
Takes 0,550980s, downloaded 134866 bytes

We get results:

content length: 902909 bytes vs 134866 bytes
download time: 18,628747s vs 0,550980s

Please fix it ASAP: this issue reduces the sales in stores of our merchants
Affected browsers

[+] Chrome
[+] Safari
[+] Firefox
[+] Edge
[+] IE
[+] Chrome Mobile/Tablet
[+] Safari Mobile/Tablet
[+] Web View / Safari ViewController
[+] Other

Are you still seeing this issue? Should have been resolved, looks like there was an issue with gzip on our CDN.

Are you still seeing this issue?
Yes! I still reproduce this issue.
For example I reproduce it with DNS server <IP_ADDRESS>

nslookup OUTPUT:

host-57:~ user$ nslookup www.paypalobjects.com
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53
Non-authoritative answer:
www.paypalobjects.com	canonical name = geo.paypalobjects.com.akadns.net.
geo.paypalobjects.com.akadns.net	canonical name = >pprussia.www.direct.paypalobjects.com.akadns.net.
Name:	pprussia.www.direct.paypalobjects.com.akadns.net
Address: <IP_ADDRESS>

curl OUTPUT:

host-57:~ user$ curl -I 'https://www.paypalobjects.com/api/checkout.min.js' --compressed
HTTP/1.1 200 OK
Server: Apache
Last-Modified: Fri, 23 Mar 2018 21:51:58 GMT
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Content-Type: application/x-javascript
Connection: Keep-Alive
Date: Fri, 30 Mar 2018 05:14:42 GMT
Age: 1607
Content-Length: 903473
Still not compressed

Ok thanks for the heads-up, let me follow up on this one.

I've checked on this and the resource is gzipped.
No. I still reproduce this issue.

nslookup OUTPUT

host-57:~ user$ nslookup www.paypalobjects.com
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53
Non-authoritative answer:
www.paypalobjects.com	canonical name = geo.paypalobjects.com.akadns.net.
geo.paypalobjects.com.akadns.net	canonical name = >pprussia.www.direct.paypalobjects.com.akadns.net.
Name:	pprussia.www.direct.paypalobjects.com.akadns.net
Address: <IP_ADDRESS>

curl OUTPUT

host-57:~ user$ curl -G 'https://www.paypalobjects.com/api/checkout.min.js' --compressed > out
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  919k  100  919k    0     0  1794k      0 --:--:-- --:--:-- --:--:-- 1798k

@bluepnume How can I help you investigate this issue? What more information can I provide for investigation?


feat(linux): use system xdg-open when available

xdg-open is already available in many desktop linux distributions. This PR changes the code to detect if it is available on the system and uses that one if detected.
This will fix:

supplied/bundled xdg-open not compatible with your Linux distribution (Did not encouter this yet but could be a potential issue)
when bundling your app with tools like https://github.com/zeit/pkg, it is not possible to include the xdg-open from this repo in the executable. You need to put the xdg-open file in the same directory as your project/app executable, which I'd like to avoid. Should fix #61 for most of the users. (Related: https://github.com/zeit/pkg/issues/213)

I am aware that users on linux without xdg-open installed will still have issues, when this lib is bundled via pkg, but I think this risk is acceptable. Especially because when supplying the app via a package manager like apt, a dependency to xdg-utils should do the trick.
What do you think @sindresorhus ?
:)

Many Linux distributions have outdated xdg-open versions missing important bug fixes. Bundling xdg-open have stability and consistency benefits. I want this package to just work out of the box for all Linux users when used with normal Node.js.

supplied/bundled xdg-open not compatible with your Linux distribution (Did not encouter this yet but could be a potential issue)

I'm not going to change anything based on potential issues.

when bundling your app with tools like zeit/pkg, it is not possible to include the xdg-open from this repo in the executable. You need to put the xdg-open file in the same directory as your project/app executable, which I'd like to avoid.

I stand by my comment in #61, I should not have to specially work around random tools. This was already marked as fixed in pkg, but it seems like the fix was not correct and additional comments on https://github.com/zeit/pkg/issues/207 are ignored. Try opening a new issue on pkg about this.

Alright. Understandable reasons for you package. Thank you for your quick response.
Just want to point out it is not really a bug in pkg, it is more like a inconvenience / UX problem and not that verbose documentation on pkg side.
Will move the detection into our project to use xdg-open directly when available.

We worked around via:
  if (['win32', 'darwin'].includes(process.platform)) {
    await opn(URL, {
      wait: false
    })
  } else if (await commandExists('xdg-open')) {
    await execa('xdg-open', [URL])
  } else {
    log(`Unable to open your browser automatically. Please open the following URI in your browser:\n\n${URL}`)
  }

Thanks @axe312ger
I ve put in on npm https://github.com/zoutepopcorn/opn-pkg

You can also do something like this as a workaround to point to system's xdg-open
      let opnOpts: {app?: string | string[]};
      if (['win32', 'darwin'].includes(process.platform)) {
        opnOpts = {};
      } else {
        opnOpts = {app: 'xdg-open'};
      }
      return opn(`http://localhost:${port}/client`, opnOpts);