Authentication using phone number only

Is your feature request related to a problem? Please describe.
Yes - when I tried using Amplify for authenticating users using a phone number and TOTP, I ran into some issues.
Describe the solution you'd like
I'd like there to be another "alternative sign in" option, where you can sign up/sign in using your phone number only (and TOTP for verification on both registration and login).
Describe alternatives you've considered
You could use the hash of the phone number as the username, the phone number as the password, and enable MFA. However, that would be extremely hack-y, and so I'd prefer not to use it.
Additional context
aws-amplify/aws-sdk-android#1012 (and more specifically https://github.com/aws-amplify/aws-sdk-android/issues/1012#issuecomment-505580288).
// cc @undefobj

@itaisteinherz thanks for the feature request I take this to the team and get back to you with the result of our discussion.

any updates?

@attilah any update on this issue. I am facing the same problem.

@attilah any update ?

I am facing the same issue
`// snippet
const signUpObj = {
“ClientId”: “myClientId”,
“Username”: “+12027953213”,
“Password”: “1595375749602”,
“UserAttributes”: [],
“ValidationData”: null
};
try {
const result: SignUpResult = await Auth.signUp(signUpObj);
resolve(result);
} catch(error) {
console.log(error)
}
// end of snippet
// result:
/*
{
“__type”: “InvalidParameterException”,
“message”: “Attributes did not conform to the schema: email: The attribute is required\n”
}*/`

I have temporary solution for this issue so that I can just move on, but we need to have phone only signup feature for this, thank you.
      const email =<EMAIL_ADDRESS>
      const signUpObj = {
        username,
        password: Date.now().toString(),
        attributes: {
          email,
        }
      };

      const signUp = this._auth.signUp(signUpObj);
// work on results below

@itaisteinherz thanks for the feature request I take this to the team and get back to you with the result of our discussion.

Any updates on this feature request ?

I fully agree that this is a very relevant feature request!

cc @palpatim @elorzafe for visibility

This feature still stands as with the current "phone number" login mechanism still requires an associated email and password (using Amplify CLI 7.6.24), whereas this is requesting "phone number" login with SMS TOTP

Wow, nothing since 2022


chore: bdd-spring-1572564363 to 0.0.1

chore: Promote bdd-spring-1572564363 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


added the upload json functionality

As suggested I have integrated the upload_json functionality to allow pushing our CFN-Sphere YML templates to be available as CloudFormation templates at S3. Please check...

+1
only two suggestions:

instead of naming the task and implementing class "upload JSON to S3" I would rather use "upload CloudFormation template to S3", I think this is the important part of the message.
for the unit test you could use more minimalistic templates as we do not need to test cfn-sphere in this project

Comments acknowledged. Regarding templates: I wanted to keep it as simple as possible and copied them just from another project.


Create for Technisch Atheneum Keerbergen

Create for Technisch Atheneum Keerbergen
@technischatheneumkeerbergen.be

@TakJGE First stage of verification passed, official domain is technischatheneumkeerbergen.be as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@TakJGE Thank you for your patience while waiting for a review and processing your request. Pull request merged.

Dear Philip
Thank you very much! Have a nice weekend!
Kind regards
Joris Geens
Teacher TAK (Technisch Atheneum Keerbergen – Belgium)
Enthusiastic teacher ICW
http://www.technischatheneumkeerbergen.be/ www.technischatheneumkeerbergen.be
Van: Philip Torchinsky @.>
Verzonden: vrijdag 12 januari 2024 8:31
Aan: JetBrains/swot @.>
CC: TakJGE @.>; Mention @.>
Onderwerp: Re: [JetBrains/swot] Create for Technisch Atheneum Keerbergen (PR #19720)
https://github.com/TakJGE @TakJGE Thank you for your patience while waiting for a review and processing your request. Pull request merged.
—
Reply to this email directly,  https://github.com/JetBrains/swot/pull/19720#issuecomment-1888564957 view it on GitHub, or  https://github.com/notifications/unsubscribe-auth/BE4VZYB5JGOMN7BXD5OXEUDYODRC7AVCNFSM6AAAAABBL3XFMWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBYGU3DIOJVG4 unsubscribe.
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/BE4VZYHDCKBSXTYR6S7QTCDYODRC7A5CNFSM6AAAAABBL3XFMWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTQSE3N2.gif Message ID: < @.> @.>


Remove old PMs and instead say “Coming Soon” or “TBD”

While we wait for PM applicants, remove current showcase of last years PMs and show "Coming Soon" (or similar). Once we finalize PMs by end of August this can be updated with PM information.


bridge and masqurade networking doesn't work, but slirp does

/kind bug
What happened:
Starting a VM with an interface in either bridge or masquerade mode gives a broken network where the default gateway is <IP_ADDRESS> and the VM is unable to ping it or connect to anything on the network.
If I use slirp, then networking seems to work correctly.
The VM has worked perfectly a long time on kubevirt v0.35.0 / kubernetes v1.16.3 / ubuntu 18.04 with network mode bridge.
What you expected to happen:
I would expect both bridge and masquerade to work.
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):
Client Version: version.Info{GitVersion:"v0.47.1", GitCommit:"c34de42a48f5564f4fd2c21b6cbda7b96664c65b", GitTreeState:"clean", BuildDate:"2021-11-11T16:01:45Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"v0.47.1-dirty", GitCommit:"c34de42a48f5564f4fd2c21b6cbda7b96664c65b", GitTreeState:"dirty", BuildDate:"2021-11-11T16:20:45Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:10:43Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5", GitCommit:"aea7bbadd2fc0cd689de94a54e5b7b758869d691", GitTreeState:"clean", BuildDate:"2021-09-15T21:04:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

VM or VMI specifications:

This VM doesn't work, the only difference between this and one that works is that bridge is replaced with slirp
`
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
annotations:
kubevirt.io/latest-observed-api-version: v1
kubevirt.io/storage-observed-api-version: v1alpha3
generation: 1
labels:
app.kubernetes.io/instance: golden-virtual-machines
managedFields:

apiVersion: kubevirt.io/v1alpha3
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
f:kubectl.kubernetes.io/last-applied-configuration: {}
f:labels:
.: {}
f:app.kubernetes.io/instance: {}
f:spec:
.: {}
f:running: {}
f:template:
.: {}
f:metadata:
.: {}
f:annotations: {}
f:labels: {}
f:spec:
.: {}
f:domain:
.: {}
f:cpu:
.: {}
f:cores: {}
f:devices:
.: {}
f:disks: {}
f:interfaces: {}
f:machine:
.: {}
f:type: {}
f:memory:
.: {}
f:guest: {}
f:resources:
.: {}
f:requests:
.: {}
f:memory: {}
f:networks: {}
f:nodeSelector:
.: {}
f:kubernetes.io/hostname: {}
f:volumes: {}
manager: argocd-application-controller
operation: Update
time: "2021-11-19T12:01:10Z"

apiVersion: kubevirt.io/v1alpha3
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
f:kubevirt.io/latest-observed-api-version: {}
f:kubevirt.io/storage-observed-api-version: {}
f:status:
.: {}
f:conditions: {}
f:created: {}
f:printableStatus: {}
f:ready: {}
f:volumeSnapshotStatuses: {}
manager: Go-http-client
operation: Update
time: "2021-11-19T12:01:34Z"
name: win10
namespace: golden-virtual-machines
resourceVersion: "21294670"
uid: 093633db-59dc-4c1a-8055-21e7b8538999
spec:
running: true
template:
metadata:
annotations:
debugLogs: "true"
creationTimestamp: null
labels:
debugLogs: "true"
vmName: win10
spec:
domain:
cpu:
cores: 2
devices:
disks:
- disk:
bus: virtio
name: boot
- disk:
bus: virtio
name: service
- disk:
bus: virtio
name: tools
- cdrom:
bus: sata
name: secret-volume
interfaces:
- bridge: {}
macAddress: 02:05:11:b0:42:42
name: default
ports:
- port: 22
- port: 80
- port: 443
- port: 3389
- port: 3400
machine:
type: q35
memory:
guest: 8Gi
resources:
requests:
memory: 8Gi
networks:

name: default
pod: {}
nodeSelector:
kubernetes.io/hostname: glengrant
volumes:
name: boot
persistentVolumeClaim:
claimName: win10
containerDisk:
image: registry.stibo.dk/rm/public/kubevirt/build-agent-service:11e66bd66fe017989f4f46bacbfe924fdf2ac6c8
name: service
containerDisk:
image: registry.stibo.dk/containers/public/windows-vm-tools-container:2a4b5912eec127f9ee910fd4c532bfa7e30feb5b
name: tools
name: secret-volume
secret:
secretName: service-mode
status:
conditions:

lastProbeTime: null
lastTransitionTime: "2021-11-19T12:01:31Z"
status: "True"
type: Ready

lastProbeTime: null
lastTransitionTime: null
message: 'cannot migrate VMI: PVC win10 is not shared, live migration requires
that all PVCs must be shared (using ReadWriteMany access mode)'
reason: DisksNotLiveMigratable
status: "False"
type: LiveMigratable
created: true
printableStatus: Running
ready: true
volumeSnapshotStatuses:

enabled: false
name: boot
reason: 'No VolumeSnapshotClass: Volume snapshots are not configured for this
StorageClass [cephfs] [boot]'

enabled: false
name: service
reason: Snapshot is not supported for this volumeSource type [service]

enabled: false
name: tools
reason: Snapshot is not supported for this volumeSource type [tools]

enabled: false
name: secret-volume
reason: Snapshot is not supported for this volumeSource type [secret-volume]
`

Cloud provider or hardware configuration:

Bare metal RKE v1.3.1 cluster with metallb in BGP mode.
The hosts are connected with ipoib (Infiniband).

OS (e.g. from /etc/os-release):

Ubuntu 20.04.3 LTS

Kernel (e.g. uname -a):

Linux glengrant 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

I have since upgraded kubevirt on the old cluster and bridge works ok there, so that means that the working setup is:

Kubevirt v0.35.0 and v0.47.1
Kubernetes v1.16.3
Docker 20.10.7
Ubuntu 18.04
Linux 4.15.0-128-generic
Metallb in layer 2 mode

The setup where bridge and masqurade is broken is:

Kubevirt v0.47.1
Kubernetes v1.21.5
Docker 20.10.10
Ubuntu 20.04
Linux 5.4.0-89-generic
Metallb in BGP mode

@dren-dk I see that you updated ubuntu there. Could it be related to app-amor? Just a first guess.

/assign @maiqueb
thanks for following up here.

The new cluster does have apparmor running, but so did the old one:

sudo cat /sys/kernel/security/apparmor/profiles
docker-default (enforce)
/usr/sbin/ntpd (enforce)
/usr/sbin/tcpdump (enforce)
/{,usr/}sbin/dhclient (enforce)
/usr/lib/connman/scripts/dhclient-script (enforce)
/usr/lib/NetworkManager/nm-dhcp-helper (enforce)
/usr/lib/NetworkManager/nm-dhcp-client.action (enforce)
lsb_release (enforce)
man_groff (enforce)
man_filter (enforce)
/usr/bin/man (enforce)
nvidia_modprobe (enforce)
nvidia_modprobe//kmod (enforce)
/usr/sbin/haveged (enforce)

I've seen some references to the "/usr/libexec/qemu-kvm PUx," magic line to put in /etc/apparmor.d/usr.sbin.libvirtd, like:
https://github.com/kubevirt/kubevirt/issues/4303 but that issue seems to indicate that qemu cannot start at all.

I looked at the dmesg to see if apparmor metioned anything about it messing things up, but this is all that happens:
[Thu Nov 25 12:31:53 2021] eth0-nic: renamed from eth0
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 1(eth0-nic) entered blocking state
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 1(eth0-nic) entered disabled state
[Thu Nov 25 12:31:53 2021] device eth0-nic entered promiscuous mode
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 2(tap0) entered blocking state
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 2(tap0) entered disabled state
[Thu Nov 25 12:31:53 2021] device tap0 entered promiscuous mode
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 2(tap0) entered blocking state
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 2(tap0) entered forwarding state
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 1(eth0-nic) entered blocking state
[Thu Nov 25 12:31:53 2021] k6t-eth0: port 1(eth0-nic) entered forwarding state

We uninstall snap and that left a dangling references in /etc/apparmor.d/usr.lib.snapd.snap-confine.real which caused
apparmor to not start, removing it and restarting apparmor didn't do anything, though.
I noticed that /etc/apparmor.d/usr.sbin.libvirtd didn't exist, so I lifted one from another system with libvirt-daemon-system installed, but restarting apparmor didn't do anything.

Hello I noticed a similar issue (for masquerade) but was not able to clearly troubleshoot it with default delivery.
I noticed that :
the ip route is not as expected
default via <IP_ADDRESS> dev eth0  <IP_ADDRESS>/24 dev k6t-eth0 proto kernel scope link src <IP_ADDRESS>  <IP_ADDRESS> dev eth0 scope link
the ip a command returns
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00     inet <IP_ADDRESS>/8 scope host lo        valid_lft forever preferred_lft forever 3: eth0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default      link/ether e6:2a:d2:c0:94:f2 brd ff:ff:ff:ff:ff:ff link-netnsid 0     inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global eth0        valid_lft forever preferred_lft forever 4: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default      link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff     inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global k6t-eth0        valid_lft forever preferred_lft forever 5: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast master k6t-eth0 state UP group default qlen 1000     link/ether 7e:c4:78:ec:94:8f brd ff:ff:ff:ff:ff:ff
and as the ip route does not seem right I checked (nftables/iptables rules)
nft list ruleset is empty
and
bash-4.4# whoami root bash-4.4# iptables -S iptables v1.8.4 (nf_tables): Could not fetch rule set generation id: Permission denied (you must be root)
Which means that even the root account can't access to potables/nftables (I'm not sure this is an expected behavior).
I can't understand how the network could work.
I also noticed that on virt-handler,
calling the vm itself <IP_ADDRESS> is responding
calling the vm through the pod ip is not responding.
I hope It could help solving this issue (I'm testing Kubevirt 0.51.0)

Hello I noticed a similar issue (for masquerade) but was not able to clearly troubleshoot it with default delivery.
I noticed that : the ip route is not as expected default via <IP_ADDRESS> dev eth0 <IP_ADDRESS>/24 dev k6t-eth0 proto kernel scope link src <IP_ADDRESS> <IP_ADDRESS> dev eth0 scope link the ip a command returns 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet <IP_ADDRESS>/8 scope host lo valid_lft forever preferred_lft forever 3: eth0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether e6:2a:d2:c0:94:f2 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global eth0 valid_lft forever preferred_lft forever 4: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global k6t-eth0 valid_lft forever preferred_lft forever 5: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast master k6t-eth0 state UP group default qlen 1000 link/ether 7e:c4:78:ec:94:8f brd ff:ff:ff:ff:ff:ff
and as the ip route does not seem right I checked (nftables/iptables rules) nft list ruleset is empty
and bash-4.4# whoami root bash-4.4# iptables -S iptables v1.8.4 (nf_tables): Could not fetch rule set generation id: Permission denied (you must be root) Which means that even the root account can't access to potables/nftables (I'm not sure this is an expected behavior).

I assume this is happening on the virt-launcher pod; that is expected: virt-launchers miss the NET_ADMIN capability, and as such, cannot perform these operations. That is a security feature.
If you want to access the netfilter rules, you have to access them via the corresponding virt-handler - which does have the required permissions. You first need to find the PID of the virt-launcher you want to debug, and then tap into its network namespace via nsenter:
nsenter -t <virt launcher PID> -n iptables -S

I am unsure if netfilter rules were configured via iptables / nftables. Try both :)

I can't understand how the network could work.

You can find detailed information about how masquerade works in https://github.com/kubevirt/kubevirt/blob/main/docs/devel/networking.md#masquerade-binding-mechanism
It is probably a bit out-dated, and does not account for istio service mesh, but it is still accurate when it comes to the overall traffic flow. Especially interesting is the following sentence regarding the default route:
All outbound traffic from the VM can reach the outside world via the in-pod bridge.
The packet will be routed via the default route - default via <IP_ADDRESS> dev eth0 - and
before leaving the interface, its source address will be masqueraded to the IP address
of the pod, via the masquerade target.

I also noticed that on virt-handler, calling the vm itself <IP_ADDRESS> is responding calling the vm through the pod ip is not responding.
I hope It could help solving this issue (I'm testing Kubevirt 0.51.0)

Thank you for your comment (and yes I was looking in virt-launcher pod), I'll check the documentation you pointed.
But I noticed this in the referenced documentation which is contrary to your comment (out of dated documentation ?).

Thank you for your comment (and yes I was looking in virt-launcher pod), I'll check the documentation you pointed.
But I noticed this in the referenced documentation which is contrary to your comment (out of dated documentation ?).

That is outdated - and as such, is no longer true. For more details check out the implementation of the pod templates, in this link.
I've pushed PR #7431 to update the docs with the correct capability list.

Thank you for the document update
I tried to run command in the namespace but the nft or iptables always return an empty set whereas I expect forwarding rule :|
The inbound communication seems blocked whereas the outgoing is ok.
I'm using a simple sample
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
  namespace: default
spec:
  running: true
  template:
    spec:
      domain:
        devices:
          disks:
            - disk:
                bus: virtio
              name: containerdisk
            - disk:
                bus: virtio
              name: cloudinitdisk
          interfaces:
            - masquerade: {}
              name: default
        machine:
          type: q35
        resources:
          requests:
            memory: 64M
      networks:
        - name: default
          pod: {}
      volumes:
        - containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
          name: containerdisk
        - cloudInitNoCloud:
            userDataBase64: SGkuXG4=
          name: cloudinitdisk

nsenter -t 15907 nft list ruleset or nsenter -t 15907 iptables -L returns no specific rules (no Kubevirt ones)

The commands you've listed about are missing -n, which indicates you want to enter the network namespace. Without that, it won't work @sushiMix .
Can you confirm you're actually tapping into the network namespace of the pod ?
Would you paste the output of:
nsenter -t <launcher-pid> -n ip a
nsenter -t <launcher-pid> -n ip r
nsenter -t <launcher-pid> -n iptables -L
nsenter -t <launcher-pid> -n nft list chains ip

Hello sorry for the missing "-n" I don't usually manipulate the namespaces.
bash-4.4# nsenter -t 22646 -n ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
3: eth0@if27: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether 92:6d:ae:e9:6d:14 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
4: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default
    link/ether 02:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global k6t-eth0
       valid_lft forever preferred_lft forever
5: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast master k6t-eth0 state UP group default qlen 1000
    link/ether 9a:da:e4:cf:fd:cf brd ff:ff:ff:ff:ff:ff

default via <IP_ADDRESS> dev eth0
<IP_ADDRESS>/24 dev k6t-eth0 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS> dev eth0 scope link

nsenter -t 22646 -n iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

bash-4.4# nsenter -t 22646 -n nft list chains ip
table ip nat {
        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
        }
        chain input {
                type nat hook input priority 100; policy accept;
        }
        chain output {
                type nat hook output priority -100; policy accept;
        }
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
        }
        chain KUBEVIRT_PREINBOUND {
        }
        chain KUBEVIRT_POSTINBOUND {
        }
}
table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
        }
        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }
}

but for nft I prefer
nsenter -t 22646 -n nft list ruleset
table ip nat {
        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                iifname "eth0" counter packets 0 bytes 0 jump KUBEVIRT_PREINBOUND
        }

        chain input {
                type nat hook input priority 100; policy accept;
        }

        chain output {
                type nat hook output priority -100; policy accept;
                ip daddr { <IP_ADDRESS> } counter packets 0 bytes 0 dnat to <IP_ADDRESS>
        }

        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr <IP_ADDRESS> counter packets 3 bytes 202 masquerade
                oifname "k6t-eth0" counter packets 1 bytes 404 jump KUBEVIRT_POSTINBOUND
        }

        chain KUBEVIRT_PREINBOUND {
                counter packets 0 bytes 0 dnat to <IP_ADDRESS>
        }

        chain KUBEVIRT_POSTINBOUND {
                ip saddr { <IP_ADDRESS> } counter packets 0 bytes 0 snat to <IP_ADDRESS>
        }
}
table ip filter {
        chain INPUT {
                type filter hook input priority filter; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority filter; policy accept;
        }

        chain OUTPUT {
                type filter hook output priority filter; policy accept;
        }
}

thanks for helping me.

I think the rules look correct ... @rhrazdil could you take a quick look at the nftables rules listed in the bottom of this comment ?
I find extremely strange that the pre routing rules was never hit:
iifname "eth0" counter packets 0 bytes 0 jump KUBEVIRT_PREINBOUND
That means traffic never hit the pod. @sushiMix, when you say "The inbound communication seems blocked whereas the outgoing is ok." from where are you trying to access the VM ?...

Indeed, according to the routing rules, the inbound traffic never reached the pod.
For outbound traffic, we can see several connections in postrouting chain:
ip saddr <IP_ADDRESS> counter packets 3 bytes 202 masquerade.

If you try it from within the virt-launcher pod, you should use the VM's static IP - which for masquerade is <IP_ADDRESS>.

I agree this test was fully functional but tried after the "public" pod ip.
For the counters I don't remember If I did all the tests before outputting the notable rules.

If you try it from within the virt-launcher pod, you should use the VM's static IP - which for masquerade is <IP_ADDRESS>.

I agree this test was fully functional but tried after the "public" pod ip.
For the counters I don't remember If I did all the tests before outputting the nft rules.

Please double check this :) It's important.
One more question: could it be that when you're reaching a random pod from a node, said random pod is running on that node ? And when you're trying to reach a VM from a node the VM is scheduled on a different node ?
If so, would you try to reach out the VM from the node where it is running on ?
My point is that according to the Kubernetes network model :

agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

I interpret this as not all CNIs will be able to reach pods on different nodes. Which reminds me to ask you: what is the default cluster network CNI plugin you are using ?

Hello,
I'm using the calico CNI and tried from the host running the VM as I'm testing on a single node.
For the counters I can restart the vm and perform specific test (I don't know how to reset anonymous counters)

Hello,
I'm using the calico CNI and tried from the host running the VM as I'm testing on a single node.

That destroys my half-baked theory ... Thanks for the reply.

I finally found my issue (between chair and keyboard :|).
I do my test in a vm (VirtualBox) which runs the kubernetes node. I forgot that my VM had two network interfaces and one was using NAT. I noticed that one of the ip of my VirtualBox VM collides with the IP of the VM (which obviously breaks the routing mechanism).
I fixed it by setting
pod:
  vmNetworkCIDR: <IP_ADDRESS>/24

I have finally had a moment to grow angry enough about this problem to dig into it, here's what I have found:

I installed a ubuntu server VM with slirp and checked that it works.
I changed the VM to use bridging and checked that it failed as usual.
I upgraded from kubevirt v0.48.0 to v0.58.0, just be sure that I would be chasing any fixed bugs.

Any regular (non-kubevirt) pod has the pod address set like this, with a subnet mask of /32:
3: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether 9e:72:5a:bf:3e:4b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever

Looking at the routes set up for the pod we get:
# ip route
default via <IP_ADDRESS> dev eth0
<IP_ADDRESS> dev eth0 scope link

iow: There's a completely unrelated ip address that's explicitly reachable via the pod interface which is used as the default gw.
In the following I'm booting a plain ubuntu server VM, which is set up with DHCP that works as expected when using slirp, but it fails when using bridged networking.
I have been digging into the bridge configuration of the virt-launcher pod and I see that it does set up the bridge as expected:
brctl  show
bridge name     bridge id               STP enabled     interfaces
k6t-eth0                8000.0a9cfb35f8dc       no              eth0-nic
                                                                                tap0

The default interface is down and the bridge (k6t-eth0) is up:
bash-4.4# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip <IP_ADDRESS> brd <IP_ADDRESS>
4: eth0-nic@if29502: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue master k6t-eth0 state UP group default
    link/ether 22:49:b6:dc:a5:3c brd ff:ff:ff:ff:ff:ff link-netnsid 0
5: eth0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether 6e:77:d8:bb:c8:89 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
6: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether 0a:9c:fb:35:f8:dc brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/32 scope global k6t-eth0
       valid_lft forever preferred_lft forever
7: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc fq_codel master k6t-eth0 state UP group default qlen 1000
    link/ether 0a:9c:fb:35:f8:dc brd ff:ff:ff:ff:ff:ff

The VM is configured to use the tap0 interface according to both the command line and the libvirt domain xml:
                <interface type="ethernet">
                        <source></source>
                        <target dev="tap0" managed="no"></target>
                        <model type="virtio-non-transitional"></model>
                        <mac address="02:05:11:b0:42:42"></mac>
                        <mtu size="1440"></mtu>
                        <alias name="ua-default"></alias>
                        <rom enabled="no"></rom>
                </interface>

So it would seem the network has been configured perfectly and that can be confirmed by manually assigning the original pod address to the VMs interface and setting the routes:
# ip addr add <IP_ADDRESS>/32 dev enp1s0
# ip link set enp1s0 up
# ip route add <IP_ADDRESS> dev enp1s0 scope link
# ip route add default via <IP_ADDRESS>

With this the pod is able to reach out into the world and I can also reach into the pod via a regular LoadBalancer address.
Switching networking to slirp works as expected, so the dhcp client in the VM clearly works, but switching to bridged networking (or masqurade) causes the network configuration of the VM to fail.
It seems to me that the DHCP server is broken, as no IP or routes are assigned to the VM, unfortunately there's very little log output, even with verbosity turned up to 11, so this is just about all the DHCP related output of the virt-launcher log:
{"component":"virt-launcher","level":"info","msg":"The imported dhcpConfig: DHCPConfig: { Name: eth0, IPv4: <IP_ADDRESS>/32 eth0, IPv6: \u003cnil\u003e, MAC: 02:05:11:b0:42:42, AdvertisingIPAddr: <IP_ADDRESS>, MTU: 1440, Gateway: <IP_ADDRESS>, IPAMDisabled: false}","pos":"podnic.go:260","timestamp":"2022-12-14T07:21:50.083040Z"}
{"component":"virt-launcher","level":"info","msg":"StartDHCP network Nic: DHCPConfig: { Name: eth0, IPv4: <IP_ADDRESS>/32 eth0, IPv6: \u003cnil\u003e, MAC: 02:05:11:b0:42:42, AdvertisingIPAddr: <IP_ADDRESS>, MTU: 1440, Gateway: <IP_ADDRESS>, IPAMDisabled: false}","pos":"common.go:332","timestamp":"2022-12-14T07:21:50.083144Z"}
{"component":"virt-launcher","level":"info","msg":"Starting SingleClientDHCPServer","pos":"server.go:65","timestamp":"2022-12-14T07:21:50.083470Z"}

Rebooting the VM doesn't cause any log lines from the DHCP server as would be expected (with verbosity set to 11), but the virt-launcher is clearly listening for requests:
# netstat -lnpu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
udp        0      0 <IP_ADDRESS>:67              <IP_ADDRESS>:*                           12/virt-launcher

I tried running tcpdump in the VM and configured its network manager for verbose logging, but I never see any dhcp requests being sent from the VM.
At this point I reviewed the network configuration of the VM itself and it turned out that the network interface changed its name, so the VM was actually not configured to run DHCP, when I added the new network interface to the network manager configuration the VM started working perfectly.
The only reason I created the ubuntu based VM was to debug this situation, so I went back to the windows VMs that originally failed and after switching them to bridging they started working perfectly too.
Bottom line is that I think the bridging problem was fixed somewhere in the 0.48.0 to 0.58.0 time frame.

@dren-dk Nice debugging.
@EdDev Would you know of any changes that would fix this?

I do not see anything related, maybe @AlonaKaplan has a clue.

I would think that maybe this PR. But it was fixed on v0.43.
The VM syslog is needed to be able to debug it. But since now it is working, I"m not sure it has to be debugged.


fix(curriculum): enhanced grammer and flexibility in tests to accommodate any valid response

Checklist:

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

Closes #53700

Hey @aaqib605
Thank you for opening this pull request and being eager to contribute.
You have already another PR, which will be merged, for issue limited to the "first time" code contributors to this repository. Let's leave this issue one for other first timers. Because of that I'm going to close this PR. We would welcome future pull requests from you.
Thank you and happy coding.

Hey @aaqib605
Thank you for opening this pull request and being eager to contribute.
You have already another PR, which will be merged, for issue limited to the "first time" code contributors to this repository. Let's leave this issue one for other first timers. Because of that I'm going to close this PR. We would welcome future pull requests from you.
Thank you and happy coding.
@gikf I appreciate your consideration. I look forward to contributing in the future.

Thank you again and have a great day!

Hey @aaqib605
Thank you for opening this pull request and being eager to contribute.
You have already another PR, which will be merged, for issue limited to the "first time" code contributors to this repository. Let's leave this issue one for other first timers. Because of that I'm going to close this PR. We would welcome future pull requests from you.
Thank you and happy coding.

@gikf I appreciate your consideration and I look forward to contributing in the future.
Thank you again and have a great day!

@gikf Never mind. Happens to the best of us. Happy to contribute.

The second test only passes if the condition is userData?.currentSong === null || userData?.currentSong.id !== song.id.
Can you try and look into that too?

@Ksound22 Done. Now the tests work for all possible code variations.

The second test only passes if the condition is userData?.currentSong === null || userData?.currentSong.id !== song.id.
Can you try and look into that too?

@Ksound22 Done. Now the tests work for all possible code variations.

No. The second test is not reached anymore for the three possible conditions from the issue

@Ksound22 Made the necessary changes. It should work fine now.

@gikf @Ksound22 Currently code is working fine for every possible scenario, also the semi-colon is optional. Please suggest am i missing something here?

Reference

I've taken a look again.
The tests still pass without adding audio.currentTime = 0 inside the if statement when you use the three conditions as they are in the issue
Only the condition userData?.currentSong.id !== song.id || userData?.currentSong === undefined does not behave like that.

@Ksound22 I double checked and everything is working as intended. Could you please look into  it again?

if (!userData?.currentSong || userData?.currentSong.id !== song.id ) {}

image
Are you sure the changes were committed and pushed to the PR branch?

if (!userData?.currentSong || userData?.currentSong.id !== song.id ) {}

image
Are you sure the changes were committed and pushed to the PR branch?

@gikf Yes I've merged the changes from my pull request branch into the main branch of the forked repository.

That looks like being pushed to the main branch. Make sure you checkout the fix/grammar-issues-and-update-tests-in-step-29-of-music-player-project branch, then try:
git push origin fix/grammar-issues-and-update-tests-in-step-29-of-music-player-project

@gikf I've pushed the changes to the PR branch. Could you please review them now?

@aaqib605 Unfortunately I'm not seeing any new commits on the PR branch: https://github.com/freeCodeCamp/freeCodeCamp/pull/53786/commits
Please make sure they are pushed to the right branch. Join us in our chat room or the forum if you need help with it, our moderators will guide you through this.

What might be causing the delay in merging the pull request?

the pull request is not ready to be merged, you need to make changes to the branch to make the tests work correctly

Could you please take a look at the freeCodeCamp discord forum, asked for help there
https://discord.com/channels/692816967895220344/1019641182340534294/threads/1217091995600683139

Should i just make a new PR?

Should i just make a new PR?

I think you should.

Now I am looking at the PR with the latest version.
if (!userData?.currentSong || userData?.currentSong.id !== song.id) {}

if (userData?.currentSong.id !== song.id||userData?.currentSong === null) {}

These code snippets are valid and should pass the first test, but I am told
"You should create an if statement with the condition userData?.currentSong === null || userData?.currentSong.id !== song.id."

Now it works as requested! Sorry for the noise
I have a little point to make:

So userData?.currentSong === undefined should not actually pass

Hey @ilenia-magoni 👋🏽
Thanks for requesting I review this again. It's now okay with me. Could you please take a look at it yourself and approve it?
This took a lot of time, so I think it needs an extra eye.

Thanks for not giving up on this, @aaqib605!

I would like to thank everybody for their support.

Now it works as requested! Sorry for the noise
I have a little point to make: undefined === null is false So userData?.currentSong === undefined should not actually pass

@ilenia-magoni Could you please explain this in more detail, like how it affects the solution?

Now it works as requested! Sorry for the noise
I have a little point to make: undefined === null is false So userData?.currentSong === undefined should not actually pass

@ilenia-magoni Could you please explain this in more detail, like how it affects the solution?

The condition for the if statement is to check if userData?.currentSong is null, checking if it is undefined doesn't complete this goal, because if it is null, null === undefined is still false, so you should remove userData?.currentSong from the accepted solutions. You allow it with this part of the regex userData\?\.currentSong\s*===\s*undefined. That would be removing that section from two places in each test.

HI @aaqib605 !
It looks like there is one last change made for this PR left in this comment here
https://github.com/freeCodeCamp/freeCodeCamp/pull/53786#issuecomment-2039171029
It could make that change, then we should be good to go with this PR 👍

HI @aaqib605 !
It looks like there is one last change requested for this PR left in this comment here #53786 (comment)
It could make that change, then we should be good to go with this PR 👍

Thanks, everybody for the patience, I am working to implement this little change.


antismash.R code error

Dear all
I was trying to convert my antismash.json output into csv for BGCViz, but I encountered this error:
Warning messages:
1: Expected 2 pieces. Additional pieces discarded in 10 rows [38, 65, 149, 171, 184, 185, 201, 206, 306, 310].
2: Expected 2 pieces. Missing pieces filled with `NA` in 297 rows [1, 3, 5, 6, 7, 9, 10, 11, 12, 13, 14, 15, 17, 19, 20, 21, 22, 23, 24, 25, ...].
Error in (function (..., row.names = NULL, check.rows = FALSE, check.names = TRUE,  :
  arguments imply differing number of rows: 0, 1
Calls: cbind ... as.data.frame -> as.data.frame.list -> do.call -> <Anonymous>
Execution halted

Could someone point to me what the issue is with my input file? It came straight out of my antiSMASH run so I am rather puzzled. Thanks
Marcus

Hello,
Sorry for such long pause, but the BGCViz was updated and now supports the antismash.json input directly. I encourage you to try once more!


Personalization via appending URL & updating value

Hi there!
Newbie here. I've been thinking about a use case to pseudo-personalize a webpage where if the url is:
http://www.website.com/welcome=FirstName
Then the page can pick up the "FirstName" value and pass the data into a <p> tag
Can the Simulacra plugin be used for this sort of use case?
Also, I've done some research and apparently JS based binding is prone to XSS vulnerabilities. Any thoughts on that?
Thanks
vilav

Yes, in the bound data object it would look something like this:
var data = {
  name: window.location.toString().match(/welcome=+(.*)/)[1]
}

This library has nothing to do with XSS since there's absolutely no networking code. I think you misunderstand the scope of this library, it's very limited.


Fixes to PropTypes

Don't really know why 'oneOfType' is left alone in 'Link' while others are defined in 'PropTypes.js'.
Found it cleaner to remove 'oneOfType' from Link and describe it in PropTypes as the others. Sure @taion or @timdorr has some input on why this is bad, but was worth as shot.
Also, I didn't find this to collide with #3218
=======
Lastly; I'm sorry for so many PR's. I learn from your replies, which helps me to be a better programmer, writing future code. I'm very thankful for you answering PR's instead of just closing them, which would be quite tempting, as you get a lot of issues and PR's that's not right.

See https://github.com/reactjs/react-router/issues/3205 – I think I want to get rid of these prop type definitions entirely. Sorry, but thanks for the PR.


[Package Issue]: Microsoft.VCRedist.2005.x64 incorrectly identifies as x86

Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Side-By-Side installation.
Brief description of your issue
When looking to install Microsoft Visual C++ 2005 Redistributable, winget offers both .x86 and .x64 packages.
PS > winget search --source winget --id Microsoft.VCRedist.2005

Name                                            Id                          Version
-------------------------------------------------------------------------------------
Microsoft Visual C++ 2005 Redistributable       Microsoft.VCRedist.2005.x86 8.0.61001
Microsoft Visual C++ 2005 Redistributable (x64) Microsoft.VCRedist.2005.x64 8.0.61000

However, the .x64 package ID is not correctly retained upon installation of Microsoft.VCRedist.2005.x64.
Instead, the installed package identifies using the ID Microsoft.VCRedist.2005.x86.
This also affects update detection, as x86 and x64 have different available versions.
Steps to reproduce
Install Microsoft Visual C++ 2005 Redistributable (x64)
winget install -e --source winget --id Microsoft.VCRedist.2005.x64

Check for details of installed package
winget list --source winget --id Microsoft.VCRedist.2005

Actual behavior
While the package Name is correct, the package ID incorrectly uses the .x86 architecture identifier.
PS > winget list --source winget --id Microsoft.VCRedist.2005

Name                                            Id                          Version   Available
-----------------------------------------------------------------------------------------------
Microsoft Visual C++ 2005 Redistributable (x64) Microsoft.VCRedist.2005.x86 8.0.61000 8.0.61001

Installing Microsoft.VCRedist.2005.x86 if Microsoft.VCRedist.2005.x64 is already installed will overwrite the x64 version (8.0.61000) with the x86 version (8.0.61001).
Installing the x64 version after the x86 version will result in a duplicate entry in winget for the package ID Microsoft.VCRedist.2005.x86.
PS > winget list --source winget --id Microsoft.VCRedist.2005

Name                                            Id                          Version
-------------------------------------------------------------------------------------
Microsoft Visual C++ 2005 Redistributable       Microsoft.VCRedist.2005.x86 8.0.61001
Microsoft Visual C++ 2005 Redistributable (x64) Microsoft.VCRedist.2005.x86 8.0.61000

Expected behavior
Installed package ID should use the .x64 architecture identifier
PS > winget list --source winget --id Microsoft.VCRedist.2005

Name                                            Id                          Version   Available
-----------------------------------------------------------------------------------------------
Microsoft Visual C++ 2005 Redistributable (x64) Microsoft.VCRedist.2005.x64 8.0.61000 8.0.61000

Installing the x86 version should not override an already-installed x64 version.
Installing both versions should result in different package ID entries.
PS > winget list --source winget --id Microsoft.VCRedist.2005

Name                                            Id                          Version   Available
-----------------------------------------------------------------------------------------------
Microsoft Visual C++ 2005 Redistributable       Microsoft.VCRedist.2005.x86 8.0.61001
Microsoft Visual C++ 2005 Redistributable (x64) Microsoft.VCRedist.2005.x64 8.0.61000 8.0.61000

Environment
Windows Package Manager v1.8.1791
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.3810
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.23.1791.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Screenshots and Logs
No response

I believe this might be an issue with the application and installer, not quite the package manager. But this is why the old advice was "just install both architectures", to solve still needing the DLL, and also the "upgrade always available" situation.


One run, many directories

In this PR we allow ProtoData to process multiple directories with source code at once.
In CLI mode, this is achieved by supplying several paths for the --src and --destination arguments. The paths should be separated by the : symbol (or ; on Windows). The number of source dirs must match the number of target dirs exactly.
In Gradle plugin mode, this is achieved by supplying several subDirs. Note that the plugin effectively limits the usage of this feature to processing several subdirectories within one root source directory. To process source files in several projects, one needs to run the ProtoData tasks for each project.
When processing multiple source file sets, the Renderer.render(..) method is called multiple times. This is a change of behaviour compared to previous versions of ProtoData. However, there was never a guarantee of exactly one invocation of this method. Still, developers who create custom renderers should make sure files are not duplicated.

@armiol, I'll see what I can do about those bot messages. Meanwhile, PTAL.

@armiol, PTAL.


General mobile discovery 2

I have a problem with swipe on General Mobile Discovery 2. While im swiping, layout doesnt change. After hand release, layout swipes(open) immediately and back to close state. i debugged swipeListener and everything seems normal.

The case occured on Casper Via8. Demo application also has this bug. I think there are problems at these phones' android sdk.


Environment variable PUBLIC_PORT does not apply to PalWorldSettings.ini.

Describe the bug
Environment variable PUBLIC_PORT does not apply to PublicPort of PalWorldSettings.ini.
To Reproduce
Steps to reproduce the behavior:

Set PUBLIC_PORT to a value other than 8211 in enviroments in docker-compose.yml.

    environment:
      PUBLIC_PORT: 8212

Do docker compose up -d
see PublicPort of PalWorldSettings.ini
sed -nre 's/.*(PublicPort=\w+).*/\1/p ' palworld/Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
always PublicPort=8211

Expected behavior
docker-compose.yml
    environment:
      PUBLIC_PORT: 8212

PalWorldSettings.ini
PublicPort=8212

Actual behavior
docker-compose.yml
    environment:
      PUBLIC_PORT: 8212

PalWorldSettings.ini
PublicPort=8211

Screenshots
nothing.
OS information

OS:  Ubuntu 22.04 LTS
Palworld Version:  <IP_ADDRESS>
Docker Image Version:  0.25.0

Hardware information

CPU:  Intel Core i9 13900K
Memory:  DDR5 192GB

docker-compose.yml contents
version: '3'

services:
  pal:
    container_name: pal
    image: thijsvanloef/palworld-server-docker:latest
    restart: unless-stopped
    stop_grace_period: 30s
    tty: true
    volumes:
      - ./palworld:/palworld/
    environment:
      TZ: Asia/Tokyo
      PUID: 1000
      PGID: 1000
      PORT: 8211
      PUBLIC_PORT: 8212
      PUBLIC_IP: pal.a-b-c-d.com
      PLAYERS: 32
      SERVER_PASSWORD: "test"
      ADMIN_PASSWORD: admin"
      MULTITHREADING: true
      RCON_ENABLED: true
      RCON_PORT: 25575
      COMMUNITY: true
      SERVER_NAME: "TEST"
      SERVER_DESCRIPTION: "TEST"
      BACKUP_ENABLED: false
    ports:
      - "8212:8211/udp"
      - "25575:25575/tcp"
    healthcheck:
      test: rcon-cli info

Container/Host Logs
*****EXECUTING USERMOD*****
usermod: no changes
*****STARTING INSTALL/UPDATE*****
Sending Discord json: {"embeds":[{"title":"Server is updating...","color":15258703}]}
tid(29) burning pthread_key_t == 0 so we never use it
Redirecting stderr to '/home/steam/Steam/logs/stderr.txt'
Logging directory: '/home/steam/Steam/logs'
/tmp/dumps is not owned by us - delete and recreate
[  0%] Checking for available updates...
[----] Verifying installation...
[  0%] Downloading update...
[  0%] Checking for available updates...
[----] Download complete.
[----] Extracting package...
[----] Extracting package...
[----] Extracting package...
[----] Extracting package...
[----] Installing update...
[----] Installing update...
[----] Installing update...
[----] Installing update...
[----] Installing update...
[----] Installing update...
[----] Installing update...
[----] Installing update...
[----] Cleaning up...
[----] Update complete, launching Steamcmd...
tid(42) burning pthread_key_t == 0 so we never use it
Redirecting stderr to '/home/steam/Steam/logs/stderr.txt'
Logging directory: '/home/steam/Steam/logs'
[  0%] Checking for available updates...
[----] Verifying installation...
Steam Console Client (c) Valve Corporation - version<PHONE_NUMBER>
-- type 'quit' to exit --
Loading Steam API...OK
"@sSteamCmdForcePlatformType" = "linux"
"@sSteamCmdForcePlatformBitness" = "64"

Connecting anonymously to Steam Public...OK
Waiting for client config...OK
Waiting for user info...OK
 Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)
 Update state (0x5) verifying install, progress: 10.52 (237881860 /<PHONE_NUMBER>)
 Update state (0x5) verifying install, progress: 30.96 (699749462 /<PHONE_NUMBER>)
 Update state (0x5) verifying install, progress: 67.07<PHONE_NUMBER> /<PHONE_NUMBER>)
Success! App '2394010' fully installed.
Sending Discord json: {"embeds":[{"title":"Server update complete!","color":52224}]}
*****GENERATING CONFIG*****
***Using Env vars to create PalWorldSettings.ini***
Compiling PalWorldSettings.ini...
Compiling PalWorldSettings.ini done!
***** STARTING SERVER*****
./PalServer.sh -port=8211 -queryport=27015 EpicApp=PalServer -userperfthreads -NoAsyncLoadingThread -UseMultithreadForDS
Sending Discord json: {"embeds":[{"title":"Server is started!","color":52224}]}
Shutdown handler: initalize.
Increasing per-process limit of core file size to infinity.
- Existing per-process limit (soft=18446744073709551615, hard=18446744073709551615) is enough for us (need only<PHONE_NUMBER>3709551615)
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
CAppInfoCacheReadFromDiskThread took 2 milliseconds to initialize
dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory
Setting breakpad minidump AppID = 2394010
[S_API FAIL] Tried to access Steam interface SteamUser021 before SteamAPI_Init succeeded.
[S_API FAIL] Tried to access Steam interface SteamFriends017 before SteamAPI_Init succeeded.
[S_API FAIL] Tried to access Steam interface STEAMAPPS_INTERFACE_VERSION008 before SteamAPI_Init succeeded.
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.

Additional context
nothing.

Maybe...
https://github.com/thijsvanloef/palworld-server-docker/blob/dd93c22da36046b527a04dfce7b131082fd42ea8/scripts/compile-settings.sh#L79

Is fixed in the next release


Iterate through all of dataloader each epoch.

Compute epoch energy as the average of the batch energies.

Thanks Alex! Just to confirm I understand what the change is: previously, each epoch would just use the next batch from the dataset, and losses were computed per batch. So during training, the model only saw each example once. Change is each epoch uses the entire dataset, and losses are computed for the whole dataset at each epoch.
It makes sense that the old method would finish very fast, because it only processes len(dataset) samples rather than n_epoch*len(dataset) samples. I'm guessing the loss and filters learned were also not as good?

Almost. The previous incorrect method saw batch_size*epoch samples while the new method sees len(dataset)*epoch samples. So the losses returned previously were only over a single batch. Now they are over the whole dataset. The previous method would make sense if we called n_epochs n_batch_updates instead but alas we did not.
In my experience, the loss and filters could be fine with the old method, you would just have to make n_epochs large.


Arrow release 10.0.0

Next weekly release follow on from #1304
Describe the solution you'd like
Release the next version of arrow-rs
I think that there are certain API changes (https://github.com/apache/arrow-rs/pull/1345 and https://github.com/apache/arrow-rs/pull/1346 that will require a major version bump -- 10.0.0)
I plan to create a release candidate as ususal
cc @nevi-me @velvia @liukun4515  @tustvold

@alamb
Please take this pull request https://github.com/apache/arrow-rs/pull/1388 in this release.
Thank you.

Please take this pull request https://github.com/apache/arrow-rs/pull/1388 in this release.

Will do 👍

One of the CI tests is failing on master: https://github.com/apache/arrow-rs/issues/1398 which I think needs to be looked at prior to releasing 10.0.0
I can probably find time in a few hours to look into it, but if anyone else has time, that would be greatly appreciated 🙏

Update: I believe I have a fix for https://github.com/apache/arrow-rs/issues/1398 on  https://github.com/apache/arrow-rs/pull/1402
It is a test only fix so I will move ahead with creating a release candidate for arrow now even without that fix

RC is available: https://lists.apache.org/thread/0qdntovo308g1cxsj1h113b1lr6gfvhh

Released


Use the new go install syntax in the README

Since a while ago, go no longer supports use of go get to install binaries. Use the new go install command for the README instead!

这是来自QQ邮箱的假期自动回复邮件。

您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

Forgot to mention - this closes #242  and #243

@ShadiestGoat Thanks!


Bug: collection xarray to_netcdf

Saving a collection's (after combined with validate) xarray to netcdf does not work.
new_collection.ds.to_netcdf()

The following error is thrown:
File "/readonly/dodrio/apps/RHEL8/zen2-ib/software/SciPy-bundle/2022.05-foss-2022a/lib/python3.10/site-packages/scipy/io/_netcdf.py", line 555, in _write_att_values
    nc_type = REVERSE[values.dtype.char, values.dtype.itemsize]
KeyError: ('U', 64)

I think the attribute type are not compatible.

This seems to be an issue with the engine you use (probably scipy) while it should be netcdf4.  I am using netcdf4 and never had this issue.
i will add netcdf4 to the dependencies, and specify the engine in the save nc function like this:
  # convert to nc
    xrdata.to_netcdf(path=target_file,
                      engine='netcdf4',
                      mode='w',
                      **kwargs)

I found this engine issue here: https://github.com/pydata/xarray/issues/3374


Generating raw SQL migration query files

In rails, generating migrations will also generate an .sql file to be used with SQL.
E.g, when creating a new migration, it will be accompanied with something like this file:
2103232813.sql
ALTER TABLE `products` CHANGE `group` `group` varchar(50) DEFAULT NULL
ALTER TABLE `products` CHANGE `person` `person` varchar(50) DEFAULT NULL
ALTER TABLE `products` CHANGE `store_name` `store_name` varchar(50) DEFAULT NULL

Is this possible with sequelize / umzug as well? At our company, engineers do not have access to production servers so we usually give the raw queries to our devops which they use to execute migrations on our production database.
I was thinking that this would be possible by using a custom storage adapter in new Umzug({storage: CustomStorage})? I would appreciate if someone could guide me to the right direction to achieve this functionality.

Hi.
The storage parameter just defines the space where umzug stores which migration is already executed and which not.
Right now umzug does not accept pure sql files, but there is a PR #149 that will allow this, when merged.

Hi @PascalPflaum, thanks for the reply.
In the issue you referenced, it refers to some query operations like find or all. What I would like to see is when running a migration, the raw query that is used by sequelize / umzug to be dumped into an .sql file. Did you by any chance took a look into rails? They have great support for this feature.

Hi @borislemke,
indeed I see this feature useful as well. "Umzug" is database agnostic and transforming a migration into database language is up to the ODM / Database Driver. I think sequelize would be the right project to open a issue in your case.


add selector types to generated client

SelectorSyncSet and SelectorSyncIdentityProvider did not have the necessary genclient annotation to be included in the generated client.

/lgtm


Cannot Transparently Pass On JSON String From Previously Unncrypted Field

Describe the bug
When adding encryption to fields that were previously unencrypted the algorithm will fail in the case of finding a stringified JSON object because of the ':' character.
To Reproduce
First create a schema with a previously unencrypted field which stores a stringified JSON object. Store some unencrypted JSON strings. Later enable encryption for that field and try to decrypt the records with unencrypted JSON. Usually text should just pass through silently, but this time it will find the ':' characters in the JSON string and throw an error when trying to decrypt.

Hi,
If you change from encrypted to unencrypted or vice-versa, you should perform a database migration to change those fields.
Alternatively, read without a schema and update the time.
Your PR suggests handling JSON encodings, but there could be any other formats that your PR won't address.
So I'd rather not apply the PR to handle just one such case out of a potential large set of encodings.


Handling a selected List item

Intent 1
|
Intent 2 ( implements app.intent('actions.intent.OPTION', (conv, params, option)... )
|
Intent 3 ( implements app.intent('actions.intent.OPTION', (conv, params, option)... )
Intent 2 and Intent 3 are follow-up intents for Intent 1 and Intent 2 respectively.
Intent 1 implements a List item which is handled in Intent 2.
Intent 2 also implements a List item which is handled in Intent 3.
Use case:

User is in Intent 1.
He clicks a List item in Intent 1.
User is in Intent 2.
Here he say Back (a kind of Back Button logic), and goes to Intent 1 using setFollowupEvent method.
User is in Intent 1 again.
He clicks a List item in Intent 1.

From here, what I'm expected to happen:

Click to be handled in Intent 2.

What happens:

Click is handled in Intent 3.

Try setting your context lifespans to 1


Remember scroll position

Is there an easy way to remember last scroll position after transitioning back into a route that uses this component?

+1, looking for a solution to this other than storing scroll state on every transition

You can do this by binding scroll-top and / or scroll-left to properties in your controller. For example adding this line: queryParams: ['scrollTop'], to this controller in the dummy app (https://github.com/emberjs/ember-collection/blob/master/tests/dummy/app/controllers/scroll-position.js) will put the scroll position in the URL and will be remembered when you re-visit the route.

The scroll position is remembered even without the query param (though not across page reloads). I added a note to that page of the dummy app about this.


interval.slt tests fail in main

Describe the bug
Error messages of coercing temporal types have changed. cargo test fails with the error:
[interval.slt] Running query: "select '1 month'::interval - '1980-01-01'::date;"
Error: query is expected to fail with error:
        DataFusion error: Error during planning: interval can't subtract timestamp/date
but got error:
        DataFusion error: type_coercion
caused by
Error during planning: interval can't subtract timestamp/date
[SQL] select '1 month'::interval - '1980-01-01'::date;
at tests/sqllogictests/test_files/interval.slt:330

To Reproduce
run the slt tests
Expected behavior
error messages need to be updated.
Additional context
No response

I believe @jackwener  fixed this in https://github.com/apache/arrow-datafusion/pull/6242


Wsproxy: context cancellation does not propagate across websocket transport

It should be possible to trigger a closing of the connection in order to propagate the context cancellation.

Turns out this is not what was happening, the context cancellation was working across the websocket connection but the proxy side wasn't closing the client stream like it should have.


RegKeyTest>>#testIntegerSerialization

In the Debug configuration this test triggers the following in strgprim.cpp:
239: ASSERT(!behavior->isIndirect());

The assertion is invalid

Fixed with commit a4b6bb2


DNS issues when using host based networking

Hello,
Due to an unrelated failure, a number of our containers restarted earlier today.
We have two containers that use host networking mode and have the label io.rancher.container.dns: true applied. These hosts came online and couldn't resolve an external service we have linked in.
They can resolve everything else we have linked but they could not resolve the external service.
Interestingly, the service was present in each of the IP address sections in the answers.json on both hosts but crucially not listed in the default section of the same file.
Component	Version
Rancher	v0.47.0
Cattle	v0.115.0
User Interface	v0.68.0
Rancher Compose	v0.5.3

External service is defined with two ip's as per below:
Portal:
  external_ips:
    - $PORTAL1_IP
    - $PORTAL2_IP

Other hosts in the stack can see the Portal linking but not this one, could this be a bug? I've got the system in this state now so can diagnose.

@Rucknar its a bug in all versions prior to v49: external services are not resolvable to host level containers, whether its linked or otherwise. Got fixed with the refactoring we've done around forming dns data. Good catch, thanks for reporting it. Hold on upgrading to v49 though, there was some performance bug we've addressed that is gonna be available in v50 (which is gonna be released early this week)
@sangeethah we have to add more tests for containers on host networking :) We should make sure all kinds of rancher services - external/alias/regular service can be resolved from host container.

Thanks @alena1108 I'll hold on until 50 is out the door. Happy for you to close this if you wish?

@Rucknar I can't be completely happy till it's validated by our QA :) So lets @sangeethah close it.

Tested with server version - v0.50.0-rc4
From containers that belong to services with networking set to "host"  and "io.rancher.container.dns" set to "true" , able to resolve external servives /alias services /regular services,


Adding quorum Reads

Coverage decreased (-0.9%) to 37.259% when pulling 60494a02329a165587451c2483869a8eb1c2cbc9 on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling 5ea4f03cae3962326e2b3aa2fc064afdbbd9f14b on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling 5ea4f03cae3962326e2b3aa2fc064afdbbd9f14b on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling 5ea4f03cae3962326e2b3aa2fc064afdbbd9f14b on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling 89d375cd7ff4cd31ba56fa58c106f6557313cf2a on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling 89d375cd7ff4cd31ba56fa58c106f6557313cf2a on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling 535eb22f52538e0bd663d7b9617bebecb5e45a89 on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling a7812c8d67ca5db6477aa10865e8c7dbc2a032a5 on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling a7812c8d67ca5db6477aa10865e8c7dbc2a032a5 on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.

Coverage decreased (-0.9%) to 37.259% when pulling b9234e411b4ab543ed820d0a10cc7cd1b93db60a on reads into ae23f237cb5267c4aff249fc926f9fedc087eb9d on master.


[hiccup-svg] svg.image is not exported

SVG image tag defined in image.ts is not exported in index.ts causing svg.image([x, y], url) to crash with undefined function

Hey @vorg - thanks for finding this. So far only used that function implicitly via convertTree(), but will release fix in the next few days (along with other updates)...


Isolate flow actions and ensure only them can reference the buildWorkResult provider

@bot-gradle test ACC

I've triggered the following builds for you:

AllConfigCacheTestsPullRequestFeedback build

Thanks for the feedback, @mlopatkin!

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

I've triggered a build for you.


Vercel edge middleware breaks endpoints

Describe the bug
Vercel edge middleware breaks endpoints. Tested with server less and edge functions which both result in a 404 when called.
Vercel logs show that 2 edge functions are generated, one for the SvelteKit endpoint and one for the edge middleware.
Middleware works as expected adding a x-from-middleware header to each response.
Reproduction
Github reproduction repo: https://github.com/dennisregalado/sveltekit-edge-middlware-bug
Production link: https://sveltekit-edge-middlware-bug.vercel.app/
Logs
[11:44:36.857] Cloning github.com/dennisregalado/sveltekit-edge-middlware-bug (Branch: main, Commit: ad3241d)
[11:44:37.094] Cloning completed: 236.859ms
[11:44:37.829] Looking up build cache...
[11:44:39.623] Build cache downloaded [20.28 MB]: 1442.974ms
[11:44:39.678] Running "vercel build"
[11:44:40.311] Vercel CLI 28.2.2
[11:44:41.144] Installing dependencies...
[11:44:41.571] yarn install v1.22.17
[11:44:41.652] [1/4] Resolving packages...
[11:44:41.770] success Already up-to-date.
[11:44:41.774] Done in 0.21s.
[11:44:42.039] ▲ [WARNING] Cannot find base config file "./.svelte-kit/tsconfig.json" [tsconfig.json]
[11:44:42.040]
[11:44:42.040]     tsconfig.json:2:12:
[11:44:42.040]       2 │   "extends": "./.svelte-kit/tsconfig.json",
[11:44:42.040]         ╵              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[11:44:42.040]
[11:44:42.836] vite v3.1.0 building for production...
[11:44:42.870] transforming...
[11:44:43.680] ✓ 30 modules transformed.
[11:44:43.757] rendering chunks...
[11:44:43.810] vite v3.1.0 building SSR bundle for production...
[11:44:43.819] transforming...
[11:44:44.302] ✓ 44 modules transformed.
[11:44:44.332] Generated an empty chunk: "hooks"
[11:44:44.341] rendering chunks...
[11:44:44.361] .svelte-kit/output/server/vite-manifest.json                           1.39 KiB
[11:44:44.361] .svelte-kit/output/server/index.js                                     67.05 KiB
[11:44:44.362] .svelte-kit/output/server/entries/endpoints/api/vercel/_server.ts.js   0.14 KiB
[11:44:44.362] .svelte-kit/output/server/entries/fallbacks/layout.svelte.js           0.23 KiB
[11:44:44.362] .svelte-kit/output/server/entries/fallbacks/error.svelte.js            1.50 KiB
[11:44:44.362] .svelte-kit/output/server/entries/pages/_page.svelte.js                0.25 KiB
[11:44:44.363] .svelte-kit/output/server/chunks/index.js                              3.10 KiB
[11:44:44.363] .svelte-kit/output/server/chunks/index2.js                             0.97 KiB
[11:44:44.363] .svelte-kit/output/server/chunks/hooks.js                              0.00 KiB
[11:44:44.771]
[11:44:44.772] Run npm run preview to preview your production build locally.
[11:44:44.775] .svelte-kit/output/client/vite-manifest.json                                         2.21 KiB
[11:44:44.778] .svelte-kit/output/client/_app/immutable/components/layout.svelte-22efdd62.js        0.53 KiB / gzip: 0.35 KiB
[11:44:44.778] .svelte-kit/output/client/_app/immutable/components/error.svelte-95488bc3.js         2.07 KiB / gzip: 0.95 KiB
[11:44:44.779] .svelte-kit/output/client/_app/immutable/components/pages/_page.svelte-1f47eaea.js   1.15 KiB / gzip: 0.65 KiB
[11:44:44.779] .svelte-kit/output/client/_app/immutable/chunks/singletons-8230117d.js               1.81 KiB / gzip: 0.99 KiB
[11:44:44.779] .svelte-kit/output/client/_app/immutable/start-e83c26d4.js                           22.92 KiB / gzip: 8.99 KiB
[11:44:44.779] .svelte-kit/output/client/_app/immutable/chunks/index-88d3cc7d.js                    6.71 KiB / gzip: 2.73 KiB
[11:44:44.780] .svelte-kit/output/client/_app/immutable/chunks/0-9bf09096.js                        0.09 KiB / gzip: 0.09 KiB
[11:44:44.780] .svelte-kit/output/client/_app/immutable/chunks/1-fc5779c9.js                        0.09 KiB / gzip: 0.09 KiB
[11:44:44.781] .svelte-kit/output/client/_app/immutable/chunks/2-dacbca07.js                        0.09 KiB / gzip: 0.10 KiB
[11:44:44.789]
[11:44:44.790] > Using @sveltejs/adapter-vercel
[11:44:44.824]   ✔ done
[11:44:45.145] Using TypeScript 4.8.3 (local user-provided)
[11:44:47.393] Build Completed in /vercel/output [6s]
[11:44:50.878] Generated build outputs:
[11:44:50.879]  - Static files: 12
[11:44:50.879]  - Serverless Functions: 0
[11:44:50.879]  - Edge Functions: 2
[11:44:50.879] Deployed outputs in 3s
[11:44:52.711] Build completed. Populating build cache...
[11:44:58.553] Uploading build cache [20.28 MB]...
[11:45:00.262] Build cache uploaded: 1.709s
[11:45:00.295] Done with "."

System Info
System:
    OS: macOS 12.5
    CPU: (8) arm64 Apple M2
    Memory: 111.63 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.17.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.15.0 - /opt/homebrew/bin/npm
  Browsers:
    Chrome: 105.0.5195.102
    Safari: 15.6
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.73
    @sveltejs/adapter-vercel: ^1.0.0-next.74 => 1.0.0-next.74
    @sveltejs/kit: next => 1.0.0-next.481
    svelte: ^3.44.0 => 3.50.1
    vite: ^3.1.0 => 3.1.0

Severity
annoyance
Additional Information
Bummer since their CEO tweeted it working as well.

This is true, vercel deploy doesn't work for me.
I have trailing slash value: always.
Netlify works like a charm

@smitpatelx, you might want to start a separate issue. This is purely for using middleware on Vercel with Sveltekit per their documentation.

Same as Nuxt. Added a middleware.ts file in root and checked logs. It was recognized but a simple basic auth didn't work.
https://nuxt-edge-functions-test-ochre.vercel.app/

Looking at the network tab, it seems that the middleware runs (the added header is present), but something goes wrong afterwards.

It appears that this is happening on the Vercel side — it's adding an additional /api/* route, and that's running before SvelteKit can be invoked. In a vanilla project (no framework), if you have an api directory containing serverless/edge functions, Vercel automatically translates these into api routes. It seems like the logic for doing that is entwined with the logic for handling middleware files.
Better-qualified people than me are looking into it, and I'm optimistic that we'll have a fix soon, but in the meantime I can offer you a delightfully simple workaround: rename src/routes/api to src/routes/literally-anything-else.

Maybe someone from vercel took this opportunity to onboard svelte developers, this feels like a hotfix release of svelte-support. Maybe vercel will add new implementation for deploying svelte in future. I love vercel but only for nextjs. For now, netlify works well for svelte. Thanks @Rich-Harris for explaination.

This is now fixed on the platform — closing


Adds ability to whitelist devDeps of the package to be installed

When co-locating codemods with existing packages such as react etc, you will likely need to install various dependencies to perform various tasks like utils, parsing, etc. These dependencies when added to your package increase the bundlesize for regular consumers even if they're not using the codemods.
This change introduces a way around this by adding a new property to the config object dependencies where you can specify the devDeps you would like to whitelist.
dependencies: ['@hypermod/utils', 'postcss']
These will be ready by hypermod and referenced against the package.json, then installed with the package at transformation time avoiding the bundlesize bloat for regular consumers.

[ ] more testing
[ ] docs


Update misc. links and READMEs

Update links to documentation server in Rust docs
Themis wiki on GitHub has been deprecated. Let's point users to the proper, up-to-date documentation
(starting with the next release, that is).

Update links in RustThemis README as well

Quickstart => Getting started
Because we have moved away from that wording in the documentation.

Capitalize as “RustThemis” without a dash
Because that's how it's spelled in the documentation.

Replace CircleCI badge with GitHub Actions
CI has migrated to GitHub, let's update the badge to something actually indicative.

Actually, when I looked around, there were quite a few outdated documentation server links, outdated instructions, etc. I've updated most of them.
There are quite a few links left in the changelog, but I'm too lazy for that. Old versions – old links. No way anybody will actually click them, right?

Actually, when I looked around, there were quite a few outdated documentation server links, outdated instructions, etc. I've updated most of them.
There are quite a few links left in the changelog, but I'm too lazy for that. Old versions – old links. No way anybody will actually click them, right?

    Type:      fail-unless
!    Condition: condition
!    File:      tests/themis/themis_seccure_message.c
!    Line:      1649

That's a new test from #767, failing this condition:
    testsuite_fail_unless((187 <= signed_message_length_actual) && (signed_message_length_actual <= 189),
                          "produces message with expected actual length");


[BUG] When upgrading with bonded NICs uplinks stop showing up in UI and management interface disappears

Describe the bug

When you run an upgrade with bonded NICs the network section of the UI stops showing things as it should.

You can't add a network config to the existing cluster network.
You don't see any uplinks available in the dropdown for network configs
The existing cluster network shows as unavailable
The network does still work though on the VM after upgrade

To Reproduce
Steps to reproduce the behavior:
I tested this with two configurations. The support bundles are for after the upgrade. I ran the upgrades using the walkthrough for airgapped upgrades. After install of v1.0.3 I created a VLAN network before upgrade and assigned a VM to it to test with.
First Config

Single node libvirt setup

12 cores
24GB RAM
SATA SSD

bonded NIC setup during ISO install for management network

I setup the VLAN interface to use harvester-mgmt on VLAN 1
bonded nic on management interface with VLAN on management.zip

Second config

Single node libvirt setup

12 cores
24GB RAM
SATA SSD

Two bonded NICs setup via harvester config during ISO install
harvester.config.txt

First bonded NIC is the bonded management interface
Second bonded NIC is for the VLAN interface and is harvester-vlan
I setup the VLAN interface to use the second bonded nic harvester-vlan
dual bonded nics with vlan on harvester-vlan bonded interface.zip

Expected behavior

Support bundle

dual bonded nics with vlan on harvester-vlan bonded interface.zip
bonded nic on management interface with VLAN on management.zip
Environment

Harvester ISO version: master-47a3af23-head
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): Single node virtualized environment. Specified in repro steps

Additional context
Add any other context about the problem here.
This was found while testing #3045 .
I saw that when I was done running these upgrades that the cluster network was created, but no network was. The VLAN network was created and up. It also still worked with VMs from before the upgrade. However none of the NICs are shown as available, including the management  network that should have been unused in the Second Config. In the VLAN networks if you try to create another one the cluster network shows as unavailable.
So both of the environments will come up, but then the network configuration options seem to become unusable. I have more screenshots of the setups before and after the upgrade if needed

The support bundles look like for the v1.0.3.

@noahgildersleeve I checked both support bundles, and looks like the cluster was upgraded to a master ISO build in Sep.
harvester: 47a3af23
harvesterChart: 0.0.0-master-47a3af23
os: Harvester master
kubernetes: v1.22.12+rke2r1
rancher: v2.6.4-harvester3
monitoringChart: 100.1.0+up19.0.3
kubevirt: 0.54.0
rancherDependencies:
  fleet:
    chart: 100.0.3+up0.3.9
    app: 0.3.9
  fleet-crd:
    chart: 100.0.3+up0.3.9
    app: 0.3.9
  rancher-webhook:
    chart: 1.0.4+up0.2.5
    app: 0.2.5

Could you check if the ISO is correct? And maybe we can double verify again with 1.1.1-rc2.

I'll rerun the test with v1.1.1-rc2.

Closing due to functionality working and created ticket for UI issue at #3198 3198


osmanb.toml

My discord id osmanb#2178
E-mail<EMAIL_ADDRESS>

Please provide some more contact info provided. Not merged for now due to no contact info

Hello, my name is Osman CPA and I have been dealing with blockchain projects since 2016. I am validator in Avax network, I participated in cosmic horizon, quicksilver, dws testsnet in cosmos ecosystem before.
Discord id: osmanb#2178
<EMAIL_ADDRESS>


Add tooltip for number of subflow instance on info tab

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes
I added tooltip for subflow instance button on info tab.

Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[x] I have run npm run test to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Thanks - I wonder why I checked-in a commented out line here. I wonder if I found a scenario where it didn't update properly.

I feel that the comment means todo.🤔

[celebrate]     横井一仁 / Yokoi，Kazuhito reacted to your message:

From: knolleary @.>
Sent: Monday, June 24, 2024 3:26:16 PM
To: node-red/node-red @.>
Cc: 横井一仁 / Yokoi，Kazuhito @.>; Author @.>
Subject: [!]Re: [node-red/node-red] Add tooltip for number of subflow instance on info tab (PR #4786)
Merged #4786https://secure-web.cisco.com/1zaUN9ZeXbE9y0ItBODPBR9aiCaWn5kEO4J8g62-wEPFgZVuwbiAtrpxLMXhPTC3xb5RqXEYRuLzvjts7sMIHm7PKon-OCm2CZXdh4-KSMcewhg4J7I9KcWoe1rsgtI3GknkLDrvBZwMwhUWrAOxcu2LncPbNmlJddpJ5qVrIsiyg49hl08k8FvFrSUFKuKdXUFFPQllBSprOcuc915OqV0ZcaeHrRnkyEObtI-wAZomPw1cYACckZzqUG6JCO5_YPyM6QAb73Chh63zLy95ugyeEE74mx-xHH2n1X1eyu59wGxGuHzH1HkLsfexrs98K1SdhZxLHnCbtLFD-HkMnsg/https%3A%2F%2Fgithub.com%2Fnode-red%2Fnode-red%2Fpull%2F4786 into master.
―
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1fUAh3DPk8OFFoxyA1YMg66ar0o0yktrcjnk2Xe_i8tapT1EYx5dL5t3N5QIuBCsVVqpHWp9Twtf2TyKrj6-VlEegefwOAno1iPJIqkt837J75yh9svtI0MkUzugrBVZBWd0pRJNacaJegCYyia-EaCy1DbbBfDo-gVEJeP8C81fARDtjzBxMZGzWeStFNoEJN5h0G_-h54X2nlOnhZ8a7bsttKs4FPzw44JBQq-4vswAM3OYu13QJ2dfdkBMBnLDktuXg8afPrIbtIlpdldhbQ8dFVeJr9yc6514V3ld55TaFWqLp-ivXRVRtJh3IaeqLAcVnac19ekSHfR8euVZbw/https%3A%2F%2Fgithub.com%2Fnode-red%2Fnode-red%2Fpull%2F4786%23event-13268194178, or unsubscribehttps://secure-web.cisco.com/1-DiJ5rZ8YLkU0YEoprhybC6jkl88hAgS0RQqG0TuunVj8z0Aa_ngb6zOzrkN9qEcDTpo3jNCDJM9RvDew61QWtMgIWbqcypB7pp3MEGAnIJhjFYPIThrp2nen6oN3OzDXWsJJHuB1pgTiK4uuXrNKpbeym-YviZnNx3I9MTjI-Kri-KphAObVxgwenMYbrBnuT89I0jNOZ_HTYOMEdZT8rCanSFg_hwJrYy_daye-3cGQ6nlZ52oiATCk_2ZAUpx16lBSX8OZr-NudQpqaL8lplfFt_hm4aif0U3BcPUWr8E9CxM8WWH9KiAzUscxWwl_DNe8lxVgab0BI7P4jHAXA/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE26XF7DQHADXWZSU5JQ3PTZJA3BRAVCNFSM6AAAAABJYJ62YGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTGI3DQMJZGQYTOOA.
You are receiving this because you authored the thread.Message ID: @.***>


iOS wrapper refactoring

I have refactored files of objc wrapper, from folder /src/wrappers/themis/Obj-C/objcthemis.
Basic changes:

use TS prefix for every class name according to Apple Code Convetions
rename methods to correspond Apple Coding Guidelines
use properties instead of ivars why?
change typedef enum into typedef NS_ENUM
update syntax to Modern ObjC Syntax acoording to clang guide and apple guide
update Doxygen comments (although we still have comments like @param [in] context user context)
fix xcode warnings (objcthemis is now warnings-free, although compiling themis in xcode using default preferences still generates 69 warnings from files outside objcthemis folder)

update iOS project to reflect these changes
add TODO for unimplemented pieces (like SecureSession)

I've pointed Pod to use head of this branch, which is good for testing, but should be changed, as soon as pull request will be merged.
@mnaza please, look through changes, leave comments (if any).
Unfortunately, auto merge is disabled, so I'll merge pull-request manually after your approval.
And point Pod to master's head.
And check if everything is working again.

All work fine.


URL expansion endpoint

Create a URL expansion endpoint..
From a g/GOOGLEURL return the JSON document it encodes.
Later this will be the endpoint that can look up our own storage solution.

NB hang on implementing this until we've thought everything through: may not be needed if we embed data a la #655


Test Swift

This might provide some insight: https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly

Thanks @MggMuggins!
That holds consistent with the results collected from Swift 2 back in the first round of testing.
The main challange is that WASM and LLVM IR are different languages, Emscripten can compile many, if not most, LLVM IR operations into WASM but not all operations.
WASM limitations the Emscripten can't cover over are what is currently preventing Swift from compiling to WASM. What remains to be seen is if the right combination of Swift compiler flags can overcome the issues or if it will require changes to Swift's compiler.

Swift has been tested, it is currently not supported, more details in the swift readme file.


When in dark mode, Recomposition SwingPanel will flashes

https://user-images.githubusercontent.com/16540656/152769994-505a4195-5dae-40ea-892d-8a7153a42b7f.mp4
fun main() = application {
    Window(
        onCloseRequest = ::exitApplication,
    ) {
        MaterialTheme(colors = darkColors()) {
            Column(
                horizontalAlignment = Alignment.CenterHorizontally,
                verticalArrangement = Arrangement.Top,
                modifier = Modifier
                    .background(MaterialTheme.colors.background)
                    .fillMaxSize()
            ) {
                var boxVisible by remember { mutableStateOf(false) }
                Button(onClick = { boxVisible = !boxVisible }) {
                    Text(text = "Show Box")
                }
                if (boxVisible) {
                    Box(Modifier.background(Color(0xFF121212)).width(600.dp).height(500.dp).border(1.dp,Color.DarkGray)) {
                        Text("Box Visible is: $boxVisible",color = MaterialTheme.colors.onBackground)
                    }
                }
                var swingVisible by remember{ mutableStateOf(false)}
                Button(onClick = {swingVisible = !swingVisible}){
                    Text(text = "Show SwingPanel")
                }
                if(swingVisible){
                    SwingPanel(
                        background = Color(0xFF121212),
                        modifier = Modifier.width(600.dp).height(500.dp).border(1.dp,Color.DarkGray),
                        factory = {
                            JPanel().apply {
                                background = java.awt.Color(12,12,12)
                                add(JTextArea("SwingPanel Visible is: $swingVisible"))
                            }

                        }
                    )
                }

            }
        }

    }
}

How to remove the flash?

How to eliminate the flash?

I think the flash is actually the swing panel that is in the light mode appearing for a brief second before recomposition kicks in. I've seen this in my own implementation
https://user-images.githubusercontent.com/13775137/156100575-966c0eea-04cc-49f6-91eb-0ee575d5dfcf.mov
A related conversation on slack here, indicates that this is actually a swing issue that is raised here

In the reporter's video, the flash seems to be when the SwingPanel is removed. I tested the latest Compose, and there is no flash when it's removed, but there is when it's added!
https://user-images.githubusercontent.com/5230206/227174209-8cee1ea8-c379-42d8-91dc-c1a353efb29e.mp4

A white flash also appears when initialize ComposePanel.

fun main() = SwingUtilities.invokeLater {
    val window = JFrame()
    // creating ComposePanel
    val composePanel = ComposePanel()
    window.defaultCloseOperation = WindowConstants.EXIT_ON_CLOSE
    window.title = "SwingComposeWindow"

    window.background = java.awt.Color(12,12,12)
    // addind ComposePanel on JFrame
    window.contentPane.add(composePanel, BorderLayout.CENTER)

    // setting the content
    composePanel.setContent {
        ComposeContent()
    }

    window.setSize(800, 600)
    window.isVisible = true
}

@Composable
fun ComposeContent() {
    Box(
        modifier = Modifier.fillMaxSize().background(Color(0xFF434343)),
        contentAlignment = Alignment.Center
    ) {
        Text("ComposeContent", color = Color.White)
    }
}

https://github.com/JetBrains/compose-multiplatform/assets/16540656/b3dd8d4e-dac9-4ffa-9adf-e7c08e1c7e69

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


fix: bump postgrest-js

What kind of change does this PR introduce?
This version of postgrest-js includes the following fixes:

https://github.com/supabase/postgrest-js/pull/210
https://github.com/supabase/postgrest-js/pull/212

:tada: This PR is included in version 1.22.4 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Make domains configurable for hc score dsa1-score

Scoring mementos by Padia's work depends upon a list of domains for the categories of news, image sharing sites, video sharing sites, blog sites,  and social media sites. These lists will likely change over time and should be configurable by the end user.
The scoring is handled on lines 431 - 451 of hypercane/score/dsa1_ranking. We will have to make it generic.
https://github.com/oduwsdl/hypercane/blob/2e071d70185b8b0bbbeabacfb22d7be35b318c01/hypercane/score/dsa1_ranking.py#L431-L451
The lists themselves are on lines 15 - 386 of that same file.
https://github.com/oduwsdl/hypercane/blob/2e071d70185b8b0bbbeabacfb22d7be35b318c01/hypercane/score/dsa1_ranking.py#L15-L386

This is a duplicate of #10. Closing.


Minute should not be in multiple of 5.

Hello,
I want to display all minutes from 1 to 60.

Yes. You can show all minutes at your will. Maybe you need to change the radius of cylinder to avoid overlapping.


Issue with dynamic content and modal

When I have a modal that provides dynamic content (through use of ng-select and ng-include), how can I make the modal dialog either adjust its height or include a scrollbar on the content?  Currently if the user selects an item from a menu on the left side of the dialog, and a template is loaded on the right side with lengthy content, that content can extend past the height of the modal dialog.  What is the best way to handle this?

I am unsure what you issue actually is. Please provide a plunkr showing the issue you encounter.

Closing due to the lack of response


[Request] Audio Speedhack?

The speedhack works really well, but the music is always off sync, I wonder if it would be possible for audio speedhack like megahack

this would be a very good feature to add


Use session's start_directory in session creation

This will make tmux's whole session be in a given directory, instead of just changing windows and panes' relative paths

Current coverage is 83.42% (diff: 100%)

Merging #197 into master will decrease coverage by 0.40%

@@             master       #197   diff @@
==========================================
  Files             5          5
  Lines           742        742
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits            622        619     -3
- Misses          120        123     +3
  Partials          0          0

Powered by Codecov. Last update b63ef54...a5e2194

This is breaking tests on tmux 1.8.
Maybe it can be a conditional support on the tmux version?

Done!
But there seems to be a problem with libtmux's is_version function when tmux's version is 1.9a (probably a parsing problem)

Rebased against  df60657

@minijackson can you make tests for this?

Sure thing

Unfortunately, I can't find a way to get the working directory of a session (even with tmux commands). I could inspect the process to see it's cwd, but that doesn't seem to be the right solution to me…

The session's environment doesn't have the right PWD, so I'm guessing that even inspecting the process is a no-go

Sorry for the late response, I am having issues keeping up with the project. I'm seeking maintainers @ https://github.com/tony/tmuxp/issues/290. If you (or someone you know) may be interested in helping maintain libtmux or tmuxp, feel free to contact me by email or in the https://github.com/tony/tmuxp/issues/290 issue.
In the mean time, if you're still interested in this PR, can you rebase it via git pull --rebase origin master?

@minijackson Can you rebase this?
I just merged #623 which moves us to a poetry packaging setup and will runs the PR through GitHub actions.
Also, air traffic control, is this the same as #403?

@tony Yes this is an implementation of the same feature as #403, with the check that Tmux is not 1.8. I'll rebase the PR in a quick moment.

Done!

@minijackson Thank you!  Is it possible you could check out the linting issue?
@anddam I just had an issue with you being let out of a PR at #441. In this case it seems @minijackson had this before you, but do you have any comments on this approach vs your own?

Lint should pass now ^^

Oh, I cannot find the is_version function in libtmux anymore...

There we go! It simply was renamed to has_version

@minijackson That leads me to a more questions, since if I publish, this goes to a lot of users that already have a bit of using tmuxp without this
If I could - I'd just have had this have been the default behavior. My concern is atm people are relying on this and triggering automated stuff.  I'm wondering if we should add this - but feature flag it somehow so users aren't caught with a new behavior off guard
Would this change behavior / disrupt any users using the current behavior as it is on master as of now? (e.g. what if they're relying on start_directory's behavior not setting stuff? e.g. they have a script executing somehow)
Is this something we should issue a deprecation warning behavior ? Have toggleable via an option?  Phase it in via an env variable?
Could you write something to CHANGES explaining the behavior? Explain the behavior in the documentation?

Also I may be overthinking it by the way - let me know what you think 😊

I think you're right that this changes could break some setup for end user: if a launched script creates a new window or pane dynamically for example. This may be a quite specific usecase, but not impossible to imagine. Breaking this usecase could be avoided by adding a new option (like session_directory) instead of using the start_directory.
I don't think this is optimal, since that means the behavior of the session's start_directory and the window's start_directory are incoherent: new panes are created under the window's start_directory, but new windows would not be created under the session's start_directory. But this is the current behaviour and users are used to it.
I'm afraid the choice isn't clear cut, and I don't think it is mine to make, but either way I'm happy to use a different option name, and update the doc if you want.

@minijackson I propose you document this in CHANGES and docs, and we merge this
I think I will then release this semver type in 1.6.0
This is minor and subtle enough for that case.  Rationale:

If someone was doing a serious command it'd be done manually
If someone was doing something very niche, it'd be through tmux itself
This behavioral change comparable to tmux(1)'s version bumps
If someone was doing commands that'd break stuff, they shouldn't update feature releases
The effects of this are really minor, they only effect newly created windows in a session, and they're matching the behavior normal tmux users would expect

@tony That's fine with me! I'll see if I can document that tomorrow.

@minijackson Sounds good!

@tony I'v updated the CHANGES file, but I'm not sure if or where I should update the documentation

@anddam […] do you have any comments on this approach vs your own?

He actually managed the 1.8 case I was asking about in my PR.

@minijackson I am unsure of what the original problem was here, but it seems like this may be solving the case of new windows/panes (from tmux vs tmuxp) being created in the original directory where tmuxp was run. If this is the case, a bug hotfix was just released last weekend that fixes this problem (v1.5.8+).

Yes, looking at the diff of #639, it seems that this PR is now a duplicate. Thank you for telling me!


Client Allocation Request for: deklod cloud data tecnology

Client Allocation Questions
Core Information

Name: deklod cloud data tecnology
Website / Social Media: https://dekun.decoo.io/
Region: Greater China Region
DataCap Requested: 200TiB
Addresses to be Notarized: f1mdk7s2vntzm6hu35yuo6vjubtrpfnb2awhgvrri
Notary Requested: 1ane-1,KIMQI001

@xiehaijun95 Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

The address was filled in incorrectly and submitted repeatedly.