Update what-is-sap-ai-core-d029a32.md

Thank you for allowing me to take part to this journey!

Thank you for your feedback! We’ll look into it and come back to you if we have any questions.

Thank you for taking the time to contribute to our documentation. On this occasion, we cannot implement your suggestion, but we look forward to your future contributions.


Setup a Gitter or Slack room

to better facilitate communication between members lets consider creating a Gitter or Slack chatroom. I recommend Gitter since it is free and doesnt require a paid account, just need a github account.
Once created we should link to it with a gitter badge from the readme.

We already use riot.im actively as a "IRC Client with benefits" for the #nars room. Not sure about Gitter (don't know about it) but I would surely never switch to a closed-source solution such as Slack here.

I dont like slack either, so I'm with you on that. I used riot.im before,
not a fan, but not opposed to using it. Gitter is just more popular and
integrated with GitHub so may be worth considering.
On Wed, May 2, 2018 at 8:42 PM, patham9<EMAIL_ADDRESS>wrote:

We already use riot.im actively as a "IRC Client with benefits" for the
#nars room. Not sure about Gitter (don't know about it) but I would surely
never switch to a closed-source solution such as Slack here.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/opennars/opennars/issues/103#issuecomment-386163456,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC5JAlqwRUMlt_1E7dd2mnjJUabSyKOUks5tulKGgaJpZM4TwWUM
.

If you guys decide you want to stick with IRC we should close this ticket and create a new one to add the info to the readme.

I like Gitter but it is something else we will have to monitor. I suggest that we review our position on this in 3 months time. This will allow us to see what impact the current project changes have on the contributor base.

ok - there are a few changes required to the READ.ME so I will consolidate and do one commit later today. I'll leave this open until I merge the changes.

this was already added.


Drop hard-coded part in URL - close #43

Hello,
In reference to #43 I suggest this kind of update
This should be put only in minor realese, due add functionality in a backwards-compatible manner.
Greetings,

Please also provide some updated documentation, showing how to include the urlpatterns at the old path.

Any update in here? I just want to disable the hardcoded url and use the admin for checking sessions

Feel free to take that PR. I no longer developer anything in Django.

I just made another url with the same hardcoded one but redirects it to a blank page, this effectively disables the hardcoded link.


feature request add recursivity

when adding a folder it only compresses the first level i request a parameter to indicate that you want all the subtree being also minified and to create same structure in the target dir that exists in de source dir

sorry not familiarized with the **/*.js pattern you can delete this feature request


Shift+arrows don't work in search field

Seems to work for me. Seeing it's an old issue, I went back to v1.0, and it worked in all the versions I tried.

Hmmm, no idea... Maybe something changed with BTextControl? No matter, closing issue.


Post canonicalization bug

Hmm, interesting bug. If I post to Mastodon and Takahē with something like the following:
first line

Second line
third line

fourth line

Mastodon will store this as:

Testing something, will delete this

Second line
Third line

Fourth line

And Takahē will store it as

Testing with multiple lines

One blank since the last line
No blanks since the last line

Two blanks since the last

(sorry. the message content doesn't match because I was copying from several instances, but the raw data is copied from djadmin)
Web clients render the two results roughly the same, but mobile clients render the Takahē result dramatically differently, as seen in the screenshot (confirmed on Ivory and official Mastodon client).
Example post: https://takahe.tabletcorry.com/<EMAIL_ADDRESS>Example rendering in mobile client:

I think the fix is to remove the blank lines from Takahē's post storage? And possibly use a self-closing break tag.

 Yes, we can totally remove the extra newlines. I don't think the  should matter though.

Yeah, it's pretty strange.
Agreed the break tag shouldn't matter, and the only reason to switch would be to more closely align to Mastodon formatting.


[KOGITO-2635] - Preparing release 0.12.0

Signed-off-by: Ricardo Zanini<EMAIL_ADDRESS>See: https://issues.redhat.com/browse/KOGITO-2635
Small adjustments in the manifest to release the 0.12.0 version.
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster

Community Operators PR: https://github.com/operator-framework/community-operators/pull/1969
Upstream Operators PR: https://github.com/operator-framework/community-operators/pull/1970


Drop macros

While I understand the value some appreciate from "power assertions" and similar, I think that this library should keep things simple and not introduce its own macros.
I agree that sourcecode's macros should roll into Scala proper, and once that's the case this library can make use of that.  But nice-to-haves like power assertions should probably live elsewhere, on some "shiny things" shelf.
JUnit seems to have done well without needing macros.
Here's an example of the kind of pitfalls of using macros: https://github.com/lampepfl/dotty/issues/7128

I agree. JUnit's API is actually very friendly and reports very good error messages. Power asserts are overrated.

I'd say having a well-functioning power assertion macro in the core library has equal or more value to having scala-verify itself, and same for SourceCode. After all, people are able to test things today using whatever test frameworks, and they could also adopt JUnit 4 or 5 if that fits their needs. The point of scala-verify is to implement something that's cross-platform, zero-dependency, and minimal.
My interpretation of minimal here is not the-smallest-implementation-there-could-be (that would be Predef.assert), but aiming to remove unnecessary API or things user needs to memorize. I'm not saying that it's the best thing in this life (Paul said that), but power assertion IMO has decent enough UX for very little to memorize, which is the essence of minimalism.
Also the fact that we are surfacing problems with Dotty (or my attempt at Dotty macros) is a feature, not a bug. Dotty is still in beta, and by having a library that tries to use it we can catch its bugs and fix either scala-verify or Dotty itself.

I welcome experiments that excercise Dotty's macros, but that's not a good reason to use them here.
Power assertions can always be added later, if we find we can't live without them.

One reason I never bothered to introduce fancy macro-powered assertions in Minitest is that whenever I felt the need for a better error message, I would use the optional hint parameter, which I believe is what people also do in JUnit.
 Similarly for other types of messages.
Having a "power asserts" micro-library in the ecosystem would be great though and this nanotest-strawman lib could even provide quick integration with it, as a sub-project.
I like to say that the biggest barrier to entry for Scala beginners are the macros and the macro-enabled libraries, due to all of the edge-cases and the weird errors, that beginners are destined to fall into.

if we find we can't live without them

Doesn't seem to be that much of a big deal

JUnit seems to have done well without needing macros

I can follow these points, yes we can live without them. But I don't agree that this means it's better not to have them in this library. I agree with @eed3si9n, it's a nice, easy to use, time-saving feature.

I didn't like utest's macros for reasons I expect to find using this/expecty's macros: it's fiddly on unimportant details such as whether you inline or val things.  In utest's case I inlined things and the output was of no use.  Here I expect to find much the same.
Take the example in https://github.com/eed3si9n/expecty#code-examples.  If you write
assert(person.say(word1, word2) == "pong pong")

then you get
assert(person.say(word1, word2) == "pong pong")
       |      |   |      |      |
       |      |   ping   pong   false
       |      ping pong
       Person(Fred,42)

But if you chose to allocate the result of calling person.say to a val, then you get nothing useful.  Or if you don't allocate the person but define it inline (assert(Person("Fred", 42).say ...) then you get even more output.
Now imagine Person is a 10 field case class, and I have a List of 3 of them and do:
assert(List(fred, bob, john) == foo.getOwners)

Now I'm getting 3x10 fields for the 3 Persons, then another 3x10 fields for the LHF List itself, then another 3x10 fields for the RHS List.  How does that look?  How does it truncate?  How customisable is it?
This whole power assertion thing looks great on paper, but I think it doesn't work well in practice.
Power assertion look to me like a fad, much like the 10 different styles of doing "unit testing" the ScalaTest ships with.
I suggest withholding adding such fads to such an important library I hoped this library would become.

The most useful feature is printing the left and right values if an assertion fails, ideally with some nice diffing. I agree that seeing all the sub-expressions is not crucial and has various pitfalls. To underline that, in the example it's not obvious to spot the "ping pong" string (which is the left value of the assertion) between all the other output.

I can follow these points, yes we can live without them. But I don't agree that this means it's better not to have them in this library. I agree with @eed3si9n, it's a nice, easy to use, time-saving feature.

It's a time-saving feature, but consider that it's the kind of feature that needs to be maintained and maintenance isn't necessarily cheap.
Macros are sensitive to changes in the compiler's internals, their API being unstable still, so whenever a new Scala version happens, you end up doing fixes for supporting the new version, or waiting on compiler plugins to be published first.
Not sure if nanotest-strawman still wants to support Scala 2.10 or 2.11 for example, but I've had many problems with 2.10 and even 2.11 in getting macros to work. I crashed that compiler so many times with no idea of how or why, desperately trying out changes in order to make it not crash. Working with macros in Scala, at least with 2.10, but also in newer versions, involves a lot of tribal knowledge (e.g. this tree is now dirty, don't do that twice, this expression can trigger this or that issue so tree needs to be rewritten, etc).
And we might say that we should no longer care about Scala 2.10 or 2.11, however if maintaining a 2.10 build is hard, then adopting Scala 2.14 or other future versions will be hard as well.
So in my opinion, a feature might be useful, but maintainer time matters more, especially if you want this library to be always available on new Scala versions and platforms, which I assume is the purpose of the project.

Remotely related, we can consider integrating https://github.com/xdotai/diff

I'm not sure if scala.quoted macros will be stable in Scala 3, but https://github.com/scala/nanotest-strawman/pull/44 is a fresh data point on the "Macros are sensitive to changes in the compiler's internals" case.

If the goal of this lib is to have something that we can easily publish for each Scala version then we should probably move the macros to some optional module because they will for sure require more upgrade work.

https://github.com/eed3si9n/expecty is that other module (in my eyes).

Tried to see if the new Dotty and Verify releases fixed https://github.com/lampepfl/dotty/issues/7128#issuecomment-571505284, but sadly not.  Verify is still unusable as a testing library on Dotty due to its use of macros.

Verify is still unusable as a testing library on Dotty

meta-issue: why isn't CI telling us that?

I don't know why CI isn't catching some use cases but the diff like
-    import qctx.tasty._
+    import qctx.tasty.{ _, given }

in https://github.com/scala/nanotest-strawman/pull/44 has nothing to do with macros. It's to do with implicit/givens related language changes that are happening in Dotty. This is somewhat expected if you write a library on top of a language that's not feature frozen. https://contributors.scala-lang.org/t/preparing-for-feature-freeze/3780 said 0.20 will be the last, but there's another PR to change the syntax again.

Of course it does:

the reason that I couldn't use (and continue to not be able to use) scala-verify is because of macros: https://github.com/lampepfl/dotty/issues/7128
the reason that scala-verify was unusable with Dotty 0.20 (#41) and upgrading from Dotty 0.19 to 0.21 took a while (#44) is becomes of macros

Also the fact that we are surfacing problems with Dotty (or my attempt at Dotty macros) is a feature, not a bug. Dotty is still in beta, and by having a library that tries to use it we can catch its bugs and fix either scala-verify or Dotty itself.

You mentioned this earlier.  Why don't you make expecty that experiment, and let scala-verify be readily available to start testing across Scala/Dotty?

are verify and/or expecty in the Dotty community build? that could be a mechanism for making sure either or both are up to date with the latest Dotty changes ahead of time, rather than after a new Dotty is released

Power assertion look to me like a fad

Another recent example of power assertion being a gimmick:
[info] - cancel on-going task with string id *** FAILED ***
[info]   assertion failed
[info]
[info]   assert(svr.waitForString(1.minute) { s =>
[info]              |             | |           |
[info]              false         | 1 minute    testpkg.EventsTest$$$Lambda$330/0x00000001003c0840@248d118
[info]                            scala.concurrent.duration.package$DurationInt@1

gimmick is a bit harsh. Let's compare the two:
Predef.assert
[info] - cancel on-going task with string id *** FAILED ***
[info]   assertion failed

Verify's assert
[info] - cancel on-going task with string id *** FAILED ***
[info]   assertion failed
[info]
[info]   assert(svr.waitForString(1.minute) { s =>
[info]              |             | |           |
[info]              false         | 1 minute    testpkg.EventsTest$$$Lambda$330/0x00000001003c0840@248d118
[info]                            scala.concurrent.duration.package$DurationInt@1

Without providing custom error message, I can tell that the failed assertion was about 1.minute timeout.


/usr/bin/ld: libpoly.a(controller.cpp.o):(.bss+0x8): multiple definition of `polybar::socket_util::make_unix_connection'; libpoly.a(bar.cpp.o):(.bss+0x0): first defined here

I'm using the AUR package
yay -S polybar
error
/usr/bin/ld: libpoly.a(controller.cpp.o):(.bss+0x8): multiple definition of `polybar::socket_util::make_unix_connection'; libpoly.a(bar.cpp.o):(.bss+0x0): first defined here
/usr/bin/ld: libpoly.a(bspwm.cpp.o):(.bss+0x0): multiple definition of `polybar::socket_util::make_unix_connection'; libpoly.a(bar.cpp.o):(.bss+0x0): first defined here
/usr/bin/ld: libpoly.a(bspwm.cpp.o):(.bss+0x0): multiple definition of `polybar::socket_util::make_unix_connection'; libpoly.a(bar.cpp.o):(.bss+0x0): first defined here
/usr/bin/ld: libpoly.a(i3.cpp.o):(.bss+0x0): multiple definition of `polybar::socket_util::make_unix_connection'; libpoly.a(bar.cpp.o):(.bss+0x0): first defined here
/usr/bin/ld: libpoly.a(socket.cpp.o):(.bss+0x0): multiple definition of `polybar::socket_util::make_unix_connection'; libpoly.a(bar.cpp.o):(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [bin/CMakeFiles/polybar.dir/build.make:115: bin/polybar] Error 1
make[1]: *** [CMakeFiles/Makefile2:625: bin/CMakeFiles/polybar.dir/all] Error 2
make: *** [Makefile:150: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
Error making: polybar-git

Environment:

Arch-linux
WM: i3-gaps

Got this issue after gcc was upgraded to 10.1.0. It worked on 9.3.0.

Got this issue after gcc was upgraded to 10.1.0. It worked on 9.3.0.

this worked, i wish they could fix that

Manual build using Clang does work. Invoke cmake with CXX=/bin/clang++ cmake ...
I'm on Arch with the Xmonad WM and Clang 10.0.0

Related: https://gcc.gnu.org/gcc-10/porting_to.html

A common mistake in C is omitting extern when declaring a global variable in a header file. GCC 10 defaults to -fno-common, which means a linker error will now be reported.

If anyone else is having this issue on Arch you can solve it manually by downgrading to gcc 9.
Either downgrade if you still have the old cached version or download them from
https://archive.archlinux.org/packages/g/gcc/gcc-9.3.0-1-x86_64.pkg.tar.zst
and
https://archive.archlinux.org/packages/g/gcc-libs/gcc-libs-9.3.0-1-x86_64.pkg.tar.zst
And install using pacman -U gcc-9.3.0-1-x86_64.pkg.tar.zst gcc-libs-9.3.0-1-x86_64.pkg.tar.zst. It's important to downgrade both at the same time because one depends on the other.
In the end I guess this is up to the polybar authors to change buildfiles or stick to the new default:

To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file.

I made a fix in #2098.
@scrouthtv Downgrading the c library is quite dangerous since it'll make your applications/kernel unstable.


[5.0] [CMake] Disable generation of .swiftinterface files

Explanation: Places the generation of swiftinterface files for the standard library and overlays behind a flag, which is off by default. We haven't finished implementing this feature, so we shouldn't ship it in toolchains.

Scope: CMake changes only. Nothing was using these files except tests.

Issue: rdar://problem/44942414

Risk: None

Testing: Checked that regression tests using these files are properly ignored when they are not present.

Reviewed by: @Rostepher, @compnerd

@swift-ci Please test

@swift-ci Please clean smoke test


Initial work on toggling the artwork metadata

Note: This PR goes into #1396
Initial work on being able to show / hide the artwork information - will comment inline

:+1:

hrm, I did contact them about that

1 Error

:no_entry_sign:
No CHANGELOG changes made

2 Warnings

:warning:
Needs testing on a Phone if change is non-trivial

:warning:
Found unstubbbed networking requests

ARFairFavoritesNetworkModelSpec in test_ignores_artworks_without_a_partner
ARFairFavoritesNetworkModelSpec in test_ignores_artworks_without_a_partner
ARFairFavoritesNetworkModelSpec in test_ignores_artworks_without_a_partner

  Generated by :no_entry_sign: danger

Tests pass, it's just danger, will submit a changelog entry for it on my next PR :+1:


Document channel branches and release channels

Problem
Currently the NixOS Wiki page has some of the best information on how releases work.
Yet, it's extremely misleading with its page title and subtly wrong description of channels.
Proposal

document release channels upstream in the Nixpkgs contributor guide on the change propagation workflow
establish the relationship between release branches, "channel branches" (new term), and (release) channels
link to the Nix manual for authoritative documentation on channels

still a bit messy at the moment, but all the information is there, somewhere):

https://nixos.org/manual/nix/unstable/command-ref/files/channels
https://nixos.org/manual/nix/unstable/command-ref/nix-channel

release-: the master of the release channels ; this is where all changes go in and accumulate until they are picked up by Hydra to be copied over nixos- or nixpkgs-*
nixos-: NixOS releases channel pointer (usage: NixOS)
nixpkgs-: Nixpkgs releases channel pointer (usage: macOS, non-NixOS usecases)
Hydra copies from release-* to nixos-* and nixpkgs-* depending on the situation (channel tests, etc.): https://status.nixos.org/
You push to release-*, you pull from nixos-* or nixpkgs-*

Because this is such a vital part both for end users and daily operations, we don't want to keep it in the wiki -- in this case not because the information is likely to diverge as that stuff won't change any time soon, but because it's really important to get it right and perfectly clear. And change reviews on the Wiki are impractical.
Discussed with @NixOS/documentation-team (specifically @alejandrosame @proofconstruction @wamirez) and @RaitoBezarius.
Checklist

[x] checked latest Nixpkgs manual (source) and latest NixOS manual (source)
[x] checked open documentation issues for possible duplicates
[x] checked open documentation pull requests for possible solutions

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-10-23-documentation-team-meeting-notes-88/34562/1

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-10-30-documentation-team-meeting-notes-90/34936/1


[FEATURE]: Improved documentation on "upsert" behavior

Describe what you want
The current docs do not clearly explain what each option in the .onConflictDoUpdate method actually does.

It's a 1 to 1 mapping to the SQL on conflict clause - https://www.postgresql.org/docs/current/sql-insert.html#SQL-ON-CONFLICT
all it does is adding this clause to the query

The docs have been improved. We have now a section in the insert for Upserts and conflicts


Tip: When creating widget for an app, add this!

The tutorial at Android Authority had me stumped a bit as it did not work. When building a widget into an existing app, it is necessary to add a few lines to the receiver declaration. Add an icon and label to the tag for the widget to appear!
android:icon="@drawable/icon"  android:label="Example Widget"
Hope this helps!

Great tip @searchy2. Thanks.


Kong version (v0.13.0)
Postgres 10.3
Centos 7

No, it means that your load balancer is empty. There are no targets left.
The default has 10000 positions, which will be distributed over the targets you add. In this case there are no targets left and they remain unassigned

@Tieske In any case, a [warn] level message saying dropped=10000 in a forward proxy is a pretty scary thing and likely to cause further user confusing. Maybe that's a case for renaming the message to removed= (or even deleted=, to better match the DELETE operation). (To be honest, I'm not understanding why it says dropped and assigned=0 in the POST /upstreams/_/targets operations as well.)
Alternatively, if the above messages are nothing to worry about, do we need the internals of the load balancer to be exposed as a warning each time it does its normal operation?

@hishamhm that message is only logged at the end of a balancer update, which happens on add/delete targets, or on requery the dns for a target, with changed dns results. That's when indices get redistributed.
see: https://github.com/Kong/lua-resty-dns-client/blob/master/src/resty/dns/balancer/ring.lua#L238-L241
The warning is logged only when "assigned" hits 0
I think the OP was scripting against the mgt api, causing a number of those messages to appear in a short window.


Fixes to router/app init method

Idiot-proofed ACP so an incorrectly defined route won't brick NodeBB
Added support for subdirectories
Using router helper instead of defining route+apiRoute.

Clared for v0.9.x/v1.x.x

thanks :+1:


[VMware] Update data disk controller same as the root disk controller type when it is not set in the VM detail

Description
This PR updates data disk controller (in VMware) same as the root disk controller type when it is not set in the VM detail. This is to ensure the disk controller is available for the data disks, as all the SCSI controllers are created with same controller type.
Fixes #9400

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)
[ ] build/CI
[ ] test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[x] Major
[ ] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?
Manually testing with Paravirtual controller (pvscsi) as the root disk controller.
Before =>

After =>

How did you try to break this feature and the system with this change?

@blueorangutan package

@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el7 ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10443

@blueorangutan help

@sureshanaparti [SL] I understand these words: "help", "hello", "thanks", "package", "test"
Test command usage: test [mgmt os] [hypervisor] [keepEnv] [qemuEv] [basicZone|securityGroups]
Mgmt OS options: ['centos7', 'centos6', 'alma9', 'suse15', 'alma8', 'ubuntu18', 'ubuntu22', 'ubuntu20', 'rocky8', 'ubuntu24']
Hypervisor options: ['kvm-centos6', 'kvm-centos7', 'kvm-rocky8', 'kvm-alma8', 'kvm-alma9', 'kvm-ubuntu18', 'kvm-ubuntu20', 'kvm-ubuntu22', 'kvm-ubuntu24', 'kvm-suse15', 'vmware-55u3', 'vmware-60u2', 'vmware-65u2', 'vmware-67u3', 'vmware-70u1', 'vmware-70u2', 'vmware-70u3', 'vmware-80', 'vmware-80u1', 'xenserver-65sp1', 'xenserver-71', 'xenserver-74', 'xcpng74', 'xcpng76', 'xcpng80', 'xcpng81', 'xcpng82']
Note: when keepEnv is passed, you need to specify mgmt server os and hypervisor or use the matrix command.
when qemuEv is passed, it will deploy KVM hyperviosr hosts with qemu-kvm-ev, else it will default to stock qemu.
When basicZone and/or securityGroups are passed it will create a zone of the last type specified (default is Advanced)
Package command usage: package [all(default value),kvm,xen,vmware,hyperv,ovm] - a comma separated list can be passed with package command to bundle the required hypervisor's systemVM templates. Not passing any argument will bundle all - kvm,xen and vmware templates.
Blessed contributors for kicking Trillian test jobs: ['rohityadavcloud', 'shwstppr', 'vishesh92', 'Pearl1594', 'harikrishna-patnala', 'nvazquez', 'DaanHoogland', 'weizhouapache', 'borisstoyanov', 'vladimirpetrov', 'kiranchavala', 'andrijapanicsb', 'NuxRo', 'rajujith', 'alexandremattioli', 'sureshanaparti', 'mlsorensen', 'oscaralvaro', 'abh1sar']

@blueorangutan test centos7 vmware-80

@sureshanaparti a [SL] Trillian-Jenkins test job (centos7 mgmt + vmware-80) has been kicked to run smoke tests

[SF] Trillian test result (tid-10944)
Environment: vmware-80 (x2), Advanced Networking with Mgmt server 7
Total time taken: 73848 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9433-t10944-vmware-80.zip
Smoke tests completed. 131 look OK, 1 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test
Result
Time (s)
Test File

test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true
Error
3606.47
test_routers_network_ops.py

test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false
Error
1631.60
test_routers_network_ops.py

@blueorangutan package

@blueorangutan package

@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10740

I have not tested in a VMware environment to confirm, but is this really fixing the issue when attaching a volume? The volume attach workflow does not seem to use the changed code.
From what I could gather by reading the code, the problem happens because CloudStack tries to attach the data disks using default SCSI controllers (LSI Logic), but there are only PVSCSI controllers. I think that changing the data disk controllers to LSI Logic (while having PVSCSI root disk controllers) and trying to attach a data disk should still produce the same error.
If that is the case, maybe it would be good to prioritize using the root disk controllers for data disks on the volume attach workflow in case both are SCSI?

I have not tested in a VMware environment to confirm, but is this really fixing the issue when attaching a volume? The volume attach workflow does not seem to use the changed code.
From what I could gather by reading the code, the problem happens because CloudStack tries to attach the data disks using default SCSI controllers (LSI Logic), but there are only PVSCSI controllers. I think that changing the data disk controllers to LSI Logic (while having PVSCSI root disk controllers) and trying to attach a data disk should still produce the same error.
If that is the case, maybe it would be good to prioritize using the root disk controllers for data disks on the volume attach workflow in case both are SCSI?

All the disk controllers in VMware VM are created using the type mentioned in root disk controller (primary controller), so the data disk controller should match with that controller type to support attach data volume. If data disk controller has a different controller type, attach fails as it is not found in the VM spec.
In this case, when data disk controller is not set, previously it was set to osdefault, which picks the default controller type (say, lsilogic) for that OS and might not be the same as root disk controller (say, pvscsi). so, it's better to sync the data disk controller (when not set) with root disk controller.

@blueorangutan package

@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result [SF]: ✔ el8 ✔ el9 ✔ debian ✔ suse15. SL-JID 10776

@blueorangutan test

@vladimirpetrov a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

I have not tested in a VMware environment to confirm, but is this really fixing the issue when attaching a volume? The volume attach workflow does not seem to use the changed code.
From what I could gather by reading the code, the problem happens because CloudStack tries to attach the data disks using default SCSI controllers (LSI Logic), but there are only PVSCSI controllers. I think that changing the data disk controllers to LSI Logic (while having PVSCSI root disk controllers) and trying to attach a data disk should still produce the same error.
If that is the case, maybe it would be good to prioritize using the root disk controllers for data disks on the volume attach workflow in case both are SCSI?

All the disk controllers in VMware VM are created using the same type mentioned in root disk controller (primary controller), so the data disk controller should match with that controller type created to support attach data volume. If data disk controller has a different controller type, attach fails as it is not found in the VM spec.
In this case, when data disk controller is not set, previously it was set to osdefault, which picks the default controller type (say, lsilogic) for that OS and might not be the same as root disk controller (say, pvscsi). so, it's better to sync the data disk controller (when not set) with root disk controller.

I understand that you want to synchronize the data disk controller with the root disk controller to ensure data disks can be attached. However, I think that we are doing it in the wrong place. I think that it would be better to synchronize it in the volume attachment process itself.
As you mentioned, if both root disks and data disks use SCSI controllers, the root disk controller is prioritized when creating a VM. So, suppose we have a scenario in which a template has rootDiskController set to pvscsi and dataDiskController set to osdefault or any other SCSI subtype (which is the current configuration for some existing VMs because dataDiskController defaulted to osdefault when not set): if we deploy a VM from that template with a data disk, the deployment process will prioritize using the root disk's controller (PVSCSI) for the data disk, even though dataDiskController may have been set set to something else, and the VM will be created successfully with two disks that use PVSCSI controllers. However, if we try to attach another volume to that VM (or detach and reattach the data disk), an exception will be thrown because the volume attachment process tries to attach the data disk using a LSI Logic controller instead.
To avoid this exception for these scenarios as well, I think that it would be better to fix the original issue by making the volume attachment process consistent with the VM creation process: prioritizing the root disk controller in case both details are set to SCSI subtypes, instead of matching them when the VM is created only if dataDiskController is empty.

[SF] Trillian test result (tid-11161)
Environment: kvm-ol8 (x2), Advanced Networking with Mgmt server ol8
Total time taken: 46823 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr9433-t11161-kvm-ol8.zip
Smoke tests completed. 133 look OK, 0 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test
Result
Time (s)
Test File

I have not tested in a VMware environment to confirm, but is this really fixing the issue when attaching a volume? The volume attach workflow does not seem to use the changed code.
From what I could gather by reading the code, the problem happens because CloudStack tries to attach the data disks using default SCSI controllers (LSI Logic), but there are only PVSCSI controllers. I think that changing the data disk controllers to LSI Logic (while having PVSCSI root disk controllers) and trying to attach a data disk should still produce the same error.
If that is the case, maybe it would be good to prioritize using the root disk controllers for data disks on the volume attach workflow in case both are SCSI?

All the disk controllers in VMware VM are created using the same type mentioned in root disk controller (primary controller), so the data disk controller should match with that controller type created to support attach data volume. If data disk controller has a different controller type, attach fails as it is not found in the VM spec.
In this case, when data disk controller is not set, previously it was set to osdefault, which picks the default controller type (say, lsilogic) for that OS and might not be the same as root disk controller (say, pvscsi). so, it's better to sync the data disk controller (when not set) with root disk controller.

I understand that you want to synchronize the data disk controller with the root disk controller to ensure data disks can be attached. However, I think that we are doing it in the wrong place. I think that it would be better to synchronize it in the volume attachment process itself.
As you mentioned, if both root disks and data disks use SCSI controllers, the root disk controller is prioritized when creating a VM. So, suppose we have a scenario in which a template has rootDiskController set to pvscsi and dataDiskController set to osdefault or any other SCSI subtype (which is the current configuration for some existing VMs because dataDiskController defaulted to osdefault when not set): if we deploy a VM from that template with a data disk, the deployment process will prioritize using the root disk's controller (PVSCSI) for the data disk, even though dataDiskController may have been set set to something else, and the VM will be created successfully with two disks that use PVSCSI controllers. However, if we try to attach another volume to that VM (or detach and reattach the data disk), an exception will be thrown because the volume attachment process tries to attach the data disk using a LSI Logic controller instead.
To avoid this exception for these scenarios as well, I think that it would be better to fix the original issue by making the volume attachment process consistent with the VM creation process: prioritizing the root disk controller in case both details are set to SCSI subtypes, instead of matching them when the VM is created only if dataDiskController is empty.

@winterhazel The data disk controller is matched with the SCSI root disk controller only when the data disk controller is not set in the VM's template and VM detail. If template has the root and data disk controllers set to pvscsi and osdefault respectively, then the controllers are created with pvscsi controller to ensure root disk is configured to proper controller to create the VM. Later, any unsupported data disk controller (say, lsilogic) set would fail the attach disk, so the operator should ensure to set the root and data disk controller appropriately.
As the controllers are already created during the VM creation process, it's better to synchronize these controller details during VM creation. Synchronizing in the attach process would still set the same controller details (if you mean dynamic reconfiguration of disk controllers in VM, maybe the existing controller reconfiguration based on the data disk controller can be done as a separate improvement later). The changes here would fix the attach issue when data disk controller is not set in the VM's template and VM detail.

@winterhazel are you content with @sureshanaparti 's reply?

As the controllers are already created during the VM creation process, it's better to synchronize these controller details during VM creation. Synchronizing in the attach process would still set the same controller details (if you mean dynamic reconfiguration of disk controllers in VM, maybe the existing controller reconfiguration based on the data disk controller can be done as a separate improvement later). The changes here would fix the attach issue when data disk controller is not set in the VM's template and VM detail.

@sureshanaparti I recognize that your changes fix the attachment for this case. However, they are not fixing the root of the problem, just working-around one specific situation that can lead to it. This problem does not happen because the two settings have different values. It happens due to an inconsistent behavior of the code.
I think you may have misunderstood what I'm proposing.  Just to ensure that we have the same thing in mind: my idea is execute on the volume attachment process the same logic that the VM creation/start workflows use when adding the disk controllers to the VM's spec.
Context:

Suppose we have a template that has rootDiskController set to pvscsi and dataDiskController set to lsilogic.

Important info:

VMware does allow us to create a VM using a PVSCSI for the root disk and LSI Logic controllers (two different SCSI subtypes) for the data disks.

What happens on VM creation/start:

When a VM is created/started in CloudStack, we verify the controllers defined for the root and data disk ( rootDiskController and dataDiskController details).
We see that both are using SCSI subtypes and, even though we could create one PVSCSI for the root disk and LSI Logic controllers for data disks, we intentionally ignore the dataDiskController setting defined by the operator and choose to use only PVSCSI controllers for both the root disk and the data disks.

What is happening on volume attachment:

Then, when a user tries to attach a new data disk, the process fails because we only consider dataDiskController and try to attach with LSI Logic instead. However, there are no LSI Logic controllers because we ignored the data disk controller chosen by the operator and opted to create PVSCI controllers for both root and data disks when creating/starting the VM.

My proposal:

Implement the same logic we did on VM creation/start (choosing PVSCSI instead of LSI Logic for the data disks) on volume attachment.

@winterhazel The data disk controller is matched with the SCSI root disk controller only when the data disk controller is not set in the VM's template and VM detail. If template has the root and data disk controllers set to pvscsi and osdefault respectively, then the controllers are created with pvscsi controller to ensure root disk is configured to proper controller to create the VM. Later, any unsupported data disk controller (say, lsilogic) set would fail the attach disk, so the operator should ensure to set the root and data disk controller appropriately.

I don't think we have to place the responsibility on operators in this case. The attachment fails because we ignore the dataDiskController defined by the operator and we create/start the VM using another controller instead.

@winterhazel are you content with @sureshanaparti 's reply?

@DaanHoogland I'm fine with this being merged, because I do acknowledge that the changes here and my proposal are not exclusive, and that it did fix one situation. However, I still think that #9400 should not be considered solved with this. The changes here do not touch the root of the problem, and only solve a specific case that would be covered by modifying the volume attachment workflow. I'll address it on another PR.

correct @winterhazel, this addresses specific case, that is when data disk controller is not set. we can merge this and proceed with the proposed improvement (in volume attach workflow) in another PR. cc @DaanHoogland

@DaanHoogland I'm fine with this being merged, because I do acknowledge that the changes here and my proposal are not exclusive, and that it did fix one situation. However, I still think that #9400 should not be considered solved with this. The changes here do not touch the root of the problem, and only solve a specific case that would be covered by modifying the volume attachment workflow. I'll address it on another PR.

ok, thanks @winterhazel , I'll assign #9400 to you for futher discussion/handling.


Consider increasing memory for VirtualBox

Hi folks!
I recently followed the instructions for installing BOSH onto a VirtualBox VM and then attempted to run Cloud Foundry using cf-deployment. I got everything deployed but as soon as I attempted to push an application, the staging process hung and I started getting 404s when interacting with the the CF API. Digging into the problem, I found the VirtualBox VM swapping heavily, seems the days of 4GB to run Cloud Foundry might be long gone! Increasing to 8GB VirtualBox VM got things going, I think I was hovering a little over 5GB used when CF is deployed and staging an application.
I know this isn't technically a BOSH issue, but if folks follow the docs to deploy BOSH and then CF, they'll likely have a bad day. Maybe we could add an additional operations file that is documented to increase the memory if the operator is going to be installing CF?
Nick

Hi @SocalNick, thanks for bringing this to our attention.
Another project that may be of interest to you for using CF in a dev environment is https://github.com/cloudfoundry-incubator/cfdev. There are also some recommendations there for host machine resources.
In general bosh-deployment and its usage is for development/testing for bosh. We don't generally expect people to deploy CF locally in full. Are you also using the bosh-lite opsfile for cf-deployment? https://github.com/cloudfoundry/cf-deployment/blob/master/operations/bosh-lite.yml
Closing this as it's not an issue pertaining to bosh-deployment itself, more the usage afterwards. Hopefully cf-dev can be the better tool for you.
Thanks,
Rebecca, BOSH, Pivotal

Hey @SocalNick,
After some internal discussions, we decided that we would try increasing the default virtualbox memory and cpu to their older values that used to be specified in the vagrant bosh-lite. Hopefully this helps a bit.
Best,
@jfmyers9, CF BOSH

Thanks Rebecca and Jim, I can definitely see it both ways, appreciate the default resource bump!


rouson/caffeine has moved

README.md:2830 references github.com/rouson/caffeine which I believe has moved to the LBL repository at https://github.com/berkeleylab/caffeine.
[CoArray Fortran Framework of Efficient Interfaces to Network Environments (Caffeine)](https://github.com/rouson/caffeine): parallel runtime library that aims to support Fortran compilers with a programming-model-agnostic application binary interface (ABI) to various communication libraries, by Damian Rouson et al. Current work is on supporting the ABI with the GASNet-EX or with POSIX processes.

updated link


ImportError: cannot import name 'OrderedDict' from 'typing'

I just updated scvi-tools in my mac with pip install scvi-tools --upgrade but kept having the error below.
Before this update, scvi-tools was loading smoothly in my Mac.
Any ideas of what may be going on?

import scvi
import anndata
import numpy as np
import pandas as pd
import scanpy as sc

import seaborn as sns
import matplotlib.pyplot as plt

---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-2-6fafc52a25d1> in <module>
----> 1 import scvi
      2 import anndata
      3 import numpy as np
      4 import pandas as pd
      5 import scanpy as sc

~/anaconda3/lib/python3.7/site-packages/scvi/__init__.py in <module>
      8
      9 # this import needs to come after prior imports to prevent circular import
---> 10 from . import data, model, external
     11
     12 # https://github.com/python-poetry/poetry/pull/2366#issuecomment-652418094

~/anaconda3/lib/python3.7/site-packages/scvi/model/__init__.py in <module>
----> 1 from ._autozi import AUTOZI
      2 from ._condscvi import CondSCVI
      3 from ._destvi import DestVI
      4 from ._linear_scvi import LinearSCVI
      5 from ._peakvi import PEAKVI

~/anaconda3/lib/python3.7/site-packages/scvi/model/_autozi.py in <module>
     10 from scvi import _CONSTANTS
     11 from scvi._compat import Literal
---> 12 from scvi.model.base import UnsupervisedTrainingMixin
     13 from scvi.module import AutoZIVAE
     14

~/anaconda3/lib/python3.7/site-packages/scvi/model/base/__init__.py in <module>
      2 from ._base_model import BaseModelClass
      3 from ._rnamixin import RNASeqMixin
----> 4 from ._training_mixin import UnsupervisedTrainingMixin
      5 from ._vaemixin import VAEMixin
      6

~/anaconda3/lib/python3.7/site-packages/scvi/model/base/_training_mixin.py in <module>
      4
      5 from scvi.dataloaders import DataSplitter
----> 6 from scvi.train import TrainingPlan, TrainRunner
      7
      8

~/anaconda3/lib/python3.7/site-packages/scvi/train/__init__.py in <module>
      1 from ._trainer import Trainer
----> 2 from ._trainingplans import (
      3     AdversarialTrainingPlan,
      4     ClassifierTrainingPlan,
      5     PyroTrainingPlan,

~/anaconda3/lib/python3.7/site-packages/scvi/train/_trainingplans.py in <module>
      9 from scvi import _CONSTANTS
     10 from scvi._compat import Literal
---> 11 from scvi.module import Classifier
     12 from scvi.module.base import BaseModuleClass, PyroBaseModuleClass
     13 from scvi.nn import one_hot

~/anaconda3/lib/python3.7/site-packages/scvi/module/__init__.py in <module>
      1 from ._autozivae import AutoZIVAE
      2 from ._classifier import Classifier
----> 3 from ._mrdeconv import MRDeconv
      4 from ._peakvae import PEAKVAE
      5 from ._scanvae import SCANVAE

~/anaconda3/lib/python3.7/site-packages/scvi/module/_mrdeconv.py in <module>
----> 1 from typing import OrderedDict
      2
      3 import numpy as np
      4 import torch
      5 from torch.distributions import Normal

ImportError: cannot import name 'OrderedDict' from 'typing' (/Users/ctl/anaconda3/lib/python3.7/typing.py)

Versions:

o.11.0

What version of Python do you have? It seems like this works since 3.7.2. If this is the issue we need to fix our reqs to address this.

I have Python 3.7.0. Let me try to upgrade and will report back.

I can confirm that upgrading to python 3.7.8 solved my issue.


Topology Error

I am following the KERAS application note on fine tuning, however I am getting a layer mismatch.
What is the best way to determine the difference in layers?
Thank you.
    model = InceptionV3(weights="imagenet",include_top=True)
File "lib\keras\applications\inception_v3_fixedpath.py", line 288, in InceptionV3
if weights == 'imagenet':
File "lib\keras\engine\topology.py", line 2708, in load_weights
self.load_weights_from_hdf5_group(f)
File "lib\keras\engine\topology.py", line 2760, in load_weights_from_hdf5_group
str(len(flattened_layers)) + ' layers.')
**ValueError: You are trying to load a weight file containing 190 layers into a model with 189 layers.**

The attachment layer listings (/model_weights part of the path removed for diff).
Retrain model has
dense_1...2 mixed1...10, globalaveragepoolding2d_1, and optimizer_weights
The original weights file does not have these
The original file has:
merge_1...15,predictions,flatten
(note merge_1 and merge_2 appear in both)
inception_retrained_model1_lyr.txt
inception_v3_weights_tf_dim_ordering_tf_kernels_lyr.txt
inception_v3_weights_tf_dim_ordering_tf_kernels_notop_lyr.txt
retrained_full.txt
retrain_notop.txt

train.py and inference.py
inference.txt
train.txt

Here are three model plots from keras visualize
original, original after new layers added and retrained

Results need to be reviewed. The following change allows the weights to load.
model.load_weights(weights_path,by_name=True)

This may be working, model.load_weights(weights_path,by_name=True)
The predictor in image_utils is not working with 2 classes, however, the predictions appear to working. Still interested what the extra layer is.


Handle nusmods ApiException and invalid academic year

An input like 1966-1967 or 2023-2024 follows the format correctly but the NUSMods API doesn't have mods for that AY. Same for an input like 2020-2022 which has the right format but isn't a valid AY.
Should we add something to the error dialog such as The academic year specified should be consecutive years e.g 2022-2023 and also Do note that the academic year may have the correct format but might be too far into the past or future. ?

Yes i'm currently doing that by adding it in the UG since it will be quite a long description. Will link it on the alert window


vue-cli-service build --target lib-async

What problem does this feature solve?
At the moment we can create libs and web-components. In the course of my current project the companies architecture has shifted from a giant app to wanting to manage each "module" of the application with a separate npm package. Within these packages one thing that will be exported is a router config that will then be registered within a new Vue Router instance on the main application. This works, until you try to lazy load a component into the router config. Webpack cannot resolve the chunks.
In the description of async web components you say " When targeting multiple web components, the bundle may become quite large, and the user may only use a few of the components your bundle registers. The async web component mode produces a code-split bundle with a small entry file that provides the shared runtime between all the components, and registers all the custom elements upfront. The actual implementation of a component is then fetched on-demand only when an instance of the corresponding custom element is used on the page: "
This feature would simply replicate this to a common / umd module
What does the proposed API look like?
vue-cli-service build --target lib-async --name

This works, until you try to lazy load a component into the router config. Webpack cannot resolve the chunks.

Why?

@LinusBorg my assumption would be because webpack is looking for the chunks in the wrong place, the chunks exist inside the node_modules/app2 folder and at a guess i'd say when the router tries to load it its looking in the /src folder for those elements. I've attached screenshots of the configurations.

There is more discussion and a workaround in this StackOverflow post and this webpack issue.

@epicyclist thats my stack overflow post :) but yes I may of found a few work arounds for it! thank you! :)

Aye, I was documenting it for myself and others since the workaround was not posted here. Did you find any other approaches or do those links cover everything?


update issue template

IMPORTANT: Please search among the Pull requests before creating one.
Description

How has this been tested?

Closes

Codecov Report

Merging #608 (b214c37) into main (9a0a0ef) will increase coverage by 0.20%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #608      +/-   ##
==========================================
+ Coverage   72.33%   72.54%   +0.20%
==========================================
  Files          37       36       -1
  Lines        5177     5056     -121
  Branches      982      914      -68
==========================================
- Hits         3745     3668      -77
+ Misses       1181     1145      -36
+ Partials      251      243       -8

Impacted Files
Coverage Δ

squidpy/im/_io.py
66.42% <0.00%> (-0.72%)
:arrow_down:

squidpy/_utils.py


Corrupt binary

Hi! Thanks for a great tool. There is a minor issue I'm facing. It happens very rarely, but just to let you know it exists. After I've made a change, elm-live says something like
CORRUPT BINARY - path/to/project/elm/elm-stuff/0.19.0/Pages-Protein-View.elmo

The binary data at
 path/to/project/elm/elm-stuff/0.19.0/Pages-Protein-View.elmo is
corrupt.

Then I just stop elm-live, start it again and everything is working fine.
I'm on

node v8.10.0
elm 0.19.0
Ubuntu 18.04.2 LTS
Visual Studio Code 1.32.3

Thank you for shooting this issue my way! Hopefully we can get this figured out. At least restarting fixes the issue, but hopefully I can find a fix so you do not have to do that :)

Question: Did you try deleting your elm-stuff folder and and re-installing?

I've just deleted it, so I'll report if the issue happens again

This could be a race condition with other script that compile elm, for example IDE plugins

Oh that is a good point.
On Sun, May 26, 2019 at 7:57 PM lucarakuten<EMAIL_ADDRESS>wrote:

This could be a race condition with other script that compile elm, for
example IDE plugins
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/wking-io/elm-live/issues/164?email_source=notifications&email_token=ACZ6MBBT7SIQ3Y6VRLHJYPDPXMWYJA5CNFSM4HC55GRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWIRB5Y#issuecomment-496046327,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACZ6MBB276EAIAC2LGLXGNLPXMWYJANCNFSM4HC55GRA
.

I did some testing using this snippet to monitor the elm-stuff folder:
const chokidar = require('chokidar');
chokidar.watch('elm-stuff', {ignored: /(^|[\/\\])\../}).on('all', (event, path) => {
  console.log(event, path);
});

Saving a file (I use Atom IDE) or compiling both result in:
change elm-stuff/0.19.0/Main.elmo
change elm-stuff/0.19.0/Main.elmi

when elm-live is running, I get something like:
change elm-stuff/0.19.0/Main.elmi
change elm-stuff/0.19.0/Main.elmi
change elm-stuff/0.19.0/Main.elmo
change elm-stuff/0.19.0/Main.elmi
change elm-stuff/0.19.0/Main.elmo

..I am actually surprised not to get some issue all the time

Well, I have not encountered this issue again. I guess I tried to use docker-compose for elm-live, and after facing the issue I gave it up. So maybe it should be closed?

Okay I will close for now, but let me know if it happens again!


different style of avoiding damaging merklise input data

in batch level 4 this approach costs a few more hundred gas
in batch level 10

before 470927
after    513051

abort for inefficient memory usage


Block temporary/burner email addresses

We rely on email for our authentication mechanism and to create a higher entry cost for users to avoid SPAM or DDOS. Burner email providers make that security weaker as they allow to easily create many addresses. Moreover, most of these addresses are shared and publicly accessible.
We got some entries in the database of users that tried to make orders with such emails in the past (they were actually the source of https://github.com/opencollective/opencollective/issues/2363).
By using something like https://github.com/findie/burner-email-providers on the API, we can easily detect and prevent users from using them by adding a validation in the model.
The error message thrown should be explicit:

This email provider is not allowed on Open Collective. If you think that it should be, please email us at<EMAIL_ADDRESS>

I am not sure, but I would like to dwell into api and understand the code base so I just attempted to solve the issue
Would Adding the following code at https://github.com/opencollective/opencollective-api/blob/93794dd43fd516b1e984546eeac5b914ff1b7058/server/graphql/v1/mutations.js#L257-L262 work?
 if(!isEmailBurner(args.user.email.toLowerCase())){
      throw new Error('This email provider is not allowed on Open Collective. If you think that it should be, please email us at support@opencollective.com.');
      }

Also does isEmailBurner('test@10minutemail.com'); work ? , it isn't returning true

It would work :slightly_smiling_face: But by doing that at the model level (https://github.com/opencollective/opencollective-api/blob/b03634849ed89230e4a93ac4e3b6811d8215a7f6/server/models/User.js#L48) ensures that no matter how a user is created/edited, we'll always check this field the same way.

It would work  But by doing that at the model level (https://github.com/opencollective/opencollective-api/blob/b03634849ed89230e4a93ac4e3b6811d8215a7f6/server/models/User.js#L48) ensures that no matter how a user is created/edited, we'll always check this field the same way.

I thought we are doing it for new users , since there could be some profile which are existing and may be flagged by burner , so to avoid that I thought we would just add a check at the time of creation of account :)


Disable text-searching

Is there any way I can disable the text-searching behavior?
I can hide the .angucomplete-searching using css but then I get an empty .angucomplete-dropdown box which is kinda ugly.
I want the dropdown to open only when the request has finished.

Probably the easiest is to provide your own template without the searching div.


chore: consume at_commons lowercase enforcement changes

- What I did
- How I did it
- How to verify it
- Description for the changelog

This PR will never be merged. has only been created to test integration with latest at_Commons in trunk


Issue with k8s.io/docs/tasks/access-application-cluster/ingress-minikube/

This is a Bug Report

Problem:
After 'Add the following line to the bottom of the /etc/hosts file.', there is a blue quote indication with no text.

This happens in more locations in this page. Is this supposed to be like that? Thanks :)
Proposed Solution: The notes like Note: If you are running Minikube locally, use minikube ip to get the external IP. The IP address displayed within the ingress list will be the internal IP. should be inside the blue quote indication, right? :)
Page to Update:
https://kubernetes.io/...

This is related to umbrella issue #20335
/kind bug
/priority backlog

Looks like this is fixed. At least no longer an issue with Chrome or Firefox. Pls feel free to reopen this if the problem persists.
/close


'config show' now outputs Logging info from appsettings.json

Note: I wasn't entirely sure about the scope of the issue based on what's written in #481, so if this is completely different than what was intended let me know. I essentially just latched onto the existing functionality for config show and added in Logging as one of the outputs. This is an example of the new output for config show

Closes #481

Note there's also a related issue (https://github.com/dotnet/dotnet-monitor/issues/412). There are likely other sections (such as Kestrel) that we may want to add here.


Any plan to suppport videos like Facebook?

Expected behavior

interactive present and dismiss with video.

Actual behavior

just work for image at this time.

just capture video frame as image then present it, after animation end, replace video into presenting image -> play


"target_arrow_shape" doesn't work.

After I write the following code, I found the code "target_arrow_shape("triangle-backcurve")" doesn't work.
The edge is still shown as the straight line and there is no arrow in the end of the edge.
Correct me if I write something wrong.
`GraphStyles gs =new GraphStyles();
GeneralGraphStyles ggs = new GeneralGraphStyles.Builder().target_arrow_shape("triangle-backcurve").target_arrow_color("red").target_endpoint("outside-to-line").arrow_scale("150").target_distance_from_node("20px").line_color("red").line_style("dashed").build();
gs.addStyle("edge", ggs);
	GeneralGraphStyles ggsNode = new GeneralGraphStyles.Builder().shape("round-rectangle").background_fit("contain").background_image("icon/play.png").build();
	gs.addStyle("node", ggsNode);
	cytoscape.loadStyle(gs.getJson(true));

	Edge edge = new Edge();
	edge.getData().put("source", "test");
	edge.getData().put("target", "test1");
	cytoscape.addEdge(edge);`

You need to change the curve style as explained here:
https://js.cytoscape.org/#style/edge-line
the default curve style only supports mid-arrows


ptex: 2.1.28 -> 2.1.33

Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/ptex/versions.
These checks were done:

built on NixOS
Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
directory tree listing: https://gist.github.com/88ea582c17048ee1efddf1b2e87ef3bc

cc @guibou for review

Success on x86_64-darwin (full log)
Attempted: ptex
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/ysv13j3r8w6ffgxkw5678anx1apil9v6-ptex-2.1.33-bin/bin
patching script interpreter paths in /nix/store/ysv13j3r8w6ffgxkw5678anx1apil9v6-ptex-2.1.33-bin
strip is /nix/store/0fzpxnsanc02i4jsb1yhchjp4p62b2n3-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/snrzcf6vzsmqkjhb8rghjs3pwv97wmk7-ptex-2.1.33-dev
strip is /nix/store/0fzpxnsanc02i4jsb1yhchjp4p62b2n3-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/ldlx05iy2isy4fnzflch5b3f3d80fpvh-ptex-2.1.33
strip is /nix/store/0fzpxnsanc02i4jsb1yhchjp4p62b2n3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/cnrpi912svx4wl82j05iqd3li0j2bs5y-ptex-2.1.33-lib/lib
patching script interpreter paths in /nix/store/cnrpi912svx4wl82j05iqd3li0j2bs5y-ptex-2.1.33-lib
/nix/store/ysv13j3r8w6ffgxkw5678anx1apil9v6-ptex-2.1.33-bin

Success on aarch64-linux (full log)
Attempted: ptex
Partial log (click to expand)
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
patching script interpreter paths in /nix/store/fa34lalnw3km8cxjvmaam2k47jlkqzvi-ptex-2.1.33
checking for references to /build in /nix/store/fa34lalnw3km8cxjvmaam2k47jlkqzvi-ptex-2.1.33...
shrinking RPATHs of ELF executables and libraries in /nix/store/shwm75y1gka2isga43fdpwwgym0rqawg-ptex-2.1.33-lib
shrinking /nix/store/shwm75y1gka2isga43fdpwwgym0rqawg-ptex-2.1.33-lib/lib/libPtex.so
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/shwm75y1gka2isga43fdpwwgym0rqawg-ptex-2.1.33-lib/lib
patching script interpreter paths in /nix/store/shwm75y1gka2isga43fdpwwgym0rqawg-ptex-2.1.33-lib
checking for references to /build in /nix/store/shwm75y1gka2isga43fdpwwgym0rqawg-ptex-2.1.33-lib...
/nix/store/z9fsnw5zzi520340sqk9v00nk2hpilll-ptex-2.1.33-bin


Update header search paths for React v0.19.0

@rjbaker I see that you've added $(SRCROOT)/../../React and recursive to the header search paths, but in an ideal scenario (such as the repo's folder structure), there will be no React folder two levels up from the source root directory. Was this fix specific to your project?

The paths are different in React 0.19. My project is based on the boilerplate created after running react-native init myProject.

I encountered the same thing in a new project yesterday and this fixed it. React's iOS paths have changed in the later versions. I'm merging this pull request. Thanks a lot! Really appreciate the help.

No worries. Thanks! :+1:


Fix Potential Use-After-Free of Temporary Twine

Twine is non-owning and the lifetime of the result ends at the semicolon
here unless it is consumed into an owning abstraction. Convert to
a std::string first then insert that into the buffer here.
Not a big deal since this is along a catastrophic error path.
Noticed by inspection after some internal discussion of Twine's ownership model.

@swift-ci smoke test

@swift-ci smoke test

@swift-ci smoke test macOS

⛵


sign in with google

Describe the bug
I am using the kreait/laravel-firebase: ^5.1 and kreait/firebase-php: ^7.0.
Trying to implement google authentication flow.
There is no method signInWithGoogleIdToken as described in https://firebase-php.readthedocs.io/en/latest/authentication.html?highlight=string#custom-authentication-flows.
If i use SignInWithIdpCredentials method i don't know which arguments to use for provider or accessToken.
Thank for help
Installed packages
{
    "name": "laravel/laravel",
    "type": "project",
    "description": "Instantia Data Laravel Project",
    "keywords": [
        "framework",
        "laravel"
    ],
    "license": "MIT",
    "require": {
        "php": "^8",
        "cviebrock/eloquent-sluggable": "^9.0",
        "doctrine/dbal": "^3.3",
        "guzzlehttp/guzzle": "^7.2",
        "intervention/image": "^2.7",
        "jorenvanhocht/laravel-share": "^4.2",
        "kreait/laravel-firebase": "^5.1",
        "lab404/laravel-impersonate": "^1.7",
        "laravel/framework": "^9.19",
        "laravel/passport": "^10.1",
        "laravel/tinker": "^2.7",
        "laravel/ui": "^3.4",
        "laravelcollective/html": "^6.3",
        "spatie/laravel-newsletter": "^4.11",
        "spatie/schema-org": "^3.11"
    },
    "require-dev": {
        "barryvdh/laravel-debugbar": "^3.5",
        "fakerphp/faker": "^1.9.1",
        "laravel/sail": "^1.0.1",
        "nunomaduro/collision": "^6.1",
        "spatie/laravel-ignition": "^1.2",
        "instantia/frontend": ">=1.0",
        "instantia/kruder": ">=1.0",
        "instantia/quality": ">=1.0",
        "instantia/tpladmin": ">=1.0",
        "mockery/mockery": "^1.4.4",
        "phpunit/phpunit": "^9.5.10",
        "spatie/laravel-ignition": "^1.0"
    },
    "config": {
        "optimize-autoloader": true,
        "preferred-install": "dist",
        "sort-packages": true
    },
    "extra": {
        "laravel": {
            "dont-discover": []
        }
    },
    "autoload": {
        "files": [
            "app/Helpers/helpers.php"
        ],
        "psr-4": {
            "App\\": "app/"
        },
        "classmap": [
            "database/seeds",
            "database/factories",
            "packages"
        ]
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    },
    "repositories": [],
    "minimum-stability": "dev",
    "prefer-stable": true,
    "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ],
        "post-update-cmd": [
            "@php -r \"file_exists('.env') || copy('.env.master', '.env');\""
        ]
    }
}

PHP version and extensions
composer               2.4.2    Composer package
composer-plugin-api    2.3.0    The Composer Plugin API
composer-runtime-api   2.2.2    The Composer Runtime API
ext-bcmath             8.1.2    The bcmath PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-bz2                8.1.2    The bz2 PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-calendar           8.1.2    The calendar PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-ctype              8.1.2    The ctype PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-curl               8.1.2    The curl PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-date               8.1.2    The date PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-dom                20031129 The dom PHP extension
ext-exif               8.1.2    The exif PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-ffi                8.1.2    The FFI PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-fileinfo           8.1.2    The fileinfo PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-filter             8.1.2    The filter PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-ftp                8.1.2    The ftp PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-gd                 8.1.2    The gd PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-gettext            8.1.2    The gettext PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-hash               8.1.2    The hash PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-iconv              8.1.2    The iconv PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-intl               8.1.2    The intl PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-json               8.1.2    The json PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-libxml             8.1.2    The libxml PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-mbstring           8.1.2    The mbstring PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-mysqli             8.1.2    The mysqli PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-mysqlnd            0        The mysqlnd PHP extension (actual version: mysqlnd 8.1.2-1ubuntu2.11)
ext-openssl            8.1.2    The openssl PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-pcntl              8.1.2    The pcntl PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-pcre               8.1.2    The pcre PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-pdo                8.1.2    The PDO PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-pdo_mysql          8.1.2    The pdo_mysql PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-pdo_sqlsrv         5.10.1   The pdo_sqlsrv PHP extension
ext-phar               8.1.2    The Phar PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-posix              8.1.2    The posix PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-readline           8.1.2    The readline PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-reflection         8.1.2    The Reflection PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-session            8.1.2    The session PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-shmop              8.1.2    The shmop PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-simplexml          8.1.2    The SimpleXML PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-sockets            8.1.2    The sockets PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-sodium             8.1.2    The sodium PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-spl                8.1.2    The SPL PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-sqlsrv             5.10.1   The sqlsrv PHP extension
ext-sysvmsg            8.1.2    The sysvmsg PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-sysvsem            8.1.2    The sysvsem PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-sysvshm            8.1.2    The sysvshm PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-tokenizer          8.1.2    The tokenizer PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-xml                8.1.2    The xml PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-xmlreader          8.1.2    The xmlreader PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-xmlwriter          8.1.2    The xmlwriter PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-xsl                8.1.2    The xsl PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-zend-opcache       8.1.2    The Zend OPcache PHP extension (actual version: 8.1.2-1ubuntu2.11)
ext-zip                1.19.5   The zip PHP extension
ext-zlib               8.1.2    The zlib PHP extension (actual version: 8.1.2-1ubuntu2.11)
lib-bz2                1.0.8    The bz2 library
lib-curl               7.81.0   The curl library
lib-curl-libssh        0.9.6    curl libssh version
lib-curl-openssl       3.0.2    curl OpenSSL version (3.0.2)
lib-curl-zlib          1.2.11   curl zlib version
lib-date-timelib       2021.11  date timelib version
lib-date-zoneinfo      0        zoneinfo ("Olson") database for date
lib-fileinfo-libmagic  540      fileinfo libmagic version
lib-gd                 2.3.0    The gd library
lib-iconv              2.35     The iconv library
lib-icu                70.1     The ICU unicode and globalization support library
lib-icu-cldr           40       ICU CLDR project version
lib-icu-unicode        14.0.0   ICU unicode version
lib-libsodium          1.0.18   The libsodium library
lib-libxml             2.9.13   libxml library version
lib-libxslt            1.1.34   The libxslt library
lib-libxslt-libxml     2.9.13   libxml version libxslt is compiled against
lib-mbstring-libmbfl   1.3.2    mbstring libmbfl version
lib-mbstring-oniguruma 6.9.7    mbstring oniguruma version
lib-openssl            3.0.2    OpenSSL 3.0.2 15 Mar 2022
lib-pcre               10.39    The pcre library
lib-pcre-unicode       14.0.0   PCRE Unicode version support
lib-zip-libzip         1.7.3    The zip-libzip library
lib-zlib               1.2.11   The zlib library
php                    8.1.2    The PHP interpreter
php-64bit              8.1.2    The PHP interpreter, 64bit
php-ipv6               8.1.2    The PHP interpreter, with IPv6 support

Steps to reproduce the issue.
# Insert the commands issued in the terminal if they are needed
# to reproduce the issue. Otherwise, delete this code block.

// Insert the PHP code to reproduce the issue. Please ensure that it is code that
// can be copy pasted to reproduce it.

Error message/Stack trace
Tinker output
PHP Error:  Call to undefined method Kreait\Firebase\Auth::signInWithGoogleIdToken() in /Services/TestServices.php on line 54

Additional information
No response

The documentation is outdated in that section, thank you for finding and reporting it, I will remove it as soon as I can get to it, I'm currently not at my computer.
$signInResult = $auth->signInWithIdpIdToken('google.com', $idToken, $redirectUrl, $linkingIdToken);

should work ($redirectUrl and $linkingIdToken are optional)

I am using the firebase web sdk configuration for google - the client id for idToken but:
Kreait\Firebase\Auth\SignIn\FailedToSignIn with message 'INVALID_IDP_RESPONSE : Unsuccessful check authorization response from Google: {
"error_description": "Invalid Value"
}

I looked a little bit into it and found https://firebase.google.com/docs/reference/rest/auth that a more detailed error description is INVALID_IDP_RESPONSE: The supplied auth credential is malformed or has expired. (you can find it on the page if you search for the error identifier).
I'm unsure what you pass to the PHP backend, but I hope this helps resolve the issue. This is nothing I can solve with the SDK, so I will close this issue - feel free to add further comments with your findings so that others might benefit from them.
In the meantime, I'm going to try to make the error messages returned in the exception more helpful by including the information from the page above.

The SDK already interprets the error and adds the clarifying information, so I'm not sure why it was not displayed to you 🤔


[JSDoc] Should we suppose ts-style for @prop (similar to @param)

// @ts-check
/**
 * @typedef {Object} Opts
 * @property {string} x
 * @property {string=} y
 * @property z {string=}
 *
 * @param {Opts} opts
 */
function foo(opts) {}

foo({x: 'abc'});

yup. you are right.

Does #16122 means it will type check ?

@cyrilletuzi  yep! So you can use both syntax interchangably


Operator should manage automatically upgrades of the discovery service

Right now the image used for the discovery service is specified by the user in the DiscoveryService resource with the field spec.image. This should be an optional field and the operator should automatically keep the version of the discovery service in sync with the version of the operator.

Solved with #59


Release Google.Cloud.BareMetalSolution.V2 version 1.4.0

Changes in this release:
No API surface changes; just dependency updates.

Created release for Google.Cloud.BareMetalSolution.V2-1.4.0


fix: init workspace list was wrong if set rootSearch

// should respect the value of rootSearch after that feature.

I think this makes sense, I have included the commit in #224 as to make merging easier.


upcoming events update

upcoming events page created

Good work. Though there is no preview.
But merge my pr before merging this one. 👍🏾

@winniekagz why did you force push?
and also, I am waiting for your review on my pull request. We should combine this, and start on the middleware for sending push notifications to Whatsapp.

@winniekagz we need to fix the conflicts, if it will be tricky, I can do it for you.

Fix conflict

lemmi work on it

Cool
Watch out you don't lose your code
On Thu, 30 Sep 2021, 23:57 winniekagz, @.***> wrote:

Fix conflict
lemmi work on it
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/tuk-scit/scit-fe-web-alerting-module/pull/10#issuecomment-931673283,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHQMLPNL4RVFOXTPWAIITFLUETFKDANCNFSM5EZC3YBQ
.


Git fileSystemProvider does not return an error when a file does not exist

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

Versions
Version : 1.86.0 (Universal)
Validation : 05047486b6df5eb8d44b2ecd70ea3bdf775fd937
Date : 2024-01-31T10:29:15.765Z
Electron : 27.2.3
ElectronBuildId : 26495564
Chromium : 118.0.5993.159
Node.js : 18.17.1
V8 : <IP_ADDRESS>-electron.0
Système d’exploitation : Darwin arm64 23.2.0

Steps to Reproduce:

stat will return a FileStat even if the file does not exist: https://github.com/microsoft/vscode/blob/559f5befe57875bff4e5bb4f2cf8b89aba19a820/extensions/git/src/fileSystemProvider.ts#L128-L145

readFile will return an empty Uint8Array if the file does not exist: https://github.com/microsoft/vscode/blob/559f5befe57875bff4e5bb4f2cf8b89aba19a820/extensions/git/src/fileSystemProvider.ts#L155-L192

The documentation is unclear about non existing file but VS Code has a FileSystemError.FileNotFound() error.
Is that expected? And if so, how can I check if a file exists or not when the Git fileSystemProvider is enabled. I thought about using the size property but I can't tell if it's an empty file or a non-existing file.
Maybe we should add an extra property to tell if the file exists in the working tree or not? Also, I do think that we should return a FileSystemError.FileNotFound() when trying to read a file that does not exist in the working tree.

Adding @joaomoreno to provide more context whether this is expected or not.

Fixed with https://github.com/microsoft/vscode/pull/236676


What to do with Recaptcha is already loaded?

When the Recaptcha is already loaded, the catch() is triggered. Why?
Why don't just skip the loading, and go straight to recaptcha.execute()?
Thanks.

Hey, this behavior is actually not intended, therefore I've implemented a fix.
Now it's possible to always get the recaptcha instance with the load function.


Uploader - error uploading very short file

Original report: https://rfcx.slack.com/archives/C03FD1WD02J/p1718123083670039

I was just trying to upload an audio file via the arbimon uploader and its come up with an error 'Validation errors: Parameter 'sample_count' should be an integer'. It is a 30minute clip from a longer .wav file that I cropped in R.
I (Carly) also tried to upload the file myself and got the same error

Example file https://rfcx.slack.com/archives/C03FD1WD02J/p1718123145781889?thread_ts=1718123083.670039&cid=C03FD1WD02J

Fix in https://github.com/rfcx/ingest-service/issues/81

it as expected that the last files is 0.000031 second and null sample count
it can split into 31 files same as ingest service

from
ffprobe -i out030.wav -show_entries stream=sample_count -show_entries format=duration -v quiet -of csv="p=0"

the result is

0.000031

the first line should be sample_count but it is empty so it means null

@koonchaya is this closed since this ticket is completed - https://github.com/rfcx/ingest-service/issues/81

This fix hasn't been deployed to production yet.


added unofficial_name to NL

fix for issue #491
"The Netherlands" doesn't match to NL country

Ooops I gave credit to #614 but you were first!  Thank you so much for this pr.  Closing in favor of #614.


deployer: health check can fail to detect failing startup

In #3776 I saw that the health check passed, but manually testing to launch a server failed. I assume the difference is that we check that the pod enters a running state or similar, but for the user server to successfully start - also JupyterHub needs to believe its successfully started, and that isn't something we check for currently.
Action points

Look into how our health check test work, does it consider JupyterHub's understanding about the server status?

Note that a server can be considered started, but not ready to be redirected to as well - what happens in this case is that the server is started by KubeSpawner - but JupyterHub never redirects the user because its not considering the user server ready yet.

I think this could have been due to a kubespawner bug fixed in kubespawner 7, available in z2jh 4, so I propose ignoring this and relying on getting z2jh 4 (see #5079 )


Use GitLab auth to render info

Hi,
I was wondering if there was a way to use the signed in users GitLab authentication to render the GitLab cards to limit what can be viewed and not leak commits or other information that the user wouldn't have visibility in GitLab.
Thanks

Hi @pleroux-bell, unfortunately, the feature you are looking for is not available at the moment.


disableOnClickOutside ES6/2015 class support

When using ES6 classes setting the property <Component disableOnClickOutside={true} />
Will overwrite the ability to use this.props.disableOnClickOutside(); within the component class.  A simple solution I'm using now is to rename the property.
        this.enableOnClickOutside();
}```

to

```if (!this.props.disabled) {
        this.enableOnClickOutside();
}```

closing due to the release of v5.0.0 - the functionality is now a pure HOC solution with props pass-through, and README.md documentation that clarifies how to use its new form.


how to link a static library?

I found it shows this as default: '-Dlibrary=shared_library', so I am wondering how could I use static library? I am in windows btw. Does it looks like > node-gyp rebuild --static

Can you be more specific?  Do you want to link to or link together a static library?  The former is not much different from linking to a shared library, just add it to the list of libraries to link in.

I need use libbitcoin as node addon, on Mac I am succeed to write the binding.gyp, maybe because it is a shared library, but on Windows, the author said some of the function is not finish yet, so there is only static library can be used on Windows. But I don't know how to make the binding.gyp right. Here is the binding.gyp file:

{
"targets": [
{
"target_name": "module1",
"sources": [
"module1.cpp"
],
"conditions": [
["OS=='mac'", {
"xcode_settings": {
"GCC_ENABLE_CPP_RTTI": "YES",
"GCC_ENABLE_CPP_EXCEPTIONS": "YES",
"OTHER_CFLAGS": [
"-std=c++11",
"-stdlib=libc++"
]
},
"include_dirs": [
"/usr/local/include"
],
"libraries": [
"/usr/local/lib/libbitcoin.dylib"
]
}],
["OS=='win'", {
"msvs_settings": {
"VCCLCompilerTool": {
'StringPooling': 'true', # pool string literals
'DebugInformationFormat': 3, # Generate a PDB
'WarningLevel': 3,
'BufferSecurityCheck': 'true',
'ExceptionHandling': 1, # /EHsc
'SuppressStartupBanner': 'true',
'WarnAsError': 'false',
}
},
"include_dirs": [
"../libbitcoin/include",
],
"libraries": [
"../libbitcoin/bin/x64/Release/CTP_Nov2013/staticlibbitcoin.lib"
]
}]
]
}
]
}

If I run node-gyp rebuild, then it said like this:
C:\code\libbitcoin\include\bitcoin/bitcoin/math/hash.hpp(25): fatal error C1083
: Cannot open include file: 'boost/functional/hash_fwd.hpp': No such file or di
rectory (..\module1.cpp) [C:\code\FrisbeeDog-CC\build\module1.vcxproj]

so I add boost dir into include section like this:

"include_dirs": [
"../libbitcoin/include",
"../libbitcoin/builds/msvc/vs2013/packages/boost.<IP_ADDRESS>/lib/native/include"
],

then it show other errors, like:
C:\code\libbitcoin\include\bitcoin/bitcoin/config/printer.hpp(52): error C2487:
'max_arguments' : member of dll interface class may not be declared with dll i
nterface (..\module1.cpp) [C:\code\FrisbeeDog-CC\build\module1.vcxproj]
C:\code\libbitcoin\builds\msvc\vs2013\packages\boost.<IP_ADDRESS>\lib\native\includ
e\boost/log/detail/config.hpp(30): fatal error C1189: #error :  Boost.Log: RTTI
is required by the library (..\module1.cpp) [C:\code\FrisbeeDog-CC\build\modul
e1.vcxproj]
Can you figure out how to make it right?

The RTTI thing probably means you need to set {'msvs_settings': 'VCCLCompilerTool': { 'RuntimeTypeInfo': 'true' } } in your binding.gyp.
The other one is an issue with the library, not node-gyp.  I'll close this out because I can't help you with that.


Save as svg

Hi,
Is it possible to export a styled dataframe to svg ? If not, is it possible to add the option in the future ?
Thank you.

I think it is not possible since current solution is just like... make a screenshot.


Subsequent source ~/.zshrc throws error

Prerequisites

[X] I've checked the existing issues and I'm not duplicating a report.
[X] I've checked the zimfw Changelog and I'm not being affected by documented changes.
[X] I've checked the zimfw 📢 Announcements and I'm not being affected by announced changes.

Bug description
Basically,
❯ source ~/.zshrc
warning: completion was already initialized before completion module. Will call compinit again. See https://github.com/zimfw/zimfw/wiki/Troubleshooting#completion-is-not-working
warning: compinit being called again after completion module at /home/sam/.zim/modules/completion/init.zsh:35

I followed the instructions at the link and concluded here:

If there's a "compinit being called at ..." message in the terminal, and it mentions Zim's "modules/completion/init.zsh" file, then you're good.

So, a fresh terminal session works fine without errors, but subsequent source ~/.zshrc throws the error. What's the intended way to reload your configuration without starting a new terminal session?
Steps to reproduce

cd ${$(mktemp -d):A} && \
    ZDOTDIR=${PWD} HOME=${PWD} ZIM_HOME=${PWD}/.zim && \
    curl -fsSL https://raw.githubusercontent.com/zimfw/install/master/install.zsh | zsh && \
    exec zsh

source $HOME/.zshrc

Current behavior
Current behavior throws an error like:
% source $HOME/.zshrc
warning: completion was already initialized before completion module. Will call compinit again. See https://github.com/zimfw/zimfw/wiki/Troubleshooting#completion-is-not-working
warning: compinit being called again after completion module at /tmp/tmp.ELzioLyKIS/.zim/modules/completion/init.zsh:35

Expected behavior
No errors.
zimfw info
zimfw version:        1.14.0 (built at 2024-06-25 17:29:35 UTC, previous commit is 3b7908d)
LANG:                 en_US.UTF-8
OSTYPE:               linux-gnu
TERM:                 xterm-kitty
TERM_PROGRAM:
TERM_PROGRAM_VERSION:
ZIM_HOME:             /tmp/tmp.ELzioLyKIS/.zim
ZSH_VERSION:          5.9

Additional context
No response

Hi @samtay

What's the intended way to reload your configuration without starting a new terminal session?

exec zsh

See https://unix.stackexchange.com/a/532591/85616

Huh, I've never encountered this issue until now, but the info in there all makes sense. Will close as my mistake. Thanks!


636 check for existing wallet

This PR is a fix for https://github.com/joinmarket-webui/jam/issues/636. When creating/importing a new wallet, the wallet name will now be validated immediately for duplicates, instead of on form submission when the user clicks "Create".
https://github.com/joinmarket-webui/jam/assets/25010707/6443dcfb-875e-4293-8b92-ae8125c9cd2c
An attempted fix was made using react router loaders, but this caused many redundant api calls to be made on component mount and session refresh. For now, this fix follows existing patterns, but utilizing a loader is something that could/should be investigated in future refactors.

Concept ACK


Publishing Artifact to Maven Central

It would be nice if restcli be available from maven as jvm library.
Then you would be able to run requests test directly from JUnit, such as:
class MyApiTest {

    @ParameterizedTest
    @CsvSource(value = [
        "1. simple tests.http",
        "2. complex tests.http"
    ])
    fun `should successfully execute test requests`(fileName: String) {
        // Given
        println("Test file: $fileName")
        val restCli = RestCli().apply {
            environmentName = "test"
            httpFilePaths = arrayOf(javaClass.getResource("/requests/${fileName}").path)
            environmentFilesDirectory = javaClass.getResource("/requests/").path
        }
        // When
        val exitCode = restCli.call()
        // Then
        assertThat(exitCode).isEqualTo(0)
    }
}

Yes, please! Our use case would be verification whether the requests still match the endpoints we implement 🙇


TLS 1.1+ Support in MupX

How do I get TLS 1.1+ support for MupX? I see it's not possible with MUP. We have a healthcare application that requires HIPPA compliance and we must use TLS 1.1+ according to the NIST 800 specs.

Here is a link about TLS on nginx.
http://askubuntu.com/questions/319192/how-to-enable-tls-1-2-in-nginx
Mupx which is the best current available version uses nginx so that would require customizing the configuration file used in the Mupx package (you'll probably have to make a PR and use it for yourself or wait a few months to see how the new version currently bring ported to karidahq).
The real problem with that idea is it loads docker images from elsewhere and even that route does not provide complete access so you'll find yourself running into similar problems you've already experienced.
https://github.com/arunoda/meteor-up/blob/mupx/templates/linux/start.sh#L58
You basically need to replace the front-end stuff.

Maybe Meteor's Galaxy is the right solution for you?

@MasterJames Does it mean that by default mupx currently only support TLS 1.0 only? From https://github.com/meteorhacks/mup-frontend-server/blob/master/lib/nginx.conf I can see the line sl_protocols TLSv1 TLSv1.1 TLSv1.2; though ?

@MasterJames when we get one of these to scale we will definitely be using Galaxy but if we can't get the first version out and meet the required HIPAA compliance we won't be able to :(

@codeHatcher For the old mup, maybe you can try to disable stud and than install bud-tls manually?

I think your right. It should work with mupx as you pointed to the TLS 1.2 ref. You also asked the right person in that other thread. I'm no expert at this just tring to help and learn.
If you deploy with mupx what is telling you its not supported?
Here is a way to check it.
http://serverfault.com/questions/638691/how-can-i-verify-if-tls-1-2-is-supported-on-a-remote-web-server-from-the-rhel-ce
(Or Google similar.)

Galaxy people will help you answer this question on their end if you ask the right person nicely. I'm sure you could try for 30 days (or maybe more if needed?) without the expense.


Regression: Apps can no longer be run/debugged from VSCode and Android Studio

Repro steps

Create a new app:flutter create repro
cd nulltest
flutter pub get

Open in VSCode or Android Studio
Hit F5 / start running or debugging

=>
When the exception was thrown, this was the stack
#2      WidgetInspectorService._registerServiceExtensionVarArgs.<anonymous closure>
package:flutter/…/widgets/widget_inspector.dart:894
#3      WidgetInspectorService._registerServiceExtensionVarArgs.<anonymous closure>
package:flutter/…/widgets/widget_inspector.dart:882
#4      BindingBase.registerServiceExtension.<anonymous closure>
package:flutter/…/foundation/binding.dart:546
<asynchronous suspension>
(elided 2 frames from class _AssertionError)
════════════════════════════════════════════════════════════════════════════════
Error handling 'serviceExtension' custom request: ext.flutter.inspector.setPubRootDirectories: (-32000) Server error
{"exception":"'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 894 pos 16: 'index == parameters.length': is not true.","stack":"#0      _AssertionError._doThrowNew (dart:core-patch/errors_patch.dart:46:39)\n#1      _AssertionError._throwNew (dart:core-patch/errors_patch.dart:36:5)\n#2      WidgetInspectorService._registerServiceExtensionVarArgs.<anonymous closure> (package:flutter/src/widgets/widget_inspector.dart:894:16)\n#3      WidgetInspectorService._registerServiceExtensionVarArgs.<anonymous closure> (package:flutter/src/widgets/widget_inspector.dart:882:17)\n#4      BindingBase.registerServiceExtension.<anonymous closure> (package:flutter/src/foundation/binding.dart:546:32)\n<asynchronous suspension>\n","method":"ext.flutter.inspector.setPubRootDirectories"}

This is potentially a regression introduced as part of resolving https://github.com/flutter/flutter/issues/68627, cc @jacob314 @goderbauer ?

I'm seeing lots of waring after upgrade master channel as well.
In my specific case I'm able to debug/run my projects without problem but the message keeps showing every time I do Hot-Reload or run my project for the first time.
Note: I don't have NNBD enabled on the projects I'm running!

Logs
Performing hot restart...
Syncing files to device iPhone 11 Pro Max...
Restarted application in 444ms.

════════ Exception caught by Flutter framework ═════════════════════════════════════════════════════
'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 894 pos 16: 'index == parameters.length': is not true.
════════════════════════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by Flutter framework ═════════════════════════════════════════════════════
'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 894 pos 16: 'index == parameters.length': is not true.
════════════════════════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by Flutter framework ═════════════════════════════════════════════════════
'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 894 pos 16: 'index == parameters.length': is not true.
════════════════════════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by Flutter framework ═════════════════════════════════════════════════════
'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 894 pos 16: 'index == parameters.length': is not true.
════════════════════════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by Flutter framework ═════════════════════════════════════════════════════
'package:flutter/src/widgets/widget_inspector.dart': Failed assertion: line 894 pos 16: 'index == parameters.length': is not true.
════════════════════════════════════════════════════════════════════════════════════════════════════

From my comment in the other issue - I tweaked it to print the arguments out and got this:
flutter: Exception: Index: 1, Params: {arg0: file:///Users/danny/Dev/TestStuff/foo, isolateId:
flutter: isolates/1397158588675607}

It seems like the code assumes that the number of arguments exactly matches the argX count, but there's also an isolateId in there.
I don't know whether the isolateId is intended to be passed here, but VS Code is definitely passing it:
params: {
	arg0: this.formatPathForPubRootDirectories(e.session.configuration.cwd),
	arg1: e.session.configuration.cwd,
	isolateId: e.body.isolateId,
},

If it shouldn't be there, VS Code is probably doing the wrong thing. If it is supposed to be there, I think the assert is incorrect.

I think the assertion is right. What may be wrong is the break block, the while loop is being broken before the index is incremented and this causes disparity between the amount of parameters iterated and the amount of index iterated.
https://github.com/flutter/flutter/blob/a4ac7cce827cce7fe8d11166d3ad3f20f6262f60/packages/flutter/lib/src/widgets/widget_inspector.dart#L882-L893

vscode shouldn't be passing an isolateId but we can ignore that field.

@jacob314 if it's not required, I can remove it - though DevTools is doing the same so I wonder if it might be needed?
https://github.com/flutter/devtools/blob/59e338106eae195718385840a3149f6287e0c354/packages/devtools_app/lib/src/inspector/inspector_service.dart#L389


Maf88/172 add contributing.rst file

I left 2 #TODO because I wasn't sure what to put there. It's for the tests and for a good example of PR.

Please leave explanation whenever closing unmerged PR (good habit to show students)

I didn't rebase correctly the branch 172 and one of my other branch was pushed too. This should be a one commit branch. Therefore I closed it and recreated a new branch with the right commit.


Tidy up

Pull Request Test Coverage Report for Build 13

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 60.702%

Totals

Change from base Build 12:
0.0%

Covered Lines:
899

Relevant Lines:
1481

💛  - Coveralls


docs: 📝 fix link for --preset option

@tuffz Thank you!

I have to thank you for this outstanding piece of software.