Errors when using exec endpoint in LXD 3.5

Required information

Distribution: Ubuntu 18.04.1 LTS
Distribution version: 4.15.0-1019-gcp
The output of "lxc info":

config:
  core.https_address: '[::]:8443'
  core.trust_password: true
api_extensions:
- storage_zfs_remove_snapshots
- container_host_shutdown_timeout
- container_stop_priority
- container_syscall_filtering
- auth_pki
- container_last_used_at
- etag
- patch
- usb_devices
- https_allowed_credentials
- image_compression_algorithm
- directory_manipulation
- container_cpu_time
- storage_zfs_use_refquota
- storage_lvm_mount_options
- network
- profile_usedby
- container_push
- container_exec_recording
- certificate_update
- container_exec_signal_handling
- gpu_devices
- container_image_properties
- migration_progress
- id_map
- network_firewall_filtering
- network_routes
- storage
- file_delete
- file_append
- network_dhcp_expiry
- storage_lvm_vg_rename
- storage_lvm_thinpool_rename
- network_vlan
- image_create_aliases
- container_stateless_copy
- container_only_migration
- storage_zfs_clone_copy
- unix_device_rename
- storage_lvm_use_thinpool
- storage_rsync_bwlimit
- network_vxlan_interface
- storage_btrfs_mount_options
- entity_description
- image_force_refresh
- storage_lvm_lv_resizing
- id_map_base
- file_symlinks
- container_push_target
- network_vlan_physical
- storage_images_delete
- container_edit_metadata
- container_snapshot_stateful_migration
- storage_driver_ceph
- storage_ceph_user_name
- resource_limits
- storage_volatile_initial_source
- storage_ceph_force_osd_reuse
- storage_block_filesystem_btrfs
- resources
- kernel_limits
- storage_api_volume_rename
- macaroon_authentication
- network_sriov
- console
- restrict_devlxd
- migration_pre_copy
- infiniband
- maas_network
- devlxd_events
- proxy
- network_dhcp_gateway
- file_get_symlink
- network_leases
- unix_device_hotplug
- storage_api_local_volume_handling
- operation_description
- clustering
- event_lifecycle
- storage_api_remote_volume_handling
- nvidia_runtime
- container_mount_propagation
- container_backup
- devlxd_images
- container_local_cross_pool_handling
- proxy_unix
- proxy_udp
- clustering_join
- proxy_tcp_udp_multi_port_handling
- network_state
- proxy_unix_dac_properties
- container_protection_delete
- unix_priv_drop
- pprof_http
- proxy_haproxy_protocol
- network_hwaddr
- proxy_nat
- network_nat_order
- container_full
- candid_authentication
- backup_compression
- candid_config
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
- tls
environment:
  addresses:
  - <IP_ADDRESS>:8443
  - <IP_ADDRESS>:8443
  architectures:
  - x86_64
  - i686
  certificate: |
    -----BEGIN CERTIFICATE-----
    MIIFVjCCAz6gAwIBAgIRALjTNSGkC8LBVbjd44xV3kAwDQYJKoZIhvcNAQELBQAw
    OzEcMBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEbMBkGA1UEAwwScm9vdEBs
    eGQtMy1pbnN0YWxsMB4XDTE4MDkyNDIxMzIwN1oXDTI4MDkyMTIxMzIwN1owOzEc
    MBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEbMBkGA1UEAwwScm9vdEBseGQt
    My1pbnN0YWxsMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA0LmOFzZY
    nazSt2I+YvlOIYkNoWX+Ajq5g0SZslmOIZA07bVyQwrGY1Q3esHxN3ZzQGyr2UHb
    LgjDJWlgXSyEkbYVWtN+xuNKKRilBnQFHrs350OcC7JaYvrEJVJ7ByPR8IZogofH
    DLwIDkaRML01z2zAZd0rmnwW92lUuLhlsjrxEiJ4c6+pXENL++eqXjOXVIZSYp1X
    TZi/lR2Ghk9SYF0pUGCSH3a6OSGB1PLCmfHkNVv5mZvbjQDGirD7yt3I1tzdVOCa
    bquHJGYuPfxBqGsuA7RnER64jgVT2jw6zxd/jusabFbo7xi2X3Kc2+1FNB8kQK7e
    96AThM1u7Ptu0gvAlcGTER5oMcAl72X5ySn3lSCG6qdtBtzicBNp7G0YCbTGcCGR
    tOOj0gdP4sxE5PJ5xSOq6EL9bEZIRwkJpQ7xlscTyKBBjPBdPxwLc4rXwPyuGM6E
    P0jcM/oxU5mQsBrazjDYq8RQmH0SGVraLiaB9BTL/W6w3bCXWlJdMUPhpjmCTOgN
    L+Z+pACHIO+sriQB74mKGtBmsuQumOpS67C3jDEKYON7JUh6Y/Ap4cJDMqcUtdBO
    Q6DpV3vfteoy3Ts6q47er2YUDrjgdUctu8Wiu29HWRuvyOg+UGtPKw1IIo5b2DgD
    FKM/+XTpC/phfFMTvkymEos2B5UuW/vWLs0CAwEAAaNVMFMwDgYDVR0PAQH/BAQD
    AgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHgYDVR0RBBcw
    FYINbHhkLTMtaW5zdGFsbIcECoAAFDANBgkqhkiG9w0BAQsFAAOCAgEAm8X8o28Y
    7MTePDw5LLQC9rcHB+4cn+LK02FzLXpKCVRpdidphRBBHuLDUJ5lMfGvDmg0I+MY
    XvXYFF1SK/HpEALTXkikxm4GOu9KCNm8h6k6QRPgX3vUqFVb6IkjYfOzEWWxz1l4
    RmWAspynPQSU8nlI2dYL52J8OHckZWOqOG7LKNkeApQWn/VQCgbyVHD8pZR6l79H
    He6tJlzaAtNFBRTlit0Xz83P/9P+q1BFEJwSBMqnvYKNZEpelnCMl+EUekg88OH+
    Xz9qyGAlURrRM5FRdeuMADOViQYv8Ky6fgO3zngTuMMUsi9RrnIXtBA2b+O9rF15
    ckShleHkdCg+Gn3f8iG7ruUAyaCkKFEm6PdI6Z8lgyG1N1gIhciX8eu32Mb8+Cl5
    rkqhfPSsY3oMjyGufABVueCjYpsdQYyaG05AfU5kmiPgyv4tQpXZuicbfwvN5Pkm
    E1Ar2eD0AIIiEv1RN/OK46jNbePkvvOyzN8wkt4nBJMZrJQDQ/9s8/216lINKv9C
    WPpHpIkibEGzV30Z362pHYZhsinrLjQsDjE45SF18aJtSlP95AlM6x141B5sttjN
    gVKhWewl2uHmJg/Eto8PKjPBwmpNWJbj9AWRkj0H8k5cUW4iS94UPW1+mEEu2TKv
    88TkLly3tpZcm3qPOM+y+8ZRcV8fX7ngx3w=
    -----END CERTIFICATE-----
  certificate_fingerprint: <redacted>
  driver: lxc
  driver_version: 3.0.2
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.15.0-1019-gcp
  server: lxd
  server_pid: 1120
  server_version: "3.5"
  storage: zfs
  storage_version: 0.7.5-1ubuntu16.3
  server_clustered: false
  server_name: container-images-1

Issue description
I have a sequence of basic commands I am trying to execute against the container using the Hyperkit Ruby library (until we upgrade to pylxd...). These commands are very simple (creating a directory, unzipping a file, etc) and work in our current cluster running LXD 2.16, however, on LXD 3.5 I am seeing:
metadata:
  context: {}
  level: eror
  message: 'Failed to retrieve PID of executing child process: EOF'
timestamp: "2018-09-24T21:56:19.394912046Z"
type: logging

in the monitor logs (note that this example's timestamp is off from the below examples as it was taken from a different run, but the error message is the same every time).
This seems to happen reliably but unpredictably, about 20% of the time.
Steps to reproduce
This would be a pretty complex reproduction case. I could attempt to do with curl if necessary. The steps that are being followed though are:

Create a container
Submit a request to the exec endpoint
Use the operations endpoint to check if the operation is completed
API returns a 400 and log generates the above

Information to attach

[x] Any relevant kernel output (dmesg)

This is all that's generated during the interations with the container:
[ 1459.708758] audit: type=1400 audit(1537827138.902:76): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxd-development-52bc90662885bbee-1537827135520_</var/snap/lxd/common/lxd>" pid=23075 comm="apparmor_parser"
[ 1459.721485] lxdbr0: port 12(veth741ACH) entered blocking state
[ 1459.721487] lxdbr0: port 12(veth741ACH) entered disabled state
[ 1459.721600] device veth741ACH entered promiscuous mode
[ 1459.721702] IPv6: ADDRCONF(NETDEV_UP): veth741ACH: link is not ready
[ 1459.721716] lxdbr0: port 12(veth741ACH) entered blocking state
[ 1459.721718] lxdbr0: port 12(veth741ACH) entered forwarding state
[ 1459.723542] lxdbr0: port 12(veth741ACH) entered disabled state
[ 1459.804872] eth0: renamed from vethSNSK6O
[ 1459.827466] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1459.828503] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1459.828556] IPv6: ADDRCONF(NETDEV_CHANGE): veth741ACH: link becomes ready
[ 1459.828621] lxdbr0: port 12(veth741ACH) entered blocking state
[ 1459.828623] lxdbr0: port 12(veth741ACH) entered forwarding state
[ 1459.890658] audit: type=1400 audit(1537827139.082:77): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-development-52bc90662885bbee-1537827135520_</var/snap/lxd/common/lxd>" name="/sys/fs/cgroup/unified/" pid=23080 comm="systemd" fstype="cgroup2" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
[ 1459.890664] audit: type=1400 audit(1537827139.082:78): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-development-52bc90662885bbee-1537827135520_</var/snap/lxd/common/lxd>" name="/sys/fs/cgroup/unified/" pid=23080 comm="systemd" fstype="cgroup2" srcname="cgroup" flags="rw, nosuid, nodev, noexec"
[ 1460.038252] audit: type=1400 audit(1537827139.230:79): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-development-52bc90662885bbee-1537827135520_</var/snap/lxd/common/lxd>" name="/run/systemd/unit-root/run/lock/" pid=23234 comm="(networkd)" flags="ro, nosuid, nodev, noexec, remount, bind"

[x] Container log (lxc info NAME --show-log)

Note the last line:
Name: development-52bc90662885bbee-1537827135520
Remote: unix://
Architecture: x86_64
Created: 2018/09/24 22:12 UTC
Status: Running
Type: persistent
Profiles: default
Pid: 23080
Ips:
  eth0: inet    <IP_ADDRESS>      veth741ACH
  eth0: inet6   fe80::216:3eff:fe84:9013        veth741ACH
  lo:   inet    <IP_ADDRESS>
  lo:   inet6   ::1
Resources:
  Processes: 14
  Disk usage:
    root: 5.59MB
  CPU usage:
    CPU usage (in seconds): 0
  Memory usage:
    Memory (current): 45.51MB
    Memory (peak): 47.81MB
  Network usage:
    eth0:
      Bytes received: 2.60kB
      Bytes sent: 1.95kB
      Packets received: 24
      Packets sent: 14
    lo:
      Bytes received: 0B
      Bytes sent: 0B
      Packets received: 0
      Packets sent: 0

Log:

lxc development-52bc90662885bbee-1537827135520<PHONE_NUMBER>1218.921 WARN     conf - conf.c:lxc_map_ids:2917 - newuidmap binary is missing
lxc development-52bc90662885bbee-1537827135520<PHONE_NUMBER>1218.921 WARN     conf - conf.c:lxc_map_ids:2923 - newgidmap binary is missing
lxc development-52bc90662885bbee-1537827135520<PHONE_NUMBER>1218.982 WARN     conf - conf.c:lxc_map_ids:2917 - newuidmap binary is missing
lxc development-52bc90662885bbee-1537827135520<PHONE_NUMBER>1218.982 WARN     conf - conf.c:lxc_map_ids:2923 - newgidmap binary is missing
lxc development-52bc90662885bbee-1537827135520<PHONE_NUMBER>1219.729 WARN     conf - conf.c:lxc_setup_devpts:1618 - Invalid argument - Failed to unmount old devpts instance

[x] Container configuration (lxc config show NAME --expanded)

architecture: x86_64
config:
  image.architecture: amd64
  image.description: Ubuntu bionic amd64 (20180924_07:42)
  image.os: Ubuntu
  image.release: bionic
  image.serial: "20180924_07:42"
  volatile.base_image: 76c593807c13d36048f15390a17eb4dff8f0fef7e4eef9bdff83670570ff4afd
  volatile.eth0.hwaddr: 00:16:3e:84:90:13
  volatile.eth0.name: eth0
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.power: RUNNING
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

[x] Main daemon log (at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log)

action=start created=2018-09-24T22:12:15+0000 ephemeral=false lvl=info msg="Starting container" name=development-52bc90662885bbee-1537827135520 stateful=false t=2018-09-24T22:12:18+0000 used=1970-01-01T00:00:00+0000
action=start created=2018-09-24T22:12:15+0000 ephemeral=false lvl=info msg="Started container" name=development-52bc90662885bbee-1537827135520 stateful=false t=2018-09-24T22:12:19+0000 used=1970-01-01T00:00:00+0000
lvl=eror msg="Failed to retrieve PID of executing child process: EOF" t=2018-09-24T22:12:26+0000

[ ] Output of the client with --debug

Run from Hyperkit, so all I get is a 400 error.

[x] Output of the daemon with --debug (alternatively output of lxc monitor while reproducing the issue)

Same as above, here again for reference:
metadata:
  context: {}
  level: eror
  message: 'Failed to retrieve PID of executing child process: EOF'
timestamp: "2018-09-24T21:56:19.394912046Z"
type: logging

Can you show the entire lxc monitor output from the moment you start the lxc exec to the point where it's done?

@stgraber thanks for the insanely fast response.

Also it looks like for this one I am waiting for the command to finish (not polling the operations endpoint). I've seen the same behavior with both approaches.

root@container-images-1:~# cat /var/snap/lxd/common/lxd/logs/development-67858a0ce947e6a1-1537828807730/forkexec.log

runtime stack:
runtime.throw(0x11259a6, 0x17)
        /build/lxd/parts/go/build/src/runtime/panic.go:608 +0x72
runtime.netpoll(0x32202a49300, 0xdf8475800)
        /build/lxd/parts/go/build/src/runtime/netpoll_epoll.go:75 +0x215
runtime.sysmon()
        /build/lxd/parts/go/build/src/runtime/proc.go:4390 +0x41b
runtime.mstart1()
        /build/lxd/parts/go/build/src/runtime/proc.go:1282 +0xe6
runtime.mstart()
        /build/lxd/parts/go/build/src/runtime/proc.go:1248 +0x6e

goroutine 1 [runnable]:
gopkg.in/lxc/go-lxc%2ev2._Cfunc_setArrayString(0x28cecb0, 0x28ae7d0, 0x0)
        _cgo_gotypes.go:1228 +0x45
gopkg.in/lxc/go-lxc%2ev2.makeNullTerminatedArgs.func1(0x28cecb0, 0x28ae7d0, 0x0)
        /build/lxd/parts/lxd/go/src/gopkg.in/lxc/go-lxc.v2/util.go:61 +0x6a
gopkg.in/lxc/go-lxc%2ev2.makeNullTerminatedArgs(0xc0002ca040, 0x3, 0x4, 0x0)
        /build/lxd/parts/lxd/go/src/gopkg.in/lxc/go-lxc.v2/util.go:61 +0x91
gopkg.in/lxc/go-lxc%2ev2.(*Container).RunCommandNoWait(0xc00025fad0, 0xc0002ca040, 0x3, 0x4, 0xffffffffffffffff, 0xffffffffffffffff, 0x7ffc8c2498fb, 0x5, 0xffffffffffffffff, 0xffffffffffffffff, ...)
        /build/lxd/parts/lxd/go/src/gopkg.in/lxc/go-lxc.v2/container.go:1322 +0xef
main.(*cmdForkexec).Run(0xc0000c26d0, 0xc0002bc000, 0xc0002c20e0, 0xd, 0xe, 0x0, 0x0)
        /build/lxd/parts/lxd/go/src/github.com/lxc/lxd/lxd/main_forkexec.go:124 +0x558
main.(*cmdForkexec).Run-fm(0xc0002bc000, 0xc0002c20e0, 0xd, 0xe, 0x0, 0x0)
        /build/lxd/parts/lxd/go/src/github.com/lxc/lxd/lxd/main_forkexec.go:31 +0x52
github.com/spf13/cobra.(*Command).execute(0xc0002bc000, 0xc0002c2000, 0xe, 0xe, 0xc0002bc000, 0xc0002c2000)
        /build/lxd/parts/lxd/go/src/github.com/spf13/cobra/command.go:762 +0x473
github.com/spf13/cobra.(*Command).ExecuteC(0xc00029b180, 0x1145de7, 0x0, 0xc0002bf900)
        /build/lxd/parts/lxd/go/src/github.com/spf13/cobra/command.go:852 +0x2fd
github.com/spf13/cobra.(*Command).Execute(0xc00029b180, 0xc0002abec8, 0x1)
        /build/lxd/parts/lxd/go/src/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
        /build/lxd/parts/lxd/go/src/github.com/lxc/lxd/lxd/main.go:164 +0xe13

goroutine 19 [syscall]:
os/signal.signal_recv(0x0)
        /build/lxd/parts/go/build/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
        /build/lxd/parts/go/build/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
        /build/lxd/parts/go/build/src/os/signal/signal_unix.go:29 +0x41

Can you show snap info lxd?

root@container-images-1:~# snap info lxd
name:      lxd
summary:   System container manager and API
publisher: Canonical✓
contact:   https://github.com/lxc/lxd/issues
license:   unset
description: |
  LXD is a container manager for system containers.

  It offers a REST API to remotely manage containers over the network, using an image based workflow
  and with support for live migration.

  Images are available for all Ubuntu releases and architectures as well as for a wide number of
  other Linux distributions.

  LXD containers are lightweight, secure by default and a great alternative to virtual machines.
commands:
  - lxd.benchmark
  - lxd.buginfo
  - lxd.check-kernel
  - lxd.lxc
  - lxd
  - lxd.migrate
services:
  lxd.daemon: simple, enabled, active
snap-id:      J60k4JY0HppjwOjW8dZdYc8obXKxujRu
tracking:     stable
refresh-date: today at 21:32 UTC
channels:
  stable:        3.5         (8774) 66MB -
  candidate:     3.5         (8774) 66MB -
  beta:          ↑
  edge:          git-efc73da (8791) 66MB -
  3.0/stable:    3.0.2       (8715) 65MB -
  3.0/candidate: 3.0.2       (8715) 65MB -
  3.0/beta:      ↑
  3.0/edge:      git-1722ea8 (8801) 65MB -
  2.0/stable:    2.0.11      (8023) 28MB -
  2.0/candidate: 2.0.11      (8023) 28MB -
  2.0/beta:      ↑
  2.0/edge:      git-92a4fdc (8000) 26MB -
installed:       3.5         (8774) 66MB -

Ok, can you give me the exact query being sent to LXD?
Looks like a problem with the command or arguments being parsed inside go-lxc.

I know Hyperkit isn't officially supported, but a request to the LXD API is being made here:
https://github.com/jeffshantz/hyperkit/blob/master/lib/hyperkit/client/containers.rb#L315
We're not using any of the option params (except occasionally sync, as mentioned).
The Ruby object we're passing in is an array, a la ['mkdir', '-p', '/src/codevolve'].
Let me know if this isn't enough and I can try to extract it some other way.

@brauner if still lurking around, maybe you'll spot something obviously bad in the go-lxc code ^

@saulcosta I'll see if I can reproduce it on a system here

@saulcosta no luck so far, so if you can reproduce it with curl or lxc query, that'd be great

Alternatively I can give you a custom LXD binary you can sideload on your system and that'd hopefully record more stuff.

@stgraber I'm able to with:
root@container-images-1:~# lxc launch ubuntu:
Creating the container
Container name is: integral-arachnid
Starting integral-arachnid
root@container-images-1:~# lxc query -X POST /1.0/containers/integral-arachnid/exec -d '{ "command": ["echo", "foo"] }' --wait
{
        "class": "task",
        "created_at": "2018-09-24T23:17:47.223217865Z",
        "description": "Executing command",
        "err": "",
        "id": "855112be-c233-405c-8868-f030ae397848",
        "may_cancel": false,
        "metadata": {
                "return": 0
        },
        "resources": {
                "containers": [
                        "/1.0/containers/integral-arachnid"
                ]
        },
        "status": "Success",
        "status_code": 200,
        "updated_at": "2018-09-24T23:17:47.28828152Z"
}
root@container-images-1:~# lxc query -X POST /1.0/containers/integral-arachnid/exec -d '{ "command": ["echo", "foo"] }' --wait
{
        "class": "task",
        "created_at": "2018-09-24T23:17:51.775155133Z",
        "description": "Executing command",
        "err": "",
        "id": "90a1073d-fda5-42fa-9a92-63b22efb32f8",
        "may_cancel": false,
        "metadata": {
                "return": 0
        },
        "resources": {
                "containers": [
                        "/1.0/containers/integral-arachnid"
                ]
        },
        "status": "Success",
        "status_code": 200,
        "updated_at": "2018-09-24T23:17:51.831319275Z"
}
root@container-images-1:~# lxc query -X POST /1.0/containers/integral-arachnid/exec -d '{ "command": ["echo", "foo"] }' --wait
Error: EOF

Note that it took a few times, this is consistent with what I've seen thus far.

This looks like a 9 size parameter is passed to calloc in makeCharArray and then 0 is used as index into the unallocated array

The calloc fix from @brauner in go-lxc fixed one of the issues in this codepath, but I'm unfortunately still seeing very frequent crashes, they now look like:
root@lantea:~# lxc query -X POST /1.0/containers/c1/exec -d '{ "command": ["echo", "foo"]}' --wait
Error: EOF
root@lantea:~# cat /var/snap/lxd/common/lxd/logs/c1/forkexec.log

runtime stack:
runtime.throw(0x10ddfdf, 0x17)
	/usr/lib/go-1.10/src/runtime/panic.go:616 +0x81
runtime.netpoll(0x6f7dbab3f00, 0xdf8475800)
	/usr/lib/go-1.10/src/runtime/netpoll_epoll.go:75 +0x216
runtime.sysmon()
	/usr/lib/go-1.10/src/runtime/proc.go:4265 +0x424
runtime.mstart1(0x0)
	/usr/lib/go-1.10/src/runtime/proc.go:1227 +0xe7
runtime.mstart()
	/usr/lib/go-1.10/src/runtime/proc.go:1193 +0x76

goroutine 1 [runnable]:
gopkg.in/lxc/go-lxc%2ev2._cgo_cmalloc(0x6, 0x33b6f20)
	_cgo_gotypes.go:1246 +0x4a
gopkg.in/lxc/go-lxc%2ev2._Cfunc_CString(0x7fff6077f8ff, 0x5, 0x33b6e50)
	_cgo_gotypes.go:223 +0x33
gopkg.in/lxc/go-lxc%2ev2.(*Container).RunCommandNoWait(0xc4202cf380, 0xc4203080a0, 0x2, 0x2, 0xffffffffffffffff, 0xffffffffffffffff, 0x7fff6077f8ff, 0x5, 0xffffffffffffffff, 0xffffffffffffffff, ...)
	/home/stgraber/data/code/go/src/gopkg.in/lxc/go-lxc.v2/container.go:1340 +0x232
main.(*cmdForkexec).Run(0xc4201cc1d8, 0xc4202f7400, 0xc4202192b0, 0xc, 0xd, 0x0, 0x0)
	/home/stgraber/data/code/go/src/github.com/lxc/lxd/lxd/main_forkexec.go:124 +0x963
main.(*cmdForkexec).Run-fm(0xc4202f7400, 0xc4202192b0, 0xc, 0xd, 0x0, 0x0)
	/home/stgraber/data/code/go/src/github.com/lxc/lxd/lxd/main_forkexec.go:31 +0x52
github.com/spf13/cobra.(*Command).execute(0xc4202f7400, 0xc420219040, 0xd, 0xd, 0xc4202f7400, 0xc420219040)
	/home/stgraber/data/code/go/src/github.com/spf13/cobra/command.go:762 +0x468
github.com/spf13/cobra.(*Command).ExecuteC(0xc4202f6780, 0x0, 0xc420304f00, 0xc420304f00)
	/home/stgraber/data/code/go/src/github.com/spf13/cobra/command.go:852 +0x30a
github.com/spf13/cobra.(*Command).Execute(0xc4202f6780, 0xc4202f1e00, 0x1)
	/home/stgraber/data/code/go/src/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
	/home/stgraber/data/code/go/src/github.com/lxc/lxd/lxd/main.go:164 +0xea3

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
	/usr/lib/go-1.10/src/runtime/sigqueue.go:139 +0xa6
os/signal.loop()
	/usr/lib/go-1.10/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.0
	/usr/lib/go-1.10/src/os/signal/signal_unix.go:28 +0x41

@stgraber @brauner thanks for handling this so quickly. Presumably I'll need to either build from source or wait for the next bugfix release to get access to this?

I plan on cherry-picking this fix later this week, so you should just get a new snap build soon with a fix.


package installing error

Hello can i run this bot on kali linux because xlib and scort are not located

Hello,
Which version of kali linux are you using?
Also, what do you get when you execute the following command?
sudo apt install python3-xlib scrot


m.request doesn't handle empty body

Returning an empty body to a json request (in rails that means doing something like head 200), m.request tries to parse the response and makes a JSON error:
Uncaught SyntaxError: Unexpected end of input

Obviously there could be a debate about whether or not you should ever get into this situation by not returning a JSON body, but I think this is something that m.request should handle correctly -- at least not throw an error.
I'll contribute this at some point when I get a chance but if someone beats me to it, awesome.

You could create your own extract() or unwrap() to check for empty response, and react accordingly.

I'd extend @Naddiseo's suggestion with 'should' rather than 'could'. m.request expects JSON and as such will break on content that isn't valid JSON.
The relevant documentation for non-JSON data formats is here

I still strongly feel that no library that expects JSON should throw an error if an empty response is given. However in the interest of making it easy to use mithril with other non-JSON apis, I just added a line to my custom extractor like @Naddiseo suggested.


Week 18 - Luke Riggins

College Board Corrections

Make Create and Read API endpoints for your project
Build a Frontend for Create and Read endpoints

I tried learning and figuring this out by using the template in the flask portfolio and trying to replace variables to make it make sense for my project which would have the information of An NBA player, the team he plays for, and the Stats that he has. The issue that I had with this was that it flat out would crash and say server error every time I thought I did it correctly. In postman, when I put the link for the local server in when I tried to send it through it just flat out did not work. During this class period, I am still trying to figure it out. I spent 4 hours on discord with Ben on it and we were clueless. It was late so Arnav had already gone to sleep. With his help, we are trying to figure it out right now.  Postman was hard to use and I was using videos to try and figure it out and none helped at all. Another error that occurred would be that the information that I changed would not show up on the local server.

.5 API
.5 DB
.9 CPT


Integrate cuDNN frontend v1 to fused attention

This PR:

[C/PyTorch] integrates cuDNN frontend v1 to fused attention,
[C/PyTorch] adds support for padding, padding_causal masks, post_scale_bias, alibi biases, and MQA/GQA to fused attention,
[C/PyTorch] widens support for _qkvpacked APIs to h3d/3hd from qkv_interleaved, and support for _kvpacked APIs to hd_h2d/hd_2hd from kv_interleaved,
[C/PyTorch] removes all usage of 'qkv_interleaved', 'kv_interleaved', 'not_interleaved' enums,
[PyTorch] fixes FlashAttention module for padding_causal mask,
[PyTorch] fixes fwd output shape for thd format in FlashAttention,
[PyTorch] adds alibi support for UnfusedDPA,
[C] changes the backend selection from prioritizing max512 to arbitrary_seqlen backend,
[C] disables padding_causal mask for cross attention for max512 backend due to bugs,
[Pytorch] makes stats_lse contiguous for future context parallel implementations,
[Pytorch] completely rewrites unit tests in test_fused_attn.py for better coverage and efficiency.

/te-ci

/te-ci

/te-ci

/te-ci

/te-ci

/te-ci pytorch

/te-ci

/te-ci jax

/te-ci paddle

/te-ci

/te-ci

Pipeline 11107364 with a newer cudnn.

Pipeline 11182007

/te-ci

Pipeline 11196472 with newer builds of cuDNN.

/te-ci jax

/te-ci jax

Pipeline 11267171

Pipeline 11267171 is green. The last 5 commits are mostly to fix L1 tests, with 95d0820 an exception. It reduces the amount of prints when training.


Implement rule-based response system

Added a simple rule engine for more control over response generation.
Enhanced logging to track the source of generated responses.

Closes #2


Update Bindings: v2.0.2

Update bindings to v2.0.2
API version v1.236.5

I reckon the generic names for cursor-based pagination responses weren't picked up during the TF provider work simply because our TF provider doesn't use them... Will try to look at this.

@Leeoc  I think all of the previous comments have been addressed. Our only issue currently is that the package dependencies endpoint response's operator property contains symbols which the java generator in this version of swagger-codegen doesn't know how to generate valid enum members for. Investigating.


Member expiration backend

What does this PR do and why?
Fixes #230.

Added a new expires_at column in the `members table.
Created a new scope not_expired for members.
Updated policies to only retrieve non-expired members.

Screenshots or screen recordings
N/A
How to set up and validate locally
There are a couple ways to test:

Call the new scope via console
Member.for_namespace_and_ancestors(@group).not_expired or Member.for_namespace_and_ancestors(@project.namespace).not_expired and verify the members.
Even though this is not the fronted PR, you can log in as the user with an expired membership to make sure groups and projects are not displayed. Some areas to check are:

the groups/projects dashboards
transferring groups/projects drop-down list

PR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

[x] I have evaluated the PR acceptance checklist for this PR.

Waiting for #319 to merge, so I can continue to update policies with the not_expired scope.

This PR doesn't need to be on hold right now. We can still update the linked_groups query in the group_policy -> relation scope. The project_policy relation scope also needs to be updated check if the user has a membership which isn't expired (direct_projects, group_projects, and linked_projects queries)


Introduce the ability to remove metrics

Once metricsd has been started, it logs any and all metrics that have been sent to it.  Sometimes this is annoying, like when you're testing and generate metrics with the wrong name.  Deleting them from the filesystem doesn't work, as metricsd will keep flushing the last values sent.

Fixed in 72ae785b674c3344993f436f4e0919fc1b3770f8.


kismet:missing kismet_capture binary

Issue description
the package kismet is included,but the kismet_capture binary is not included
It should also be setuid
Steps to reproduce

Install kismet
Run kismet on the command line

Technical details

System: 18.03pre118381.4068703502 (Impala)
Nix version:nix-env (Nix) 1.12pre5663_c7af84ce
Nixpkgs version:18.03pre118381.4068703502
Sandboxing enabled: yes

Should kismet be a NixOS module as well?

Otherwise it appears you have to run kismet under root.


oracle 9.3 deploy

hey, you have done amazing work here.  generally speaking was easy to setup once I figured out the proxmox token part.
I did run into an issue though. Any idea where the issue might be?
==> proxmox-iso.linux: Uploading /home/packer/proxmox-kvm-packer/extra/files/cloud-init/rhel/generic/cloud.cfg => /etc/cloud/cloud.cfg
proxmox-iso.linux: cloud.cfg 2.68 KiB / 2.68 KiB [======================================] 100.00% 0s
==> proxmox-iso.linux: Provisioning with shell script: /tmp/packer-shell3547237650
==> proxmox-iso.linux: Unit /usr/lib/systemd/system/qemu-guest-agent.service is added as a dependency to a non-existent unit dev-virtio\x2dports-org.qemu.guest_agent.0.device.
==> proxmox-iso.linux: Provisioning with Ansible...
proxmox-iso.linux: Setting up proxy adapter for Ansible....
==> proxmox-iso.linux: Executing Ansible: ansible-playbook -e packer_build_name="linux" -e packer_builder_type=proxmox-iso -e packer_http_addr=<IP_ADDRESS>:8378 --ssh-extra-args '-o IdentitiesOnly=yes' -e @extra/playbooks/provision_oracle9_variables.yml -e @variables/oraclelinux9.yml -v -e ansible_ssh_private_key_file=/tmp/ansible-key1881435401 -i /tmp/packer-provisioner-ansible1614403870 /home/packer/proxmox-kvm-packer/extra/playbooks/provision_rhel.yaml
proxmox-iso.linux: Using /etc/ansible/ansible.cfg as config file
proxmox-iso.linux:
proxmox-iso.linux: PLAY [prepare_rhel_machine] ****************************************************
proxmox-iso.linux:
proxmox-iso.linux: TASK [verify_ansible_meets_version_requirements] *******************************
proxmox-iso.linux: ok: [default] => {
proxmox-iso.linux:     "changed": false,
proxmox-iso.linux:     "msg": "All assertions passed"
proxmox-iso.linux: }
proxmox-iso.linux:
proxmox-iso.linux: TASK [run_initial_setup_instead_of_gather_facts] *******************************
proxmox-iso.linux: fatal: [default]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via scp: bash: line 1: /usr/lib/sftp-server: No such file or directory\nConnection closed\r\n", "unreachable": true}
proxmox-iso.linux:
proxmox-iso.linux: PLAY RECAP *********************************************************************
proxmox-iso.linux: default                    : ok=1    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0
proxmox-iso.linux:
==> proxmox-iso.linux: Provisioning step had errors: Running the cleanup provisioner, if present...
==> proxmox-iso.linux: Stopping VM
==> proxmox-iso.linux: Deleting VM
Build 'proxmox-iso.linux' errored after 6 minutes 3 seconds: Error executing Ansible: Non-zero exit status: exit status 4
Thanks!

Hi @VorlMaldor
That seems to be related on your OS and ansible/packer interaction.
Try adding the following to the ansible/ansible.cfg file as noted in the README for another tested OS.:

[ssh_connection]
scp_extra_args = "-O"

I must be missing something. I don't see that anywhere in the readme in thre repo. Is there another readme, or another document somewhere I should be following?
Also, is there supposed to be an ansible/ansible.cfg in this repo?

No that's from Packer's. Simply (my guess) your operating system is Fedora/RHEL based, and for this ansible requires an extra option.
This is OS setting
https://github.com/hashicorp/packer-plugin-ansible/issues/110

sorry, I am not trying to be dense. where would I put that in your setup, or how would I add it to extra args. I am fairly new to both ansible and packer.

No worries.
Look for /etc/ansible/ansible.conf and put it there
[ssh_connection]
scp_extra_args = "-O"

PS. Dense? ;)

sorry, dense is american slang for being mentally slow.
Thank you very much for all the help!

Please try this branch: https://github.com/marcinbojko/proxmox-kvm-packer/tree/develop

ok, I tried the new branch without and with editing the ssh_connection in /etc/ansible/ansible.cfg and received the same errors. if you need the whole log let me know.
proxmox-iso.linux:
proxmox-iso.linux: TASK [initial_clean] ***********************************************************
proxmox-iso.linux: ok: [default] => {
proxmox-iso.linux:     "msg": "Starting provision"
proxmox-iso.linux: }
proxmox-iso.linux:
proxmox-iso.linux: TASK [install_initial_packages] ************************************************
proxmox-iso.linux: FAILED - RETRYING: [default]: install_initial_packages (2 retries left).
proxmox-iso.linux: FAILED - RETRYING: [default]: install_initial_packages (1 retries left).
proxmox-iso.linux: failed: [default] (item=oracle-release-el9) => {"ansible_loop_var": "item", "attempts": 2, "changed": false, "failures": ["No package oracle-release-el9 available."], "item": "oracle-release-el9", "msg": "Failed to install some of the specified packages", "rc": 1, "results": []}
proxmox-iso.linux: changed: [default] => (item=curl) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "curl", "msg": "", "rc": 0, "results": ["Installed: curl-7.76.1-26.el9_3.3.x86_64", "Installed: libcurl-7.76.1-26.el9_3.3.x86_64", "Removed: libcurl-7.76.1-26.el9.x86_64", "Removed: curl-7.76.1-26.el9.x86_64"]}
proxmox-iso.linux: ok: [default] => (item=mc) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "mc", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=wget) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "wget", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=tar) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "tar", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=bzip2) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "bzip2", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: changed: [default] => (item=kernel-devel) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "kernel-devel", "msg": "", "rc": 0, "results": ["Installed: kernel-devel-5.14.0-362.18.1.el9_3.x86_64"]}
proxmox-iso.linux: changed: [default] => (item=kernel-headers) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "kernel-headers", "msg": "", "rc": 0, "results": ["Installed: kernel-headers-5.14.0-362.18.1.el9_3.x86_64", "Removed: kernel-headers-5.14.0-362.8.1.el9_3.x86_64"]}
proxmox-iso.linux: ok: [default] => (item=perl) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "perl", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=gcc) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "gcc", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=make) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "make", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=elfutils-libelf-devel) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "elfutils-libelf-devel", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: ok: [default] => (item=langpacks-en) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "langpacks-en", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: changed: [default] => (item=glibc-all-langpacks) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "glibc-all-langpacks", "msg": "", "rc": 0, "results": ["Installed: glibc-2.34-83.0.2.el9_3.7.x86_64", "Installed: glibc-devel-2.34-83.0.2.el9_3.7.x86_64", "Installed: glibc-gconv-extra-2.34-83.0.2.el9_3.7.x86_64", "Installed: glibc-all-langpacks-2.34-83.0.2.el9_3.7.x86_64", "Installed: glibc-common-2.34-83.0.2.el9_3.7.x86_64", "Installed: glibc-langpack-en-2.34-83.0.2.el9_3.7.x86_64", "Installed: glibc-headers-2.34-83.0.2.el9_3.7.x86_64", "Removed: glibc-2.34-83.0.1.el9_3.7.x86_64", "Removed: glibc-all-langpacks-2.34-83.0.1.el9_3.7.x86_64", "Removed: glibc-common-2.34-83.0.1.el9_3.7.x86_64", "Removed: glibc-devel-2.34-83.0.1.el9_3.7.x86_64", "Removed: glibc-gconv-extra-2.34-83.0.1.el9_3.7.x86_64", "Removed: glibc-headers-2.34-83.0.1.el9_3.7.x86_64", "Removed: glibc-langpack-en-2.34-83.0.1.el9_3.7.x86_64"]}
proxmox-iso.linux: ok: [default] => (item=ca-certificates) => {"ansible_loop_var": "item", "attempts": 1, "changed": false, "item": "ca-certificates", "msg": "Nothing to do", "rc": 0, "results": []}
proxmox-iso.linux: changed: [default] => (item=yum-utils) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "yum-utils", "msg": "", "rc": 0, "results": ["Installed: yum-utils-4.3.0-11.0.1.el9_3.noarch"]}
proxmox-iso.linux: changed: [default] => (item=sendmail) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "sendmail", "msg": "", "rc": 0, "results": ["Installed: sendmail-8.16.1-11.0.1.el9.x86_64", "Installed: procmail-3.22-56.el9.x86_64", "Installed: tinycdb-0.78-18.el9.x86_64", "Installed: cyrus-sasl-2.1.27-21.el9.x86_64"]}
proxmox-iso.linux: changed: [default] => (item=cockpit-pcp) => {"ansible_loop_var": "item", "attempts": 1, "changed": true, "item": "cockpit-pcp", "msg": "", "rc": 0, "results": ["Installed: libuv-1:1.42.0-1.el9.x86_64", "Installed: pcp-conf-6.0.5-4.0.1.el9.x86_64", "Installed: pcp-libs-6.0.5-4.0.1.el9.x86_64", "Installed: libatomic-11.4.1-<IP_ADDRESS>.el9.x86_64", "Installed: libproxy-webkitgtk4-0.4.15-35.el9.x86_64", "Installed: pcp-selinux-6.0.5-4.0.1.el9.x86_64", "Installed: webkit2gtk3-jsc-2.40.5-1.el9_3.1.x86_64", "Installed: json-glib-1.6.6-1.el9.x86_64", "Installed: abattis-cantarell-fonts-0.301-4.el9.noarch", "Installed: cockpit-bridge-300.4-1.0.1.el9_3.x86_64", "Installed: adobe-source-code-pro-fonts-<IP_ADDRESS>-12.el9.1.noarch", "Installed: gsettings-desktop-schemas-40.0-6.el9.x86_64", "Installed: cockpit-pcp-300.4-1.0.1.el9_3.x86_64", "Installed: pcp-6.0.5-4.0.1.el9.x86_64", "Installed: libproxy-0.4.15-35.el9.x86_64", "Installed: glib-networking-2.68.3-3.el9.x86_64"]}
proxmox-iso.linux:
proxmox-iso.linux: NO MORE HOSTS LEFT *************************************************************
proxmox-iso.linux:
proxmox-iso.linux: PLAY RECAP *********************************************************************
proxmox-iso.linux: default                    : ok=6    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
proxmox-iso.linux:
==> proxmox-iso.linux: Provisioning step had errors: Running the cleanup provisioner, if present...
==> proxmox-iso.linux: Stopping VM
==> proxmox-iso.linux: Deleting VM
Build 'proxmox-iso.linux' errored after 7 minutes 12 seconds: Error executing Ansible: Non-zero exit status: exit status 2
==> Wait completed after 7 minutes 12 seconds

This is not the same error. The fix I or you did, was a success - provisioning starts.
It fails, as oracle searches for specific package (I swear, Oracle guys like to complicate things), so there is simply mismatch in package name

this is what I am getting now.
./proxmox_oraclelinux_93.sh
Error: Invalid value for variable
on proxmox/variables_proxmox_oraclelinux93.pkvars.hcl line 10:
10: disks = {
11:     cache_mode            = "writeback"
12:     disk_size             = "50G"
13:     format                = "raw"
14:     type                  = "virtio"
15:     storage_pool          = "vmpool"
16: }
The value for disks is not compatible with the variable's type constraint:
attributes "discard" and "io_thread" are required.
Packer validate failed - exiting now
I did figure out that I wasn't using your devel branch before and fixed that. this is the error in that branch.
I tried to add those entries into the disks section and gave
Error: 1 error(s) occurred:

io thread option requires virtio-scsi-single controller
on proxmox/proxmox_rhel.pkr.hcl line 172:
(source code not available)

Packer validate failed - exiting now
so I removed io_thread and got
Error: Invalid value for variable
on proxmox/variables_proxmox_oraclelinux93.pkvars.hcl line 10:
10: disks = {
11:     cache_mode            = "writeback"
12:     disk_size             = "50G"
13:     format                = "raw"
14:     type                  = "virtio"
15:     storage_pool          = "vmpool"
16:     discard                 = "true"
17: }
The value for disks is not compatible with the variable's type constraint:
attribute "io_thread" is required.
Thank you much for your time and help.

make sure you did steps from the manual: especially refresh packer and packer modules/plugins, and requirements for ansible.
Looks like your Packer plugin version could be too old:
- Init packer by running  `packer init config.pkr.hcl` or `packer init -upgrade config.pkr.hcl`
- Init your ansible by running `ansible-galaxy collection install --upgrade -r ./extra/playbooks/requirements.yml`

good morning, so I was having issues getting oracle 9.3 to update to a current version of ansible. deployed a new system fedora 39 ran the packer init, and ansioble commands and am still getting:
Error: Invalid value for variable
on proxmox/variables_proxmox_oraclelinux93.pkvars.hcl line 10:
10: disks = {
11:     cache_mode            = "writeback"
12:     disk_size             = "50G"
13:     format                = "raw"
14:     type                  = "virtio"
15:     storage_pool          = "vmpool"
16: }
The value for disks is not compatible with the variable's type constraint:
attributes "discard" and "io_thread" are required.
This is the output from the ansible and packer commands:
manager@fedora:~/proxmox-kvm-packer$ packer init config.pkr.hcl
Installed plugin github.com/hashicorp/qemu v1.0.10 in "/home/manager/.config/packer/plugins/github.com/hashicorp/qemu/packer-plugin-qemu_v1.0.10_x5.0_linux_amd64"
Installed plugin github.com/hashicorp/alicloud v1.1.1 in "/home/manager/.config/packer/plugins/github.com/hashicorp/alicloud/packer-plugin-alicloud_v1.1.1_x5.0_linux_amd64"
Installed plugin github.com/hashicorp/proxmox v1.1.7 in "/home/manager/.config/packer/plugins/github.com/hashicorp/proxmox/packer-plugin-proxmox_v1.1.7_x5.0_linux_amd64"
Installed plugin github.com/hashicorp/ansible v1.1.1 in "/home/manager/.config/packer/plugins/github.com/hashicorp/ansible/packer-plugin-ansible_v1.1.1_x5.0_linux_amd64"
Installed plugin github.com/hashicorp/vagrant v1.1.2 in "/home/manager/.config/packer/plugins/github.com/hashicorp/vagrant/packer-plugin-vagrant_v1.1.2_x5.0_linux_amd64"
Installed plugin github.com/rgl/windows-update v0.15.0 in "/home/manager/.config/packer/plugins/github.com/rgl/windows-update/packer-plugin-windows-update_v0.15.0_x5.0_linux_amd64"
manager@fedora:~/proxmox-kvm-packer$ ansible-galaxy collection install --upgrade -r ./extra/playbooks/requirements.yml
Starting galaxy collection install process
Process install dependency map
Starting collection install process
'ansible.posix:1.5.4' is already installed, skipping.
'community.general:8.4.0' is already installed, skipping.
'community.crypto:2.18.0' is already installed, skipping.
manager@fedora:~/proxmox-kvm-packer$ ansible --version
ansible [core 2.16.4]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/manager/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.12/site-packages/ansible
ansible collection location = /home/manager/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/bin/ansible
python version = 3.12.2 (main, Feb 21 2024, 00:00:00) [GCC 13.2.1 20231205 (Red Hat 13.2.1-6)] (/usr/bin/python3)
jinja version = 3.1.3
libyaml = True
manager@fedora:~/proxmox-kvm-packer$ packer --version
Packer v1.10.2
Is there something I am doing wrong?

Are ou on current commit?
Please do and paste
git show | head

from main folder

That fixed it, pulling the new develop branch this morning.  You are supper awesome, thank you for the help!


Performence issus

Hello,
I have fresh install on two servers,
I installed portainer via the official stack
I have multiple issues like blank pages and cluster swarm disconnection

while all other apps are working fine
Technical details:
Portainer run on 2.1.1 on liunux docker swarm via official stack
docker version
master@node1:~$ docker version
Client: Docker Engine - Community
 Version:           20.10.3
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        48d30b5
 Built:             Fri Jan 29 14:33:21 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.3
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       46229ca
  Built:            Fri Jan 29 14:31:32 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Bug caused by ubuntu work on debian 10

None ubuntu issus
i have same problem on fresh debian install


Update for Instant Client 19.9

Simple version update.
@Djelibeybi I'll add an OL8 Dockerfile next week.

Gentle reminder to -S or --signoff your commits. :)

Gentle reminder to -S or --signoff your commits. :)

Ack.


perf: remove ESM loader to speed up CLI execution

Description of changes
Removed ESM loader for NPM CLI installation and update all the packages to be transpiled using
typescript to covert all ES6 import export statements to commonjs

Issue #, if available

Description of how you validated changes
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #9777 (5d72788) into master (f1af5bb) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #9777   +/-   ##
=======================================
  Coverage   53.01%   53.01%
=======================================
  Files         830      830
  Lines       46010    46010
  Branches     9826     9826
=======================================
+ Hits        24390    24391    +1
+ Misses      19602    19601    -1
  Partials     2018     2018

Impacted Files
Coverage Δ

packages/amplify-cli/src/commands/status.ts
40.98% <0.00%> (+1.63%)
:arrow_up:

Continue to review full report at Codecov.

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

With the current changes, a deprecation warning is seen

My attempt at merging the latest changes from master did not work out as I intended. I found it much easier to rebase, but I didn't want to force push to this branch. New PR is here with the same changes (minus the merge commit) rebased: https://github.com/aws-amplify/amplify-cli/pull/9873

Closing this PR since https://github.com/aws-amplify/amplify-cli/pull/9873 is merged


Proudly present: optimize the output of Base.render() and Page.render()

so that it pulls in required js file only. Hence the resulting render.html should be smaller

Codecov Report

Merging #112 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #112      +/-   ##
==========================================
+ Coverage   97.33%   97.35%   +0.01%
==========================================
  Files          56       56
  Lines        1916     1928      +12
==========================================
+ Hits         1865     1877      +12
  Misses         51       51

Impacted Files
Coverage Δ

test/test_page.py
100% <100%> (ø)
:arrow_up:

pyecharts/base.py
80.61% <100%> (+0.19%)
:arrow_up:

pyecharts/custom/page.py
97.77% <100%> (+0.34%)
:arrow_up:

pyecharts/template.py
97.72% <100%> (+0.16%)
:arrow_up:

Continue to review full report at Codecov.

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


Spatial sensitive heatmap

How can i get the spatial sensitive heatmap ?  Just like the bear.

The same question I have, could you tell me the idea that how you draw it?

I have the same question.  Could you tell me the idea you draw it?

@DingShengLin May be you can use CAM to output the spatial sensitive heatmap.

Hi, we obtain the sensitive heatmap depends on the accuracy of the classification and regression of the region proposal in this location. Specifically, given a feature map H in the detector, we can obtain the corresponding region proposals in each coordinate in H and then forward them into the detection head to obtain the classification score and IoU of regression. Take the classification sensitive heatmap for example, we assign the sensitive score S*C for each coordinate in a proposal via its classification score C. The central point will be assigned a value of S=1, where S is computed by a 2-D Gaussian function, fading from the center of the suggestion box to the edge. By computing all of the sensitive scores for each coordinate, we can draw this spatial sensitive heatmap. The regression sensitive heatmap can be obtained with the same method.

@songguanglu  Thank you for your explanation.  Is it convenient to make the code public?


Remove unecessary Array call

As noticed by @zenspider...
... files is the result of a map call.
No need to coerce it to an Array.

cc #11


Add @Throws(...) annotation to all interfaces

Feature Request
Everywhere we define our custom exceptions, we should add @Throw(MyException) annotation so they are translated to checked exceptions in java. Currently, it's not possible to try catch our custom exceptions from java.

Instead of doing that, we've decided to use unchecked exceptions. Resolved in #217


Allow configuration of flatcar channel in image-builder

We've done this for the version already, let's do the same for the channel.

Support for flatcar release channel has been deployed.
There is one issue though. Azure doesn't have any non stable release channel images available. Azure seems to be very behind on having available flatcar images.


added xss preventions

Hi,
I found a Cross Site Scripting vulnerability inside src/CommunityStore/Utilities/States.php
By manipulating a specific POST-Request arbitrary html-tags can be embedded into the website.
Steps to reproduce this issue:

Install concrete5 according installation instructions
Login as administrator
Install concrete5-community-store according installation instructions
Create a new product under Dashboard -> Store -> Products
Add a new product with the button "Add product"
Fill in some random data remembering the name, e.g. testproduct and setting the active status
Save the product with the button "Add product"
Get your created product [URL]/concrete/index.php/products/testproduct
Add it to the cart and immediately proceed with the checkout
Now you should be on the site [URL]/concrete/index.php/checkout
This is where the vulnerability can be triggered

By manipulating the POST-Request
POST /concrete/index.php/checkout/getstates HTTP/1.1
country=US&selectedState=&type=billing&class=form-control&data=%7B%7D
and changing the POST parameters to something like
country=US&selectedState=&type=billing&class='style%3d"background-color:red"+onchange%3d"alert('XSS')%3b"+bla%3d'&data=%7B%7D
The content of the class variable gets injected into the website DOM.
When the site finished loading the State/Province selection should be red colored.
If you then select one item in the selection a popup with the text "XSS" should appear.
By wrapping the POST variables inside "src/CommunityStore/Utilities/States.php
" with htmlspecialchars() this vulnerability is prevented.
Please check the rest of the project-files and sanitize user's input data.
There might be more exploitable XSS vulnerabilities.

Thanks for this, great to consider these aspects.
I'll look to tidy this up shortly, there are a few concrete5 sanitise functions that might be more appropriate to use instead of htmlspecialchars (but its probably just a safe though).
The main curiosity about this injection of data into the DOM is whether it's actually something you could use for cross site scripting. Since you are adjusting your own POST requests, and only you receive them (and they don't save data anywhere), I'm not seeing how it could be used to do something malicious - you're really just directly editing your own page.
(i'm asking this more for my own learning, I can still see why this should be addressed)


Infected Files

The two files (folder/.exe) contain Win32:Adware-gen according to my anti-virus. Suggested actions, please? I thank the reponder(s) in advance!

Duplicate of https://github.com/CloneTrooper1019/Roblox-Studio-Mod-Manager/issues/54


python310Packages.pyfritzhome: 0.6.5 -> 0.6.7

Description of changes
Update to latest upstream release 0.6.7

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 192395 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.fritzbox
python310Packages.pyfritzhome
python39Packages.pyfritzhome

Result of nixpkgs-review pr 192395 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.fritzbox
python310Packages.pyfritzhome
python39Packages.pyfritzhome


⚠ Bofrost.at has degraded performance

In e7bb76f, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1602 ms

Resolved: Bofrost.at performance has improved in ff3218b.


docs: fix small typo why.md

Some places is listed as zwavejs and other as zwave-js, so I changed all the one I found as zwavejs for uniformity.

Pull Request Test Coverage Report for Build 504133660

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

Totals

Change from base Build 504126915:
0.0%

Covered Lines:
2008

Relevant Lines:
8789

💛  - Coveralls

Pull Request Test Coverage Report for Build 504133660

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

Totals

Change from base Build 504126915:
0.0%

Covered Lines:
2008

Relevant Lines:
8789

💛  - Coveralls


Make header/footer and section padding match at lower widths

Considering removing the footer. See https://github.com/emdaer/emdaer.github.io/issues/18#issuecomment-348701943


[BrokenLinks] add hierarchy to contextual navigation

Global effort to fix broken links
The C+E Skilling team is fixing broken links on docs.microsoft.com. This effort will eliminate potential accessibility, security, and usability issues. This PR addresses a number of link issues that are due to the incomplete breadcrumb file. I’d very much appreciate your timely review and feedback on the hierarchy I’ve suggested. Thanks!

Docs Build status updates of commit 92d3552:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-community-training/breadcrumb/toc.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

PRMerger Results

Issue
Description

Yaml File(s)
This PR includes changes to .yml file(s) owned by another author.

File Change Percent
This PR contains file(s) with more than 20% file change.

#sign-off

Invalid command: '#sign-off'. Only the assigned author of one or more file in this PR can sign off. @


[sentry-native] Update to 0.6.7

All features are tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static


Error: $.fullCalendar.moment is not a function

Hi, I'm trying to use calendar, but get an error.
TypeError: $.fullCalendar.moment is not a function
event._start = $.fullCalendar.moment(event.start);
I noticed you've have the same error on the demo page here (FireFox firebug) http://angular-ui.github.io/ui-calendar/
Do you know how to fix it?

hi,
any one help me to solve the problem ?
TypeError: jQuery(...).fullCalendar is not a function


Usage example in readme doesn't work

I cloned the repo, got the requirements, and placed this in a test script
from transformers import pipeline

prompt = "Write an email about an alpaca that likes flan"
model = pipeline(model="`declare-lab/flan-alpaca-xl`")
model(prompt, max_length=128, do_sample=True)
print(model)

As an output, I get <transformers.pipelines.text2text_generation.Text2TextGenerationPipeline object at 0x7fdd5559de20>

That works 👍
Loading checkpoint shards: 100%|████████████████████████████████████████████████████████████████████████| 2/2 [00:04<00:00,  2.03s/it]
[{'generated_text': 'Dear [Recipient], We are [Name] and our beloved alpaca. We love our regular meal of flan, but we have been wondering if you could tell us what flavor you like. Are you a fan of vanilla or chocolate? If so, please share your recipe with us. Thanks for [Specifics]. Sincerely, [Your Name]'}]


Collect a set of test DOIs from DataCite

Seems like the API docs provide a straightforward approach: https://support.datacite.org/docs/api-sampling
https://api.test.datacite.org/dois?random=true&page[size]=10         # Test api from DataCite
https://api.datacite.org/dois?random=true&page[size]=10                # production API from DataCite


llvmPackages_7: 7.0.1 -> 7.1.0

Motivation for this change
Fixy fixes, primarily a particularly gnarly issue.
Eep, my writing-fu is weak right now sorry!
Things done
Still testing, FWIW. :)

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Hmm, upstream posted no announcement nor link from the web :-/

Hopefully they follow soon :).
Tagged ~11d ago:
http://lists.llvm.org/pipermail/release-testers/2019-April/000946.html
Official source tarballs posted ~6d ago:
http://llvm.org/viewvc/llvm-project?view=revision&revision=358580
Looks like mostly waiting on folks to generate and upload platform
binaries, but just a guess.
We can sit on this for a few days, see if things are wrapped up by then
:)
On Tue, 23 Apr 2019 06:43:46 +0000 (UTC), Vladimír Čunát<EMAIL_ADDRESS>wrote:

Hmm, upstream posted no announcement nor link from the web :-/
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/NixOS/nixpkgs/pull/60068#issuecomment-485664266Non-text part: text/html

I don't think we need to wait for that, but the amount of rebuilds is high, so it probably shouldn't go directly to master anyway.

https://github.com/llvm/llvm-project/compare/llvmorg-7.0.1..llvmorg-7.1.0
Yep, it's entirely the official fix version of the patch we were using-- well, that and bits involved in changing the version number xD.
So definitely looks good, and indeed should be sent to staging (which I just fixed now). Thanks!

We're seeing this failure on aarch64:
https://hydra.nixos.org/job/nixpkgs/staging-next/llvm_7.aarch64-linux

We're seeing this failure on aarch64:
https://hydra.nixos.org/job/nixpkgs/staging-next/llvm_7.aarch64-linux

Well that's no good, sorry!
Thoughts so far:

If needed, we can disable llvm-exegesis / don't provide libpfm: neat utility but compared to having a working clang/libLLVM is by comparison unimportant.
It's strange this started happening with the update? The only change, AFAICT, we weren't already using is the new minor version number (and propagating it through the code).  Take a look: https://github.com/llvm/llvm-project/compare/llvmorg-7.0.1..llvmorg-7.1.0 .
Our aarch64 builder has an awesome number of cores, which sometimes causes problems we don't see elsewhere.  I don't see that being the cause here, though...

Oh, that's right-- this has happened before and disappeared, apparently?
https://github.com/NixOS/nixpkgs/issues/56245
Dunno, but thanks for the ping!

So looking at the test in question... it looks like it wants to check basic perf events fire, but it tests with the execution of a literally empty lambda (?!):
https://github.com/llvm/llvm-project/blob/1feaee52ff70948747251d83690de3ee35709a61/llvm/unittests/tools/llvm-exegesis/PerfHelperTest.cpp#L26
Perhaps it's intentionally testing the edge case ("ensure at least one event is triggered")?
Brainstorming-style, do we know that this builder supports performance counters? Cloud infrastructure often has limited support for this, no clue what the situation is with aarch64 but that might be worth checking.

Alright, I think I have something! cc @grahamc re:arm builders and Packet-relatedness.
This is a bit of a long-shot but here we go...

Looks like the builder is a Packet C2 Large Arm
According to the specs on that page, it's running an Ampere eMAG.
Awesomely, Ampere has this page on this model and their upstreaming support for it

Needs 4.19, or patches?

... do we know what kernel we're running on these? ^_^

Ah ok! I just saw that the version change and assumed it was new. It looks like it's been happening on a few past builds as well

@dtzWil Another issue that may not be directly related to this update but may be broken:
https://hydra.nixos.org/build/92930990/nixlog/3/tail
--- stderr
llvm-config: error: libLLVM-7.1.dylib is missing
thread 'main' panicked at 'command did not execute successfully: "/nix/store/5ffmj0j7px7xwawrb25bwxxhab633gvg-llvm-7.1.0/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "aarch64" "amdgpu" "arm" "asmparser" "bitreader" "bitwriter" "hexagon" "instrumentation" "interpreter" "ipo" "linker" "lto" "mcjit" "mips" "msp430" "nvptx" "powerpc" "sparc" "systemz" "webassembly" "x86"
expected success, got: exit code: 1', src/build_helper/lib.rs:134:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Maybe some patch in the llvm script needs to be updated?

@matthewbauer I'm already working on that one.

The performance counters test failure (issue #56245) also occurred when I tried to build llvm 7.0.1 on a Raspberry Pi 3.


Enlarge PetMe logo upon hover in footer.

Is your feature request related to a problem? Please describe.
As the PetMe logo scales upon hover in the Header, it would be great to do the same in footer as well as better visual appeal and styling.
Describe the solution you'd like
Scale the PetMe logo in footer upon hover by making CSS changes inline using Tailwind CSS classes.
Additional context
Currently:

@akshitagupta15june Could you assign me to this issue?


Error messages could be made more helpful (or add verbose option?)

I had some problems with my c++ headers.
The setup.py simply tries to compile a sample.cpp file, but swallows all compilation errors:
Line 135:
subprocess.call([candidates[v],"-o","test_build","-std={}".format(stdFlags[i]),"-fopenmp","sample.cpp"],stdout=DEVNULL,stderr=DEVNULL)
I manually removed the stdout=DEVNULL,stderr=DEVNULL part and finally got a useful error message other than "ERROR: Test compilation with the following binary names was unsuccessful:..."
There are even some prints (lines 144, 141) in the comments that might be helpful.
I propose the addition of a verbose option, or additional prints of compilation errors to save people some time debugging.
If anyone with a similar problem finds this post, here is the SO article that helped me:
https://stackoverflow.com/questions/19575956/building-c-not-working-in-osx-10-9#19577599

Makes sense for sure. We'll resolve that. Thanks!

I think this issue has been resolved a long time ago.


[BUG]  2024 season throwing an error

Is there an existing issue for this?

[X] I have searched the existing issues

Have you installed the latest development version of the package(s) in question?

[X] I have installed the latest development version of the package.

If this is a data issue, have you tried clearing your nflverse cache?
I have cleared my nflverse cache and the issue persists.
What version of the package do you have?
Version: 0.3.2
Describe the bug
Using Python's NFL_DATA_PY package, the season 2024 doesn't seem to be available for the pbp data set. I do see other data sets updated with 2024. It fetches 2023 and prior years without a problem. Thank you so much for the help!
Reprex
import nfl_data_py as nfl

# Import data for a wide range of seasons and check the maximum season
df_pbp = nfl.import_pbp_data(years=range(2023, 2025))  # Fetch data up to a future year
latest_season = df_pbp['season'].max()
print(f"The latest available season in play-by-play data is: {latest_season}")

produces this error:
NameError                                 Traceback (most recent call last)
Cell In[17], line 4
      1 import nfl_data_py as nfl
      3 # Import data for a wide range of seasons and check the maximum season
----> 4 df_pbp = nfl.import_pbp_data(years=range(2023, 2025))  # Fetch data up to a future year
      5 latest_season = df_pbp['season'].max()
      6 print(f"The latest available season in play-by-play data is: {latest_season}")

File ~\anaconda3\Lib\site-packages\nfl_data_py\__init__.py:153, in import_pbp_data(years, columns, include_participation, downcast, cache, alt_path, thread_requests)
    150     pbp_data.append(raw)
    151     print(str(year) + ' done.')
--> 153 except Error as e:
    154     print(e)
    155     print('Data not available for ' + str(year))

NameError: name 'Error' is not defined

Expected Behavior
I would expect to see an output of:
The latest available season in play-by-play data is: 2024
nflverse_sitrep
NA

Screenshots
No response
Additional context
No response

See: https://github.com/nflverse/nfl_data_py/issues/99#issuecomment-2342212809


Deprecate HIP Markers

Hi @gargrahul @mangupta Could you shed some light on the deprecation here? Isn't HIP meant to provide a compatibility layer for what's available in CUDA? It seems to imply that downstream libraries need to split the code path for CUDA and ROCm once hipProfilerStart() and hipProfilerStop() are removed? I think there is no deprecation plan announced for the CUDA counterparts cudaProfilerStart() and cudaProfilerStop() as of CUDA 11.0, so what's the rationale here? We're maintaining support for both CUDA and ROCm, and I find this deprecation warning both annoying and confusing.


complexFilters allows multiple chains, but not multiple filters in a chain

ffpmeg tag filter_complex allows to concatenate chains with a semicolon ";", and to concatenate filters in the same chain with a comma "," (see https://trac.ffmpeg.org/wiki/FilteringGuide#FiltergraphChainFilterrelationship). The default behaviour of complexFilters() is to concatenate chains,  but not filters in the same chain. According to the documentation, multiple calls to this function will override the previous settings (see https://github.com/fluent-ffmpeg/node-fluent-ffmpeg#complexfilterfilters-map-set-complex-filtergraph )
Version information

fluent-ffmpeg version: 2.1.2
ffmpeg version: n2.2.16-18-gc7fe604
OS: rhel fedora

Code to reproduce
var command = new ffmpeg()
  .input('path/to/video.mp4')
  .input('path/to/overlay/picture.png')
  .outputOptions(['-s 1024x576','-c:a libvo_aacenc','-b:a 192k','-c:v libx264','-preset:v medium','-profile:v main','-b:v 3500k','-pix_fmt yuv420p'])
  .complexFilter(['overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2', 'fps=fps=25'])
  .on('start', function(commandLine) {
    console.log('Ffmpeg starting conversion with command: ' + commandLine);
  });

Expected results
complexFilter should have a way to map it as
-filter_complex overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2,fps=fps=25
Observed results
complexFilter can only map it as
-filter_complex overlay=(main_w-overlay_w)/2:(main_h-overlay_h)/2;fps=fps=25
ffmpeg resulting error is:
Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_fps_1

What should a potential solution look like? Nested arrays?
.complexFilter(
  [ // outer array for chaining
    'overlay',
    'fps',
    [ // inner array for joining
      'rotate',
      'transpose'
    ]
  ]
)

-filter_complex overlay;fps;rotate,transpose

For anyone looking for this, I've created a fork that allows passing a nested array to complex filters as proposed by @laggingreflex. This first filter in a nested array should define  the inputs prop and the last filter should define the outputs prop.
If someone ever decides to start maintaining this lib, I'll create a proper pull request

Create one, I'll probably have some time to review it (please add some tests and docs to your fork though)


Container sizing values misbehave when multiple controls inside a container are selected

Godot version
4.0.alpha3
System information
Windows 10
Issue description
When multiple controls inside a container are selected, their Container sizing values misbehave and don't work as expected as you can see in the video below:
https://streamable.com/7fl8qz
EDIT: Actual values are correct, they just don't work as expected.
Steps to reproduce

Add multiple controls to a container node.
Select them and change their Container sizing properties.

Minimal reproduction project
No response

CC @godotengine/gui-nodes

Fixed.


Test Coverage Bump 3

--> Added unit tests for configurator
--> Added unit tests for enforcerproxy

Codecov Report

Merging #327 into master will increase coverage by 2.95%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #327      +/-   ##
==========================================
+ Coverage      55%   57.95%   +2.95%
==========================================
  Files          47       49       +2
  Lines        4805     5038     +233
==========================================
+ Hits         2643     2920     +277
+ Misses       1940     1884      -56
- Partials      222      234      +12

Impacted Files
Coverage Δ

enforcer/utils/packetgen/packet_gen.go

enforcer/proxy/enforcerproxymock.go
0% <0%> (ø)

configurator/configurator.go
69.45% <0%> (ø)

enforcer/proxy/enforcerproxy.go
77.47% <0%> (ø)

Continue to review full report at Codecov.

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


Stop Treating Your Data Engineer Like a Data Catalog /  Barr Moses @ Medium

URL: https://barrmoses.medium.com/stop-treating-your-data-engineer-like-a-data-catalog-14ed3eacf646
Review (1-2 sentences): Data engineers are not data catalogs! That says it all. There is a small guide on how to make dream come true.

Published in Digest #18.


Adds support for AWS::AutoScalingPlans::ScalingPlan

Change Summary:
Adds support for AWS::AutoScalingPlans::ScalingPlan
Adds validators for a number of types in AWS::AutoScalingPlans
Files Changed:

applicationautoscaling.py
validators.py

Fixes #1196

Thanks for the change. Shouldn't this go into a new file troposphere/autoscalingplans.py? We typically will put new resource types into their own namespace.

@markpeek Yeah it probably should go in it's own file. I have update the pull with the changes.

Thanks!


can not override default port in the script

Hi
For Kafka-Manager UI, to change default UI port from 9000 to 9100 we were updating /etc/init.d/kafka-manager script with below entry.
RUN_CMD="$exec -java-home /usr/lib/jvm/java-1.8.0-openjdk*/ -Dhttp.port=9100 >> /var/log/kafka-manager/kafka-manager.log 2>&1 &"
This works well in RHEL6, but in RHEL7 this option of updating in above script is not working, and start of kafka-manager is taking the default 9000 port(which conflicts with Cloudera) and kafka-manager UI start fails.
Can you please help here.

I just noticed the same issue. Running bin/kafka-manager -DHttp.port=9100 occupies 9000 anyway.

It works good for me on CentOS7
This is my systemd.service
`
[Unit]
Description=Kafka Manager
Documentation=https://github.com/yahoo/kafka-manager
Requires=network.target
After=network.target
[Service]
Type=simple
User={{ kafka_manager_user }}
Group={{ kafka_manager_group }}
WorkingDirectory={{ kafka_manager_home }}
ExecStart={{ kafka_manager_home }}/bin/kafka-manager -java-home {{ kafka_manager_java_home }}
StandardOutput=null
Restart=on-failure
[Install]
WantedBy=multi-user.target
`
I added application.ini file to my conf folder for CentOS7
Here is my template
-Dconfig.file={{ kafka_manager_home }}/conf/application.conf -Dhttp.port={{ kafka_manager_port }} -Dapplication.home={{ kafka_manager_home }}

Hi,
Thanks fo your info!

in Kafka-manager docker
docker exec -ti containerId bash
if you checkout README.md file with
cat README.md
the file navigate you to run this command
bin/kafka-manager -Dconfig.file=/opt/kafka-manager/conf/application.conf -Dhttp.port=9080
then you're good to go


Invalid Audience error for JWT Bearer token

Hi,
For more than 2 weeks I have been experiencing an issue with Authorisation on Azure Function App (.net 6.0, in-process, v4) on my TEST environment.
The function was working correctly for a long time before and there was no change done lately. Suddenly the issue starts to appear successively in all our other environments (QA, PROD) with 7 days and 2 days of delay.
The weird this is that my startup configuration, specifically, is not validating the tokens audience, see the configuration.
.AddJwtBearer(options =>
{
    options.Authority = //taken from appsettings
    options.TokenValidationParameters.ValidateAudience = false;
    options.RequireHttpsMetadata = true;
    options.Events = jwtBearerEvents;
})

The most problematic thing is that the issue is not reproducible locally on the VisualStudio, and started from nothing.
The error I have:
Bearer error="invalid_token", error_description="The audience 'api1 api2 api3 api4' is invalid

the 'api1 api2 api3 api4' is the whole audience present in the token
I contacted Azure Support and they advised me to use "Custom Bearer" because apparently

"Bearer" schema is used by Azure Functions with their handler

They also suggested more or less the same as here in the "Accepted answer": microsoft learn
I would like to ask if anyone is experiencing the same issue? And if this package is prepared for, apparently, not supporting "Bearer" schema anymore?

I tried the solution from Issue 19 and, it seems, it helped.

@dawidboloz based on what you say it seems they have changed the behavior recently. I'm wondering if removing built-in config should be enabled by default for this extension, instead of having to explicitly setting it to true.

@artmasa I have the feeling with the current Azure function app configuration, there is no way to use a token with "Bearer" schema without removing the built-in config. Unless we guess what audience and scope names are required in the built-in config and merge it to the token we have :)
Having this by default in this extension will make the .AddJwtBearer usable as right now it is hard to find a workaround from Issue 19, but the decision is not up to me.

It seems they are looking into fixing this with this PR 9701. I'm still preparing a change to remove existing configuration as the default behavior.

@dawidboloz, here is the PR #23 switching the default behavior to remove any Bearer configuration from the Host

I will go ahead and close this issue. New default behavior is contained in 3.1.3 release package


error while generating metadata for .NET Core 2.2

I am getting the following error when generating the metadata.json
Unhandled Exception: System.InvalidOperationException: The indexes {'ProjectId', 'Title', 'DisciplineId'} on 'Deliverable' and {'ProjectId', 'DisciplineId', 'Title'} on 'Deliverable' are both mapped to 'EARNEST.Deliverable.AKDeliverableTitle' but with different columns ({'ProjectId', 'Title', 'DisciplineId'} and {'ProjectId', 'DisciplineId', 'Title'}).
I have a Deliverable table that has a Title column and two FKs ProjectId and DisciplineId from the Project and Discipline tables.
All these three columns are part of the alternate key of the Deliverable table and so part of the unique index 'EARNEST.Deliverable.AKDeliverableTitle'. Besides this the two FKs also have the individual non-unique indexes on them.

Were you ever able to resolve this?

Nope. I did not try after that since this was an existing database and my goal then was to develop a breze sample with .NET Core for a new project I was starting. Luckily I was able to proceed with the new database without any issues. However, in future if I did upgrade that project from ASP.NET to .NET COre then I might run into this issue again or may be not.

@steveschmitt I usually work on Angular apps involving complex RDBMS databases and breeze has worked quiet well for me so far. But I wonder if I am the only one using breeze today and if it is the right thing to do?

We (IdeaBlade) are still developing Angular apps with Breeze, and are not stopping.  We still think it is the best tool for the job when relational databases are involved.
Breeze has not been marketed well (our fault) and it doesn't have the big names behind it like GraphQL does.  But in a way, GraphQL has validated our approach.  We always said that REST is a poor idiom for handling relational data, and finally people agree with us.
We still think that Breeze is superior to GraphQL (and everything else) because it models relational data better.  Please help spread the word!

Good to know, thanks. We have another big project by another team using GraphQL with React, and I can tell you the amount of server side code they are writing (without any reduction in the client side code) is mind blowing. when compared to what I write.
The one concern I have with breeze is if it will keep up with any breaking changes in its dependencies like .NET Core versions and Angular version. So far so good though.

We were a bit slow getting the .NET 5 code out, but it's there now, and we'll try to keep up with Microsoft going forward.
Thanks for using Breeze!

and now .NET 6 code is out as well

Great! Thanks to all at IdeaBlade


submit popular items in batch

Codecov Report

Merging #352 (a1e6be3) into master (220a034) will increase coverage by 0.02%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #352      +/-   ##
==========================================
+ Coverage   72.86%   72.88%   +0.02%
==========================================
  Files          44       44
  Lines        9415     9417       +2
==========================================
+ Hits         6860     6864       +4
+ Misses       1818     1817       -1
+ Partials      737      736       -1

Impacted Files
Coverage Δ

master/tasks.go
53.83% <50.00%> (+0.13%)
:arrow_up:

master/task_manager.go
91.91% <0.00%> (+1.47%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #352 (a1e6be3) into master (220a034) will increase coverage by 0.02%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #352      +/-   ##
==========================================
+ Coverage   72.86%   72.88%   +0.02%
==========================================
  Files          44       44
  Lines        9415     9417       +2
==========================================
+ Hits         6860     6864       +4
+ Misses       1818     1817       -1
+ Partials      737      736       -1

Impacted Files
Coverage Δ

master/tasks.go
53.83% <50.00%> (+0.13%)
:arrow_up:

master/task_manager.go
91.91% <0.00%> (+1.47%)
:arrow_up:

Continue to review full report at Codecov.

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


break statement not required

I guess,test failing due to connection error?

We just fixed the other dataset on master. Could you rebase from master and push to rerun the CI ?

If I'm not wrong this function returns None if no main class was found.
I think it makes things less clear not to have a return at the end of the function.
I guess we can have one return in the for loop instead of the break statement, AND one return at the end to explicitly return None.
What do you think ?

I guess current logic makes it more readable.
you can close this pr.


Nested lists of lists can panic

Found via:

https://github.com/elixir-explorer/explorer/pull/856

This panics:
test "list of list of lists of integers with two levels of empty lists" do
  values = [[], [[]], [[1]]]
  series = Series.from_list(values)

  assert series.dtype == {:list, {:list, {:s, 64}}}
  assert Series.to_list(series) == values
end

with:
  1) test from_list/2 list of list of lists of integers with two levels of empty lists (Explorer.Series.ListTest)
     test/explorer/series/list_test.exs:122
     ** (ErlangError) Erlang error: :nif_panicked
     code: series = Series.from_list(values)
     stacktrace:
       (explorer 0.9.0-dev) Explorer.PolarsBackend.Native.s_from_list_of_series("", [#Explorer.PolarsBackend.Series<
    shape: (0,)
    Series: '' [list[null]]
    [
    ]
  >, #Explorer.PolarsBackend.Series<
    shape: (1,)
    Series: '' [list[i64]]
    [
        []
    ]
  >, #Explorer.PolarsBackend.Series<
    shape: (1,)
    Series: '' [list[i64]]
    [
        [1]
    ]
  >])
       (explorer 0.9.0-dev) lib/explorer/polars_backend/series.ex:24: Explorer.PolarsBackend.Series.from_list/2
       (explorer 0.9.0-dev) lib/explorer/series.ex:418: Explorer.Series.from_list/2
       test/explorer/series/list_test.exs:124: (test)

It appears that this is a legal series:
https://www.rustexplorer.com/b/0ga2cs
shape: (3,)
Series: 's' [list[list[i32]]]
[
	[]
	[[]]
	[[1]]
]

This issue is a blocker for the property test PR. Should I fix it there or do it separately?

Lists in polars are tricky:

If it is empty it does not matter how many levels of nested list. It takes the dtype of non empty list element

For [[] , [[]] , [[[[]]]], [[2]] ] => dtype will be list[list[s64]]

if there only one element in list it results in a different dtype.

[[[[]]]] => dtype will be list[list[list[list[null]]]]
What is the rationale behind this, any clue ?

@lkarthee Interesting I didn't realize. Is this the behavior of Rust Polars or Python Polars?

I have tested it in py polars - from your rust example it looks like rust is no different from py.

I ask because I'm not sure you could make it in Rust because the compiler might prevent you.
Also, what's resulting series from [[] , [[]] , [[[[]]]], [[2]]]? I'd assume this:
[[] , [[]] , [[]], [[2]]]
             ^^^^
             Inner nesting removed

Otherwise the dtypes wouldn't match, right?
I'll try and test these in Rust later today.

Yeah true.
s = pl.Series([[[[[[[]]]]]], [], [[]]])
shape: (3,)
Series: '' [list[list[list[list[list[list[null]]]]]]]
[
	[[[[[[]]]]]]
	[]
	[[]]
]
s = pl.Series([[[[[[[]]]]]], [], [[]], [[]], [[0], [], []]])
shape: (5,)
Series: '' [list[list[i64]]]
[
	[null]
	[]
	[[]]
	[[]]
	[[0], [], []]
]

Interesting to note that first element reduced to [null] not [[]].

Hm yeah I would've expected [[]] or [[null]], not that.

Hm yeah I would've expected [[]] or [[null]], not that.

That can potentially be a polars bug?

Yeah it might be a bug. Although it's technically legal since every element can potentially be null. Who knows, maybe it's actually the correct way to do it for some non-obvious reason 🤷
(But I think bug is most likely)

I started to make an issue, but now I think Polars is more correct than we initially thought. Consider this example:
pl.Series([["a"], [1]])
# shape: (2,)
# Series: '' [list[str]]
# [
#         ["a"]
#         ["1"]
# ]

pl.Series([[1], ["a"]])
# shape: (2,)
# Series: '' [list[i64]]
# [
#         [1]
#         [null]
# ]

The dtypes of these series are either list[str] or list[i64]. Polars needs a tie-breaker, so letting the first element decide seems like a sensible choice. I think that's what's happening with some of our examples.
However, I still can't account for some other stuff we're seeing. These cases still seem wrong even if we use the first-non-empty-element-wins rule:
# Wrapping elements in additional layers of nesting to make the dtypes compatible
pl.Series([[[2]], [1, 1]])
# shape: (2,)
# Series: '' [list[list[i64]]]
# [
#         [[2]]
#         [[1], [1]]
# ]

# An empty list as the errant element pushes the null up one layer of nesting
pl.Series([ [[2, 2]], [["b"]] ])
# shape: (2,)
# Series: '' [list[list[i64]]]
# [
#         [[2, 2]]
#         [[null]]
# ]

pl.Series([ [[2, 2]], [[[]]] ])
# shape: (2,)
# Series: '' [list[list[i64]]]
# [
#         [[2, 2]]
#         [null]
# ]

Then there's this:
pl.Series([ [[2, 2]], [[2, 2]] ])
# shape: (2,)
# Series: '' [list[list[i64]]]
# [
#         [[2, 2]]
#         [[2, 2]]
# ]

pl.Series([ [[2, 2]], [[2, []]] ])
# shape: (2,)
# Series: '' [o][object]
# [
#         [[2, 2]]
#         [[2, []]]
# ]

Not sure what to make of that. Does anyone know if the intended behavior is documented anywhere? I didn't see it in the Python docs, but I might've just missed it.

The dtypes of these series are either list[str] or list[i64]. Polars needs a tie-breaker, so letting the first element decide seems like a sensible choice. I think that's what's happening with some of our examples.

You are right, that makes sense. This means we should raise on these cases, including in several of the examples below:

pl.Series([[[2]], [1, 1]])

Should raise.

pl.Series([ [[2, 2]], [["b"]] ])

Should raise.

pl.Series([ [[2, 2]], [[[]]] ])

Should raise. You can think that [[[]]] means it is at least a three element deep list, which violates the first value.

pl.Series([ [[2, 2]], [[2, []]] ])

Should raise.

The example you originally reported is still wrong and has to be fixed though. [[], [[]], [[1]]] means that the 1+ level list, then 2+ level list, and officially confirmed with a {:list, {:list, :s64}} list. I can try to work on a PR, since I wrote the current version of the code.

@josevalim I think Polars is making non-matching elements null instead of raising. So for:

pl.Series([[[2]], [1, 1]])

Should raise.

I think it should yield [[[2]], [null, null]] instead since each 1 it encounters ought to be a list. I have no idea why they decided to wrap each 1 to yield [[[2]], [[1], [1]]].
That said, we can also chose to differ from how Python Polars is resolving these situations by raising.

I think we should be stricter, unless we have a valid use case. Returning nil or wrapping are both undesired IMO.


depth first search is not depth first

I was toying with adding breadth first search, so you could skip trees of uninteresting children, but the more I looked at the algorithm... and it's breadth first, not depth first.
Okay, first in the constructor, it sets curr_ if the condition is true. But curr_ is the top node, so that's as breadth first as you get! Secondly, in popFront, it checks for curr_ to have a child, and sets curr_ to that child, then checks the condition. If that child itself has children, they don't get visited before this child is checked.
If it were depth first, it would need to loop until there were no children at all, then visit that node, then go up parent nodes, visiting each one. Once a parent node has a next node, go to that node, do not visit it, and start going down to the lowest child again.
I believe it is a breadth first traversal, even though it goes down the children, before going to the next siblings. The condition is checked at the topmost node, and no more depth is traversed, until the next iteration. Parent nodes will always be produced by the iterator before their children, since it checks the condition as soon as it goes down to firstChild, rather than continuing down firstChild to the bottom, then checking the condition only while returning back up.
So, good news for me I can just say "void skipChildren() { curr_ = curr_.next_; }" and it'll skip those children. But if you needed depth first searching, say to prune children without messing up the iterator, you'd mess up the iterator. Whatever you mutated the tree into, the iterator would descend into that, after visiting the parent node.
If it is a breadth first iterator, maybe it should go to .next_ first, rather than .firstChild_. You can use next_ to go across, just like firstChild_ goes down, until you hit the end, and then .prev_ instead of .parent_ to return, until a node is found that has a .firstChild. That'd be a more intutive way of breadth first searching... I think?
Considering this document:
<A>
  <AB>
    <BE/><BF/><BG/>
  <AC>
    <CH/><CI/><CJ/>
  </AC>
  <AD>
    <DK/><DL/>
  </AD>
</A>

A
AB       AC       AD
BE BF BG CH CI CJ DK DL

currently the order returned is:
A, AB, BE, BF, BG, AC, CH, CI, CJ, AD, DK, DL (I checked)
A breadth first search that prioritized next_ above firstChild_ would have this order:
A, AB, AC, AD, DK, DL, CH, CI CJ, BE, BF, BG
A depth first traversal would be thus:
BE, BF, BG, AB, CH, CI, CJ, AC, DK, DL, AD, A
That traversal prioritizes firstChild_ and goes from prev_ to next_. A depth first prioritizing firstChild_ and going from next_ to prev_ would be this:
DL, DK, AD, CJ, CI, CH, AC, BG, BF, BE, AB, A
which is the exact reverse order of the breadth first search prioritizing firstChild_ and going from prev_ to next_.

I suppose what I call depth first is the exploration order, not the order of the results.
Exploration is done depth first, and parents are reported as soon as their are visited on the way down, instead of on the way up.
Actual breadth-first is more expensive as it requires a stack, doesn't it?

Yes, I didn't mean "breadth-first" sorry. Nobody in their right mind cares if a search is "breadth-first" so it's not really important to implement it. You understood the unnamed traversal I meant, but I dunno if "exploration order" is a good term for it. Exploration order is a category for traversals, so breadth-first exploration order, depth-first exploration order, etc. Maybe call it parent-first? Top-first? Cream-skimming?
The thing I'm concerned about is, with a depth-first search, if you modify the children of the node you're visiting, they won't be searched. Sometimes you don't want this, such as techniques that involve multiple refinements or expansions; expanding the contents into a list of items, then expanding each item into a list of records. You have to make multiple passes with depth-first that way. But for situations where the children you produce are already completely parsed and processed, without depth-first you'd be needlessly traversing these children, and possibly double-encoding them.
But I could care less if a node a million pages away has an abstract concept of "depth" applied to it, that's greater than the children of the one I'm working on. I didn't mean you should worry about breadth-first. Like, at all.
The current algorithm is parent-first, and I wanted depth-first.
Basically:
depth-first: traverse children, visit node.
parent-first: visit node, traverse children.
breadth-first: sacrifice children, shoot self in head, write 90 page thesis on why this is a good idea
...
You could actually implement breadth-first without a stack here, because you already have a document tree, which can act as your ersatz stack and all you need is a number for what level it is. So p. much...
traverse the tree, stop at level 0 visiting all those nodes.
traverse the tree, stop at level 1, visiting all those nodes.
traverse the tree, stop at level 2, visiting all those nodes.
etc...
no more nodes found at level X, we're done.


Table 35. 32-bit Packing Instructions formatting

Table 35. 32-bit Packing Instructions. This instruction group is not desribed as RV-only in section 2.6 . All other groups are labeled RV64-only.

"RV64-only" will be added to Table 35 in the next release. Thanks.


incorrect generated colour different to one specified

Description
I am trying to match colours on images and text. I have the exact colour values in hex, putting them into typst causes a slightly different colour to be presented. Ensure you compile these examples using typst c to generate a PDF.
I used a colour picker to get the real colour presented, it's placed in a comment at the end of the line.
#set page(fill: rgb("#F7208B")) // #F71A8C

#set page(fill: rgb("#131313")) // #0C0C0C

This can either be fixed, or return to me the correct algorithm/transformation to create a suitable matching colour.
Reproduction URL
No response
Operating system
Linux
Typst version

[X] I am using the latest version of Typst

I can confirm that, when importing the document into Inkscape and checking the fill color of the page, it is #f71a8c.

I'm getting #f6168d and #0a0a0a . I suspect this may be about pdf viewers and and not typst.

Typst currently encodes colors using CalRGB color spaces in PDFs.
Computer monitors usually use the sRGB color space. However, according to the PDF standard (Section <IP_ADDRESS> Note 2) it's not possible to represent the sRGB color space as a CalRGB color space, only to approximate it.
To properly support it typst will have to implement support for ICC color spaces.

What is the current status of this issue? I remember @Dherse was working on a rework of colours in a branch for Typst.

What is the current status of this issue? I remember @Dherse was working on a rework of colours in a branch for Typst.

It's been merged with icc profiles for readers that support it!

Testing these changes out with the typst-git on Arch, rendering the below.
#rect(fill: rgb("#141414"), height: 100%)[hello]

Chromium: #0a0a0a
Firefox: #0c0c0c
These browsers do not have ICC support, having different colours is expected. I've tried a different renderer, mupdf:
$ mupdf output.pdf &
[1] 2092346
warning: lcms: not an ICC profile, invalid signature.
warning: ignoring broken ICC profile
$ grabc
#0c0c0c

What viewer could I use to properly render ICC colours? Is there ways to rasterise the entire PDF?

Strange that mupdf is complaining about broken ICC profiles, on my end it works just fine 😱
Adobe Acrobat probably has the best support, Chrome also supports ICC profiles, and so does mupdf

@l1mey112 can you send me your document so that I can inspect it? (you can also send it to me on Discord so that it stays private)

This is the document, I am selecting the colours on the right.
output.pdf

Okay, here is a little report:

mupdf: not correct
Xpdf: correct
Acrobat: not correct
Summatra PDF: not correct
Chromium: not correct
Firefox/pdf.js: not correct
evince: not correct

This could be an issue with the ICC profile being in a new version of ICC (which may have support issues in some readers, but I would at least expect acrobat to complain). It appears that they all recognize the ICC profile but chose to ignore it (at least for sRGB). Can you try setting the color to the similar luma(14), it should work in the same way by using grayscale instead and the grayscale ICC profile (that may be a temporary workaround, and it leads to smaller file sizes anyway). I also extracted the ICC profile and ran it with a diagnostics tools and it looks correct to me 🤷♂

Fixed by https://github.com/typst/typst/pull/2262


⚠ Bofrost.lu has degraded performance

In 2280df2, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1387 ms

Resolved: Bofrost.lu performance has improved in ee2beb7 after 6 minutes.


fix lang on relative-time day ordering

Tests are failing locally for me, because my locale is en-GB not en-US, which means tests, that depend on method that don't allow for customisation with locale fail.
I've fixed this by making isDayFirst & makeFormatter locale aware (it takes a locale but defaults it to 'default'). Then in relative-time, it calls isDayFirst with the given locale and in local-time it calls makeFormatter with the given locale. Lastly I fixed the locale to en-US in the tests.

:wave: Hello and thanks for pinging us! This issue or PR has been added to our inbox and a Design Infrastructure first responder will review it soon.

:art: If this is a PR that includes a visual change, please make sure to add screenshots in the description or deploy this code to a lab machine with instructions for how to test.
:fast_forward: If this is a PR that includes changes to an interaction, please include a video recording in the description.
:warning: If this is urgent, please visit us in #primer on Slack and tag the first responders listed in the channel topic.

Seems legit.