Build fails in latest raspbian jessie on Raspberry Pi 3

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
Go src version : 1.7.4
What operating system and processor architecture are you using (go env)?
Linux raspberrypi 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
What did you do?
If possible, provide a recipe for reproducing the error.
Try building Go v 1.7.4 on latest Raspbian.
What did you expect to see?
We expect to see sucessful build of Go like mentioned in - https://dave.cheney.net/2015/09/04/building-go-1-5-on-the-raspberry-pi
What did you see instead?
`pi@raspberrypi:~/go/src $ sudo env GO_TEST_TIMEOUT_SCALE=10 GOROOT_BOOTSTRAP=$HOME/go-linux-arm-bootstrap ./all.bash
Building Go bootstrap tool.
cmd/dist
Building Go toolchain using /home/pi/go-linux-arm-bootstrap.
bootstrap/internal/sys
bootstrap/internal/bio
bootstrap/asm/internal/flags
bootstrap/compile/internal/big
bootstrap/internal/obj
bootstrap/internal/gcprog
bootstrap/internal/obj/arm
bootstrap/internal/obj/arm64
bootstrap/internal/obj/mips
bootstrap/internal/obj/ppc64
bootstrap/internal/obj/s390x
bootstrap/internal/obj/x86
bootstrap/asm/internal/lex
bootstrap/link/internal/ld
bootstrap/compile/internal/ssa
bootstrap/asm/internal/arch
bootstrap/asm/internal/asm
bootstrap/asm
bootstrap/link/internal/amd64
bootstrap/link/internal/arm
bootstrap/link/internal/arm64
bootstrap/link/internal/mips64
bootstrap/link/internal/ppc64
bootstrap/link/internal/s390x
bootstrap/link/internal/x86
bootstrap/link
bootstrap/compile/internal/gc
bootstrap/compile/internal/amd64
bootstrap/compile/internal/arm
bootstrap/compile/internal/arm64
bootstrap/compile/internal/mips64
bootstrap/compile/internal/ppc64
bootstrap/compile/internal/s390x
bootstrap/compile/internal/x86
bootstrap/compile
Building go_bootstrap for host, linux/arm.
runtime/internal/sys
runtime/internal/atomic
runtime
unicode/utf16
unicode
unicode/utf8
math
internal/syscall/windows/sysdll
encoding
sort
sync/atomic
errors
internal/race
sync
container/heap
syscall
internal/singleflight
io
hash
hash/adler32
strings
bytes
strconv
bufio
path
internal/syscall/windows/registry
internal/syscall/windows
time
regexp/syntax
crypto
encoding/base64
reflect
crypto/sha1
regexp
os
path/filepath
os/signal
io/ioutil
fmt
encoding/binary
text/template/parse
debug/dwarf
compress/flate
context
go/token
net/url
encoding/json
log
flag
go/scanner
os/exec
go/ast
compress/zlib
text/template
debug/elf
debug/macho
go/parser
go/doc
go/build
cmd/go
Building packages and commands for linux/arm.
runtime/internal/sys
runtime/internal/atomic
runtime
internal/race
errors
sync/atomic
unicode
unicode/utf8
math
sort
sync
io
syscall
hash
hash/adler32
hash/crc32
container/heap
container/list
container/ring
bytes
strings
strconv
bufio
path
time
text/tabwriter
compress/bzip2
crypto/subtle
reflect
regexp/syntax
crypto
crypto/cipher
crypto/aes
math/rand
os
crypto/sha512
regexp
crypto/hmac
crypto/md5
internal/syscall/unix
crypto/rc4
crypto/sha1
path/filepath
crypto/sha256
encoding/base64
internal/nettrace
internal/singleflight
encoding
encoding/pem
encoding/ascii85
io/ioutil
encoding/base32
unicode/utf16
vendor/golang_org/x/net/lex/httplex
hash/crc64
hash/fnv
html
image/color
internal/syscall/windows/sysdll
runtime/debug
image
encoding/binary
fmt
image/color/palette
cmd/internal/sys
crypto/des
image/internal/imageutil
index/suffixarray
image/draw
image/jpeg
flag
log
debug/dwarf
compress/flate
cmd/internal/obj
debug/gosym
debug/plan9obj
compress/zlib
cmd/vendor/golang.org/x/arch/arm/armasm
cmd/vendor/golang.org/x/arch/x86/x86asm
debug/elf
cmd/internal/goobj
debug/macho
debug/pe
archive/tar
archive/zip
compress/gzip
cmd/internal/objfile
compress/lzw
context
math/big
encoding/hex
go/token
cmd/addr2line
go/scanner
os/exec
go/ast
database/sql/driver
database/sql
encoding/csv
go/parser
go/printer
encoding/gob
crypto/dsa
crypto/elliptic
encoding/asn1
crypto/rand
crypto/rsa
cmd/cgo
crypto/ecdsa
crypto/x509/pkix
encoding/json
encoding/xml
vendor/golang_org/x/net/http2/hpack
mime
mime/quotedprintable
net/http/internal
net/url
text/template/parse
go/constant
go/format
text/scanner
image/gif
go/types
image/png
text/template
runtime/pprof
runtime/trace
go/doc
html/template
runtime/cgo
go/build
testing
internal/trace
internal/testenv
net
math/cmplx
net/internal/socktest
os/signal
os/user
runtime/race
testing/iotest
testing/quick
go/internal/gccgoimporter
go/internal/gcimporter
cmd/api
go/importer
cmd/internal/obj/arm
cmd/internal/obj/arm64
cmd/internal/obj/mips
cmd/internal/obj/ppc64
cmd/internal/obj/s390x
crypto/x509
net/textproto
mime/multipart
crypto/tls
net/http/httptrace
log/syslog
net/mail
cmd/internal/obj/x86
cmd/asm/internal/flags
cmd/asm/internal/lex
cmd/internal/bio
cmd/compile/internal/big
cmd/internal/gcprog
cmd/compile/internal/test
cmd/cover
net/http
net/smtp
cmd/asm/internal/arch
cmd/asm/internal/asm
cmd/compile/internal/ssa
cmd/dist
cmd/asm
cmd/doc
cmd/fix
expvar
net/http/cgi
net/http/cookiejar
net/http/httptest
net/http/fcgi
net/http/httputil
net/http/pprof
net/rpc
cmd/go
cmd/gofmt
net/rpc/jsonrpc
cmd/internal/pprof/profile
cmd/internal/pprof/svg
cmd/internal/pprof/tempfile
cmd/link/internal/ld
cmd/internal/pprof/plugin
cmd/internal/pprof/report
cmd/compile/internal/gc
cmd/internal/pprof/commands
cmd/internal/pprof/driver
cmd/internal/pprof/fetch
cmd/internal/pprof/symbolizer
cmd/internal/pprof/symbolz
cmd/nm
cmd/objdump
cmd/pack
cmd/link/internal/amd64
cmd/link/internal/arm
cmd/link/internal/arm64
cmd/link/internal/mips64
cmd/link/internal/ppc64
cmd/link/internal/s390x
cmd/link/internal/x86
cmd/pprof
cmd/trace
cmd/link
cmd/vet/internal/cfg
cmd/vet/internal/whitelist
cmd/vet
cmd/yacc
cmd/compile/internal/amd64
cmd/compile/internal/arm
cmd/compile/internal/arm64
cmd/compile/internal/mips64
cmd/compile/internal/ppc64
cmd/compile/internal/s390x
cmd/compile/internal/x86
cmd/compile
Testing packages.
ok  	archive/tar	1.499s
ok  	archive/zip	1.918s
ok  	bufio	0.399s
ok  	bytes	0.713s
ok  	compress/bzip2	0.465s
ok  	compress/flate	17.219s
ok  	compress/gzip	0.124s
ok  	compress/lzw	0.096s
ok  	compress/zlib	0.343s
ok  	container/heap	0.041s
ok  	container/list	0.060s
ok  	container/ring	0.043s
ok  	context	0.968s
ok  	crypto/aes	0.347s
ok  	crypto/cipher	0.115s
ok  	crypto/des	0.202s
ok  	crypto/dsa	0.102s
ok  	crypto/ecdsa	1.208s
ok  	crypto/elliptic	0.381s
ok  	crypto/hmac	0.018s
ok  	crypto/md5	0.030s
ok  	crypto/rand	0.167s
ok  	crypto/rc4	0.845s
ok  	crypto/rsa	1.206s
ok  	crypto/sha1	0.026s
ok  	crypto/sha256	0.020s
ok  	crypto/sha512	0.055s
ok  	crypto/subtle	0.074s
ok  	crypto/tls	21.416s
ok  	crypto/x509	7.896s
ok  	database/sql	0.208s
ok  	database/sql/driver	0.014s
ok  	debug/dwarf	0.119s
ok  	debug/elf	0.139s
ok  	debug/gosym	0.115s
ok  	debug/macho	0.047s
ok  	debug/pe	0.567s
ok  	debug/plan9obj	0.017s
ok  	encoding/ascii85	0.016s
ok  	encoding/asn1	0.025s
ok  	encoding/base32	0.017s
ok  	encoding/base64	0.039s
ok  	encoding/binary	0.050s
ok  	encoding/csv	0.017s
ok  	encoding/gob	0.468s
ok  	encoding/hex	0.018s
ok  	encoding/json	2.613s
ok  	encoding/pem	0.111s
ok  	encoding/xml	0.141s
ok  	errors	0.014s
ok  	expvar	0.067s
ok  	flag	0.019s
ok  	fmt	1.102s
ok  	go/ast	0.053s
ok  	go/build	1.875s
ok  	go/constant	0.034s
ok  	go/doc	0.607s
ok  	go/format	0.107s
ok  	go/internal/gccgoimporter	0.061s
ok  	go/internal/gcimporter	7.137s
ok  	go/parser	2.369s
ok  	go/printer	5.862s
ok  	go/scanner	0.064s
ok  	go/token	0.204s
ok  	go/types	5.048s
ok  	hash/adler32	0.109s
ok  	hash/crc32	0.023s
ok  	hash/crc64	0.040s
ok  	hash/fnv	0.043s
ok  	html	0.023s
ok  	html/template	0.488s
ok  	image	1.196s
ok  	image/color	1.085s
ok  	image/draw	0.758s
ok  	image/gif	0.535s
ok  	image/jpeg	1.562s
ok  	image/png	0.474s
ok  	index/suffixarray	0.088s
ok  	internal/singleflight	0.034s
ok  	internal/trace	0.197s
ok  	io	0.048s
ok  	io/ioutil	2.775s
ok  	log	0.061s
ok  	log/syslog	2.214s
ok  	math	0.025s
ok  	math/big	5.651s
ok  	math/cmplx	0.017s
ok  	math/rand	0.816s
ok  	mime	0.069s
ok  	mime/multipart	3.468s
ok  	mime/quotedprintable	1.184s
ok  	net	2.877s
ok  	net/http	43.851s
ok  	net/http/cgi	2.415s
ok  	net/http/cookiejar	0.109s
ok  	net/http/fcgi	0.075s
ok  	net/http/httptest	0.061s
ok  	net/http/httptrace	0.020s
ok  	net/http/httputil	0.222s
ok  	net/http/internal	0.048s
ok  	net/internal/socktest	0.020s
ok  	net/mail	0.040s
ok  	net/rpc	0.119s
ok  	net/rpc/jsonrpc	0.100s
ok  	net/smtp	0.259s
ok  	net/textproto	0.052s
ok  	net/url	0.090s
ok  	os	2.775s
ok  	os/exec	1.267s
ok  	os/signal	4.342s
ok  	os/user	0.039s
ok  	path	0.038s
ok  	path/filepath	0.271s
ok  	reflect	0.745s
ok  	regexp	1.078s
ok  	regexp/syntax	4.605s
--- FAIL: TestGCFairness (3.37s)
crash_test.go:77: starting testprog GCFairness: fork/exec /tmp/go-build175788758/testprog.exe: cannot allocate memory
--- FAIL: TestGCFairness2 (7.18s)
crash_test.go:77: starting testprog GCFairness2: fork/exec /tmp/go-build175788758/testprog.exe: cannot allocate memory
--- FAIL: TestNumGoroutine (5.98s)
crash_test.go:77: starting testprog NumGoroutine: fork/exec /tmp/go-build175788758/testprog.exe: cannot allocate memory
--- FAIL: TestDwarfAranges (8.04s)
runtime-lldb_test.go:205: building source fork/exec /home/pi/go/bin/go: cannot allocate memory
--- FAIL: TestLargeStringConcat (2.42s)
crash_test.go:77: starting testprog stringconcat: fork/exec /tmp/go-build175788758/testprog.exe: cannot allocate memory
FAIL
FAIL	runtime	423.697s
ok  	runtime/debug	0.115s
ok  	runtime/internal/atomic	0.649s
ok  	runtime/internal/sys	0.042s
ok  	runtime/pprof	6.378s
ok  	runtime/trace	20.906s
ok  	sort	0.575s
ok  	strconv	5.642s
ok  	strings	1.026s
ok  	sync	0.810s
ok  	sync/atomic	0.269s
ok  	syscall	0.624s
ok  	testing	1.867s
ok  	testing/quick	0.487s
ok  	text/scanner	0.033s
ok  	text/tabwriter	0.024s
ok  	text/template	3.684s
ok  	text/template/parse	0.096s
ok  	time	4.487s
ok  	unicode	0.024s
ok  	unicode/utf16	0.016s
ok  	unicode/utf8	0.030s
ok  	vendor/golang_org/x/net/http2/hpack	0.042s
ok  	vendor/golang_org/x/net/lex/httplex	0.015s
ok  	cmd/addr2line	6.076s
ok  	cmd/api	0.057s
ok  	cmd/asm/internal/asm	2.411s
ok  	cmd/asm/internal/lex	0.020s
ok  	cmd/compile/internal/big	350.904s
ok  	cmd/compile/internal/gc	119.390s
ok  	cmd/compile/internal/ssa	2.085s
ok  	cmd/compile/internal/test	0.030s
ok  	cmd/cover	11.208s
ok  	cmd/doc	0.178s
ok  	cmd/fix	0.082s
ok  	cmd/go	22.705s
ok  	cmd/gofmt	0.259s
ok  	cmd/internal/goobj	0.044s
ok  	cmd/internal/obj	0.025s
ok  	cmd/internal/obj/x86	0.031s
ok  	cmd/internal/pprof/profile	0.015s
ok  	cmd/link	0.013s
ok  	cmd/nm	4.258s
ok  	cmd/objdump	13.423s
ok  	cmd/pack	11.288s
ok  	cmd/vendor/golang.org/x/arch/arm/armasm	0.034s
ok  	cmd/vendor/golang.org/x/arch/x86/x86asm	1.103s
ok  	cmd/vet	16.117s
ok  	cmd/vet/internal/cfg	0.027s
2017/01/23 07:05:49 Failed: exit status 1
`

Looks like it just doesn't have enough memory.

@indiandragon have you looked at https://github.com/golang/go/wiki/GoArm? It shows some tricks to make use of less memory and add more via swap.
I also seem to remember that 1.8 should take slightly less memory when compiling, so try building rc2 if all else fails.

note: Go is built and installed by the time you encounter this failure. If
your goal is to build Go from source, you can safely ignore this error, and
opt to use ./make.bash in the future to avoid running the entire test suite.
On Mon, Jan 23, 2017 at 9:06 PM, Daniel Martí<EMAIL_ADDRESS>wrote:

@indiandragon https://github.com/indiandragon have you looked at
https://github.com/golang/go/wiki/GoArm? It shows some tricks to make use
of less memory and add more via swap.
I also seem to remember that 1.8 should take slightly less memory when
compiling, so try building rc2 if all else fails.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18756#issuecomment-274446341, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA3gzejwk6mDtMi3F9Zu3ADfel58Zks5rVHu3gaJpZM4LqnIR
.

@bradfitz @mvdan I'll look into the memory as you guys suggest and revert.
@davecheney That's interesting, I installed go-lang as a dependency, I check whether my intended project runs fine and revert.

@indiandragon Did this work for you or are you still unable to use Go on your Pi 3?


How can I connect to a Coral dev board from another Coral dev board using mdt shell?

Say I have one Coral dev board connected to a monitor, keyboard, and mouse. How can I run mdt shell and connect to another Coral dev board attached via USB? I am trying it now, but it seems the second Coral is not recognized and mdt shell only tries to connect to itself

Please try the changing the static ip address of the connected dev board and try to connect with mdt shell . Please check the instructions to change the static ip address at: https://github.com/google-coral/edgetpu/issues/619#issuecomment-1172606933. Thanks!

Hi hjonnalo, thank you for the response. I was able to successfully set the IP address of the first dev board as you described and verified with sudo netstat -rn. Unfortunately I am still unable to connect to the second dev board from that first dev board. It is not even showing up with mdt devices. However I double checked that this second coral works by connecting it to my laptop, and it shows up there as jumping-snail		(<IP_ADDRESS>)
Based on this, I tried to change usb0 to be <IP_ADDRESS> but am not having luck with that.
Changes I made:
/usr/bin/usb-gadget-start.sh
configure_network() {
        GADGET_CON_NAME="gadget${1}"
        INTERFACE_NAME="usb${1}"
        $(nmcli con show | grep -q "${GADGET_CON_NAME}")
        mendel_conn_exist=$?
        if [[ "$mendel_conn_exist" -eq 0 ]]; then
          echo "${GADGET_CON_NAME} connection already exists"
        elif [ "${1}" -eq "0" ]; then
          nmcli con add con-name "${GADGET_CON_NAME}" ifname "${INTERFACE_NAME}" type ethernet ip4 "<IP_ADDRESS>/24"
        elif [ "${1}" -eq "1" ]; then
          nmcli con add con-name "${GADGET_CON_NAME}" ifname "${INTERFACE_NAME}" type ethernet ip4 "<IP_ADDRESS>/24"
        else
          nmcli con add con-name "${GADGET_CON_NAME}" ifname "${INTERFACE_NAME}" type ethernet ip4 "192.168.10${1}.2/24"
        fi
        nmcli con up id "${GADGET_CON_NAME}"
}

/etc/dnsmasq.d/02-usb-gadget
dhcp-range=usb0,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>,12h
dhcp-range=usb1,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>,12h

Result after rebooting:
$ sudo netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
<IP_ADDRESS>         <IP_ADDRESS>     <IP_ADDRESS>         UG        0 0          0 eth0
<IP_ADDRESS>         <IP_ADDRESS>     <IP_ADDRESS>         UG        0 0          0 wlan0
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS>   U         0 0          0 eth0
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS>   U         0 0          0 wlan0
<IP_ADDRESS>    <IP_ADDRESS>         <IP_ADDRESS>   U         0 0          0 hotspot
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS>   U         0 0          0 usb0
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS>   U         0 0          0 usb2
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS>   U         0 0          0 usb1

I was expecting to see jumping-snail in this output, but I only see the coral pointing to itself
$ mdt devices
connected-coral		(<IP_ADDRESS>)

Was this the right kind of change to make? Is there something else I should try?

Please try changing the address1 in sudo cat /etc/NetworkManager/system-connections/gadget0.nmconnection file and reboot the device to change the usb0 ip address.
mendel@arid-pig:~$ sudo cat /etc/NetworkManager/system-connections/gadget0.nmconnection
[connection]
id=gadget0
uuid=e1565cc8-f0d2-4767-84f8-668cd3440312
type=ethernet
interface-name=usb0
permissions=

[ethernet]
mac-address-blacklist=

[ipv4]
address1=<IP_ADDRESS>/24
dns-search=
method=manual

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

(coral_venv) hemanth:~ mdt devices
arid-pig                (<IP_ADDRESS>)
After changes:
(coral_venv) hemanth:~ mdt devices
arid-pig                (<IP_ADDRESS>)

I updated the file and after a reboot am seeing the correct output:
$ mdt devices
first-coral		        (<IP_ADDRESS>)
vexing-quill		(<IP_ADDRESS>)

However I am unable to connect to it:
$ mdt shell <IP_ADDRESS>
Connecting to <IP_ADDRESS> at <IP_ADDRESS>
Couldn't establish ssh connection to device: socket error: [Errno None] Unable to connect to port 22 on <IP_ADDRESS>

Is there anything else I need to change?

I have one coral dev board and dev board mini and I am able to connect dev board mini, connected via usb OTG, from the dev board.
venv_coral) hemanthreddyj@hemanthreddyj-glaptop7:~/pycoral$ mdt shell
Waiting for a device...
Connecting to arid-pig at <IP_ADDRESS>
Linux arid-pig 4.14.98-imx #1 SMP PREEMPT Tue Nov 2 02:55:21 UTC 2021 aarch64

The programs included with the Mendel GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Mendel GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Nov  4 15:45:58 2022 from <IP_ADDRESS>
mendel@arid-pig:~$ mdt devices
arid-pig                (<IP_ADDRESS>)
wishful-orange          (<IP_ADDRESS>)
mendel@arid-pig:~$ mdt shell wishful-orange
Waiting for device wishful-orange...
Connecting to wishful-orange at <IP_ADDRESS>
Linux wishful-orange 4.19.125-mtk #1 SMP PREEMPT Thu Dec 10 02:36:13 UTC 2020 aarch64

The programs included with the Mendel GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Mendel GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Feb 14 10:12:12 2019 from <IP_ADDRESS>
mendel@wishful-orange:~$


[Refactor] use more explicit assert.ok

This is a tiny refactor, hopefully it's acceptable.
(We'll all be much happier if you choose not to ask why i need this change :-) )

@isaacs does this need documentation since it's such a small change?

I'd assume not; virtually nobody but me's going to notice.

@nicolas377 see the second sentence in the OP.
In node 0.6+, this will behave identically. Absolutely nothing needs to be documented that affect an older version of node than that :-)

(We'll all be much happier if you choose not to ask why i need this change :-) )

Oh god, I think I know what's going on here lol 😂
Do you need this backported to v7?  v8 is node 12+ already anyway.

@isaacs ideally yes, but i understand if you're unwilling. either way this drastically reduces the number of n_m patches i need to float :-)

Published on 7.2.2 and 8.0.3


[Bug] Stream Wont Connect

Describe the bug
restarted console multiple times. any fixes to this bug?

To Reproduce
No response
Expected behavior
No response
Environment
- OS:
- Device:
- Greenlight version:

Anything else?
No response
New issue

[X] I confirm that this is a new issue and not a duplicate

Please hard reset your console. This bug had reported many times. Next time please check the closed issues before opening new ones.


TFRS - Remove or hide balance change statements within the Assessment section for 2023 reporting

Describe the task
Remove, or hide in the UI, the balance change statements within the Assessment section of a reviewed/accepted compliance report for the 2023 compliance period. This needs to be done for the assessment section under all scenarios, including supplemental reporting which adds an additional sentence describing the balance change that will occur / occurred.
Examples of statements to remove within the assessment section:

Scenario 1: Private Zenhub Image

Scenario 2: Private Zenhub Image

Scenario 3: Private Zenhub Image

Scenario 4: Private Zenhub Image

Scenario 5: Private Zenhub Image

Purpose
Statements are not always correct in terms of the type of balance change that is occurring. This issue is a result of the recent changes to the Summary section of the 2023 reports. Instead of spending significant development time resolving the inaccuracies for each scenario, we want to simply hide or remove these statements for the 2023 reports.
Acceptance Criteria

[ ] first
[ ] second
[ ] third

Additional context

Add any other context about the task here.
Or here

Hey team! Please add your planning poker estimate with Zenhub @AlexZorkin @jig-patel @prv-proton

Working for 2023 reports. Unable to test if it is still available in 2022 and prior reports due to a bug with viewing summary and declaration section. Unable to submit new reports to test. Closing out this ticket and will test 2022 and prior once the bug is resolved.


Add org.slf4j/slf4j-nop depedency prevent messages when running task dev

Only an annoyance.
These messages show while running ./task dev
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Adding the slf4j-nop dependency resolves.

Thanks!


at service level docerina tags are not read

Original issue - https://github.com/ballerina-lang/docerina/issues/99
at the service level, Ballerina does not allow single line comments. However, docerina tags are allowed. However, it seems that tags such as @doc:Description are not shown once the docerina templates are generated.
steps
1.add a tag such as below just above the service.
@doc:Description { value: "The service helps to obtain the jacoco code coverage via jenkins as json payload"}
2.run the command to generate the doc template
../../../ballerina-tools-0.88/bin/ballerina doc ../../../wso2/ -o doc/   -v
Note: Ideally since the @doc:Description,  is allowed, the contents should be read. Currently, developers cannot add a single line comment nor does the docerina contents are shown for a service.

This is fixed with the new documentation syntax.


Bad DNS gets cached until total phone reboot

Try to connect when wifi accidently off.
DNS gets cached as bad until one reboots entire phone!

What device\android version is that with? Also what build of ConnectBot?

"Latest" connectbot, on Android 4.0.4 mtk6577.

I'm not sure ConnectBot could do anything about this since the DNS is cached in netd.

This was a bug\feature fixed somewhere in the Jelly Bean era, if I remember correctly. I used to have similar issues accessing local network resources such as intranet web pages due to DNS caching on my Nexus S. Seems a long time ago now :)
@jidanni As a workaround, I think i put into airplane mode or maybe just toggled the data connection for a moment rather than full reboot.

OK.


Donate button

updated the footer and sidebar donate links, and added a donate button to the navbar.

Codecov Report

Merging #34 (e25e231) into master (23e54be) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #34   +/-   ##
======================================
  Coverage    3.83%   3.83%
======================================
  Files         145     145
  Lines        3047    3047
  Branches      958     958
======================================
  Hits          117     117
  Misses       2927    2927
  Partials        3       3

Impacted Files
Coverage Δ

src/components/Donate.tsx
0.00% <ø> (ø)

src/components/Footer.tsx
0.00% <ø> (ø)

src/components/Navbar.tsx
0.00% <ø> (ø)

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 23e54be...e25e231. Read the comment docs.


Incorrect documentation in obsolete attribute

As mentioned here:
https://github.com/cake-build/cake/commit/7dd911841488657f9cd98752d1526360bf6d398c#commitcomment-17689375
by @Redth

Fixed by #938


Feature request: Introducing some builder-functionality to weaviate's Java client for building where- and field-clauses

Hey,
currently, weaviate's Java client only supports specifying where-filter-clauses and the specifications of fields to be returned via inserting strings into the corresponding withWhere() and withFields() functions (respectively).
However, constructing strings manually seems prone to making errors and usually leads to poorly readable code. Therefore, it would be great for the future to have the weaviate Java client providing functionality for building where- and fields-clauses using some builder-functions.
Kind regards!

@antas-marcin this is the feature request for the question that we had the slack conversation about


[Possible bug] Issue with M4 dataset inverse transform

Hi,
I am not sure if M4 is using inverse transform function. Even if I pass the flag --inverse True, the function inverse_transform won't be called.
And there's no self.scaler set in Dataset_M4, The __read_data__ doesn't have the self.scaler functionality for M4 class!

Hi, we do not normalize the M4 data before input. Thus, you do not need employ the inverse transform.


Android: Folders Show Stories from Sub-Folders

As requested in #669.  Right now we only show stories in their true containing folder, not in any parent folders like the web.

Working on this, since the main task is a blocker for several other, smaller features.  It turns out we were totally discarding the folder heirarchy really, really early in the data lifecycle.  I'm updating the parse/process/store/render pipeline to actually understand that folders can be nested at all.

Finally updated the app's DB to retain full folder heirarchy data (we used to toss it out).  Folders now display stories from any feed within the folder or sub-folders, like the web.  Also was able to remove some work-around code that was previously required as a result of our data loss.  Pull request coming once I tweak a few remaining UI bits to correctly reflect unread counts in collapsed folders.

Done in #679.


Add Notebook WG leads to OWNERS

This adds the Notebook Working Group Leads as OWNERS for the Notebook docs.

@RFMVasconcelos can you please review?

Sure!
/assign @RFMVasconcelos

@8bitmp3 there is no need to add you as a reviewer, as you are already a reviewer in the root OWNERS file

@RFMVasconcelos I have updated the PR to only assign approvers

Great @thesuperzapper !
/lgtm

/approve

/assign @Bobgy

@Bobgy can you please LGTM this?

/lgtm
/approve
Sure, thank you for starting taking care of the docs!


Can't --inspect into a remote node container (port translation not working)

VSCode Version: insider
OS Version: Windows 10 + docker

This issue is related to the previews one, albeit this time the translation issue is with port number.
https://github.com/Microsoft/vscode/issues/23257
Now IP translation works as VSCode is respecting the launch.json IP.
However the same problem was not resolved for port translation.
That is, VSCode seems to ignore the port I specify in launch.json
Example [Host port -> Container port]
9999 -> --inspect-brk=<IP_ADDRESS>:9229
The above work when I open it in chrome as <IP_ADDRESS>:9999 but it doesn't in VSCode if I specify the port number in launch.json as 9999
Google Chrome handles both flawlessly.

I think this is the same as https://github.com/Microsoft/vscode/issues/25015


allow shpec file to specify shell to support developing for different shells and fix bad detection on mac

I'm somewhat speculating here since I haven't played with this thoroughly, but I believe this explains the misbehavior I was seeing.
On my friend's mac, he ran my shpec and it was failing because, on his system, it wasn't using the current bash version for the test.
He found that it was running an old version of shell, I guess the one that is invoked automatically when there is no shebang for the script you invoked (that being shpec).  I looked at the shpec file and saw there was indeed no shebang.
His most current bash was in /usr/local/bin, but wasn't being invoked as the shell to run shpec under.  Adding a "#!/usr/bin/env bash" shebang to shpec got it to work properly.
I'm guessing there's no shebang on shpec since it's portable to multiple shells and so the system's shell is perhaps the best hint on what the programmer is aiming for.
However, that's not the correct indicator for the desired shell for testing, at least clearly on my friend's mac.
Rather, it should be the user's test file which determines the shell.  This would allow my test to specify /usr/bin/env bash as the shell and have it be respected so that the test code is executed in the desired context.  If I had code targeted for another shell in a different file, that too would be detected and tested properly.
I don't know how exactly this would be accomplished, aside from detecting the shebang in the test file and exec'ing or fork'ing shpec in the specified shell, although that might pose some difficulties if several files were specified with differing shells.  Still, I'm sure it could be done with a little effort.

Haven't had time to look at this, closing rather than letting it zombie.


release: fix bash bug in script

Signed-off-by: Tibor Vass<EMAIL_ADDRESS>Ping @jfrazelle @tianon

LGTM, its actually not that bad w the -x, so im impartial

@tianon updated PTAL

LGTM

@jfrazelle @tianon feel free to merge


delta time extension doesnt work properly on penguinmod

Expected Behavior
it should show the normal fps
Actual Behavior
it keeps switching from 5000 fps to 10000 fps
Steps to Reproduce
import this custom extension into penguinmod and show the fps variable
(https://extensions.turbowarp.org/XeroName/Deltatime.js)
Operating System and Browser
windows 11, microsoft edge

that apears to be expected behavior

nvm but it is fixed now

tank u


[Fix #432] Add new FactoryGirl/DynamicAssociationDeclaration cop

This adds a new FactoryBot cop as outlined in #432. It checks for dynamic association declarations in factories, and suggests replacing them with calls to #association, which is more explicit, and supports configuration options.

Since the namespace was changed from FactoryGirl to FactoryBot at #490, it seems good to make a change accordingly 😃

Since the namespace was changed from FactoryGirl to FactoryBot at #490, it seems good to make a change accordingly 😃

I used FactoryGirl in all places except the namespaces. I think this needs to be a separate PR with deprecation warnings.

I tried on a local codebase and it seems it doesn't register offence if there is anything in the factory but the offending code. Also it triggers false positives on legitimate code, like calling skip_create in the factory or referencing a trait

Thanks for the feedback, @Darhazer. Will add some test cases, and exclusions for false positives. Guess I'll need to go dig deeper into FactoryBot documentation. 😅

I used FactoryGirl in all places except the namespaces. I think this needs to be a separate PR with deprecation warnings.

I think this cop also seems to work under FactoryBot namespace.
So just renaming cop name to FactoryBot, is not compatibility problem, I think.

@Darhazer: Sorry. Have been caught up with work. What remains is to remove false positives for traits referenced from inside other traits.
My strategy is to skip up to the factory root, then scan through all the immediate children and collect any defined trait names in a list. Does this seem sound? Or can you think of any cases where this would not work?

My strategy is to skip up to the factory root, then scan through all the immediate children and collect any defined trait names in a whitelist.

I would to exactly the same.
Please check also the case when there is association followed by other properties, as in my initial tests those were not flaged:
FactoryGirl.define do
  factory :user do
    country
    sequence(:email) { |n|<EMAIL_ADDRESS>}

I would to exactly the same.

I will proceed with this approach, then. 🙂

Please check also the case when there is association followed by other properties, as in my initial tests those were not flaged

I fixed this already. 😊

btw with something like def_node_search :registered_trait?, ' (send nil :trait (sym %))' and then use it like registered_trait?(node, name)

The development has stalled. Nobody picked it up.
Also, the implicit association syntax is similar to inline global attribute definition and inclusion of traits, which make it ambiguous, and risks false positives.
Besides, the implicit style is a pretty valid syntax. I'm not aware of any deprecations.
Just as everything about FactoryGirl, it needs a deep thought when used, and the fact that it comes with a caveat doesn't mean it should be always avoided.
See https://github.com/rubocop-hq/rubocop-rspec/issues/432#issuecomment-667682937


Prefix before suggestion provider should not be displayed.

@tkurz I think we do not need a fixed display title. Since the second part dbsearch in the Screenshot is the display title from the configuration. So if we have a default value for the configuration, we have max flexibility. WDYT?


WIP Repaint the bike shed

This PR follows on from the discussion in #5497 . Its happening. Lets go.
Shields badges should be accessible by default. The first stated goal of shields is that badges should be

legible: it should be as easy to read the metadata provided by a badge as it is to read body copy inside of a README file regardless of display resolution

The objective of this PR is to improve the colour contrast (and hence accessibility and readability) of our badges. I'm going to do that by:

Adjusting the palette of named/semantic colours we use to render 99% of our "official" badges (that is service badges on a named route).
Using a more pronounced drop-shadow on badge styles that use a drop-shadow (flat, which is the default and also plastic) to achieve greater contrast.

There are a number of things I am explicitly not doing in this PR:

I'm not attempting to achieve LC-75 contrast when using the flat-square or for-the-badge styles, which do not use a drop-shadow. The palette changes should increase contrast when using those styles, but in some cases those styles will still not achieve the target.
I'm not attempting to achieve sufficient contrast in 100% of cases. There will still be cases where a user can supply a named CSS colour or hex value (either on a custom badge, or as an override) outside the standard palette that decrease accessibility.
I'm not making any changes to the brightness calculations we use to automatically switch the text or logo colour when using custom colours.
I'm not making any changes to the handful of "official" badges that are using custom hex values outside of the standard palette, for whatever reason.

Those are not problems we will never tackle, but changes to those things should be out of scope for this PR. Lets start off by making a small change that fixes the most common cases to start with. Those issues can be addressed at another time.
As it stands right now, this PR makes the following changes. As we tweak this PR, I will update this:
colours

colour
before
after

brightgreen

green

yellowgreen

yellow

orange

red

blue

grey

lightgrey

build status

status
before
after

passing

failing

error

version

version
before
after

stable

pre-release

coverage

coverage
before
after

100%

95%

85%

75%

0%

There are a number of things I have not done in this PR:

This PR makes changes to the badge-maker NPM package. I haven't bumped the package version or updated the changelog in this PR.
We're going to need to do some communication around this change. As well as a pinned issue/discussion, one of the things I want to do is write a blog post. I'll write it before we merge this, but lets nail the code changes down first.

Obviously this change is high impact. Merging this will change the base palette for the first time in ~10 years, affect basically 100% of users and everyone is going to have opinions about it. I am confident we are making this change for the right reasons, but I'd like to make sure we have some kind of consensus on the outcome from the maintainer team and wider community before we merge this.
Maintainers: You can spin up a review app to review changes. I'd be particularly interested if anyone can spot any unintended consequences of this work that I may have missed as well as just feedback on the intended changes outlined in the tables above.

Total aside: I'd started working on this (https://github.com/JoshuaKGoldberg/shields/tree/render-shadow) and had a hard time getting the local dev server to show my changes. Very happy you're taking this on. Thanks 😄

Haven’t tested this, but I'm on board with the spirit of the changes. At first glance, I'll note that "brightgreen" doesn't feel very bright anymore, and yellow feels a little brown-ish.

Yeah there's a bit of discussion about the brightgreen here https://github.com/badges/shields/issues/5497#issuecomment-1902725815
Obviously there's a tension between darkening sufficiently to improve contrast while retaining bright/light-ness

At first glance, I'll note that "brightgreen" doesn't feel very bright anymore,

This was the first thing that jumped out at me as well. The other feeling I had reading back over this (and the issue) is that I can't visually differentiate between the changed green and brightgreen any more.
That may just be my screen and/or my eyes, and even though large chunks of the discussions went over my head, the reasoning and calculations behind those seem valid and reasonable so I'm definitely not objecting. That's just my human reaction with a "shields user" hat on that I can't readily tell the difference anymore.
I was trying to think of cases where we have badges with a default color scale that includes both, and I think that's largely found in places like rating/score and code coverage badges with a clear textual value that'll help (e.g. my green coverage badge with 99% coverage may have a background color I can't readily differentiate, but the 100 vs 99 percentage text would definitely avoid me misreading the badge)

While looking at another issue I noticed
https://github.com/badges/shields/blob/caea7597f9f6560c48854904be82c0999dcba7bd/services/licenses.js#L92
Just chucking a link to this here to remind myself when I get a chance to come back to this.

At first glance, I'll note that "brightgreen" doesn't feel very bright anymore,

This was the first thing that jumped out at me as well. The other feeling I had reading back over this (and the issue) is that I can't visually differentiate between the changed green and brightgreen any more.

I think there might be a bit of an iron triangle here. There are several properties we want to optimise for:

"brightgreen" should still look/feel bright
"brightgreen" and "green" should be noticibly different
there should be sufficient contrast between the text and background colours

and it is proving tricky to find a solution that achieves all 3 of those at the same time.
I guess one question here is: We've concentrated on calculating the contrast between the background and the text, but we haven't really looked at the contrast/difference between the different colours in the scale (at least not quantitatively). Is there any kind of guidance or formula we can use that might inform how different colours in a scale need to be in order to be sufficiently different from each other, accepting that they might not actually appear together?

That may just be my screen and/or my eyes

Yes. This is good feedback though. The entire point of this is to try and make stuff readable on a wider range of screens/eyes.

I was trying to think of cases where we have badges with a default color scale that includes both, and I think that's largely found in places like rating/score and code coverage

There are a number of palettes where we use "green" and "brightgreen" in the same colour scheme. If you have a look over https://github.com/badges/shields/blob/master/services/color-formatters.js but yeah coverage and ratings would be examples.

Is there any kind of guidance or formula we can use that might inform how different colours in a scale need to be in order to be sufficiently different from each other, accepting that they might not actually appear together?

Yes, and it'd be the same contrast algorithm as other parts. If there is enough color contrast between the two colors using whatever algorithm you choose, they're separate; if not, they would be considered as not being separate. The same APCA resources apcacontrast.com mentioned https://github.com/badges/shields/issues/5497#issuecomment-1885773006 can work in theory, except it looks like the website is down right now. 🥲

Here's another thought on the green/brightgreen thing.

We can make the green and brightgreen more different, but doing so requires making the brightgreen darker
We can make the brightgreen more bright, but doing so makes the green and brightgreen harder to distinguish

so.. what if this is telling us: this should be one colour?
What if we got rid of the distinction between green and brightgreen and the scale went

green
yellowgreen
yellow
orange
red

and brightgreen becomes a legacy alias for green
I feel like that requires a bit more of a lift because we change the number of possible buckets we can put a score into and we have to review any scale that currently uses both green and brightgreen. It might also make it more difficult to maintain 2 palettes. I've not completely thought that through, but what do we think of that as an idea? Just reduce the number of colours in the palette.

Just reduce the number of colours in the palette.

I think you're onto something here, though the devil will of course be in the details. I suspect there will also likely need to be a consideration of the different personas (persona A being a long time shield user who is accustomed to the prior palette and feel like their 100% coverage is visually "wrong", and persona B being a new user who's :+1: with the palette and appreciates the contrast and accessibility aspects)

It has been 6 months since I last worked on this branch, so it is not really fresh in my mind, but I will try and find some time to get my head back into this and see what's involved in reducing the colour palette so there is only one green.

OK. It has been a really long time since I looked at this, but I spent a bit of time combing though everything to work it out.
My assessment here is that going down to one green only matters where we define a colour scheme which includes both brightgreen and green. If we define a colour scheme that only includes one of those two colours, then it doesn't really matter.
There are 13 files where we define one or more colour schemes that include both brightgreen and green:

services/bugzilla/bugzilla.service.js
services/codacy/codacy-grade.service.js
services/codeclimate/codeclimate-analysis.service.js
services/codefactor/codefactor-helpers.js
services/color-formatters.js
services/mozilla-observatory/mozilla-observatory.service.js
services/ossf-scorecard/ossf-scorecard.service.js
services/puppetforge/puppetforge-module-endorsement.service.js
services/reuse/reuse-compliance-helper.js
services/scrutinizer/scrutinizer-quality.service.js
services/security-headers/security-headers.service.js
services/sonar/sonar-fortify-rating.service.js
services/test-results.js

..and then changing those has knock-on effects on tests. I think we would need to update tests in the following 8 files:

services/codefactor/codefactor-grade.spec.js
services/color-formatters.spec.js
services/dub/dub-download.tester.js
services/dub/dub-score.tester.js
services/greasyfork/greasyfork-rating.spec.js
services/mozilla-observatory/mozilla-observatory.spec.js
services/ossf-scorecard/ossf-scorecard.tester.js
services/website/website.tester.js

Within the places where we have palettes that use both brightgreen and green there are then 2 cases within that:

Schemes that use 5 colours or fewer: For example this 5 point scale uses both brightgreen and green https://github.com/badges/shields/blob/cf656d3a4d34faae1bea991ce1a55835ef550915/services/ossf-scorecard/ossf-scorecard.service.js#L9-L12 but we could substitute in orange to keep it as a 5-point scale.
Palettes that use 6 colours: For example this 6 point scale uses both brightgreen and green https://github.com/badges/shields/blob/cf656d3a4d34faae1bea991ce1a55835ef550915/services/codacy/codacy-grade.service.js#L41-L48 but if we collapse brightgreen and green into 1 we need to pick 2 of the 6 letters A-F and give them the same colour. More generally: we have to reduce the resolution of the scale.

When it comes to how to tackle this, I think there are 3 ways we can go:

Just alias brightgreen and green to the same hex code in the accessible palette, but keep them aliased to different colours in the legacy palette and call it a day. This is the quickest and simplest thing we can do. Also this would allow us to maintain the existing palette exactly as it is now alongside a new one where we alias the same words to the new palette. This is also the solution that yields the least useful results IMO as it basically takes the "best" and "second best" value/range and makes them both now the best, and this would indiscriminately apply to both cases (including where we could adjust the palette without adjusting the resolution). I am going to rule this one out.
Individually re-assess each case. There are not a huge number of cases to work though. We can make individual decisions about each scale. Keep 5 point (or fewer) scales where we can. If we have to go down from a 6 point scale to a 5, we can make a case by case decision about how to do it for each scale/service. This will yield more useful results to the user, but the downside is: If we wanted to maintain 2 palettes side-by side (including keeping 6-colour scales in all the cases where we currently use them for the "legacy" palette), this is way more complex. We have to pass make the "which palette are we using" variable available all the way down to the stack the service/helper layer or devise some mechanism to allow every colour scheme to define 2 variants, allow the service layer to pass them both up the stack and then make the decision about which one to use based on the "which palette are we using" variable. I don't really fancy doing either of those, although obviously if we decide we just want to rip the band aid off and change the palette this is a complete non-issue and we just do it.
If we decide we do want to maintain 2 palettes, then there is a halfway house option. First step would be to make another PR which adjusts all the colour scaled highlight above to stop using both brightgreen and green but in the existing (legacy) palette. So all 5 point (or fewer) scales we sub in another colour to take out green. All 6 point scales we reduce the resolution to a 5 point scale and still make an individual decision about how to do each one, but we haven't changed any colours yet. Then we could have one palette where green and brightgreen alias to the same hex code and another where they alias to different hex codes but it doesn't matter because there is no colour scheme where both green and brightgreen appear. That would allow the model where you have a "legacy" and "accessible" palette, but it means that the "legacy" palette isn't exactly what you have now because within that palette every 6 point scale has been reduced to a 5.

Coming back to this with fresh eyes and going through all this code has made me realise a couple of additional things.
The first one is relevant to this issue, and I'm going to chuck it into the mix here while we are still making decisions:
If we're going to reduce the number of colours in the standard palette in the name of improving contrast/accessibility, and we think we should go down from 2 greens to 1 green, should we also go down from 2 yellows to 1 yellow?
With completely fresh eyes on this: It seems to me that if brightgreen and green should reduce to just green, yellowgreen and yellow should also reduce to just yellow.
That gives us even fewer colours to play with in a good --> bad scale so we lose a lot of resolution. You've now got green/yellow/orange/red (so 4 point scale, max) and all of the above needs to be re-worked with yellow/yellowgreen as well ad brightgreen/green but it does feel like it gives you a lot more contrast and allows us wiggle room to pick a really nice yellow. Broadly the 3 process options still apply if we do that.
Is that too bold and radical?
The second one is a complete tangent and we don't need to solve it here, so I'm going to move it to another issue, but while I was working through all this stuff I found that there's a lot of places where colour scales are different for no good reasons. e.g: There are places where we're defining a 3 point good --> bad scale that is brightgreen/yellow/red and other places where we're defining a 3 point good --> bad scale that is brightgreen/orange/red and there is not really any good reason why they are different. This feels like something we can clean up, but lets not do it here. Going down to a max 4 point scale would clean this up a lot though as there is way less wiggle room. I'm going to move the discussion of that elsewhere.

I'm personally not sold on the idea of having two different colours palettes and supporting both via a URL parameter. I'd be in favour of just going ahead and making the changes presented in the PR description, possibly making brightgreen a little more bright and yellow a little less brown. We don't need to make things perfect, any change that improves legibility  is a win in my opinion.


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 847 ms

Resolved: Bofrost.at performance has improved in 1f6c87d.


The filtering of the variant list are not working correctly if the number of property groups is more than 500

PHP Version: 8.2   | Shopware Version: <IP_ADDRESS>  | Affected area / extension: Platform(Default)

Expected behaviour:
The filtering of variant list and storefront presentation modal shows all selected property groups.
Actual behaviour:
Some property groups are missing in the filtering of variant list.
How to reproduce:

Create a large number of property groups > 500
Generate variants in any product.
Some random property groups will be missing in the filtering of variant list and Storefront presentation modal also.

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-39196
[created from NEXT-39196, comment 505799]

[public]

Status Change: In Progress

Work on this issue has started. It is now being implemented.
[created from NEXT-39196, comment 509219]

[public]

Status Change: In Review

Work on this ticket is complete and is now pending review.
[created from NEXT-39196, comment 510122]

[public]

Status Change: Resolved

The ticket has been successfully completed; the solution is implemented and verified.
[created from NEXT-39196, comment 512478]

[public]

FixVersion Change: <IP_ADDRESS>

This issue will be / was solved in Shopware version <IP_ADDRESS>.
[created from NEXT-39196, comment 512480]


change the name of the last with statement

This is a:

[x] bug fix PR with no breaking changes — please ensure the base branch is master
[-] new functionality — please ensure the base branch is the latest dev/ branch
[-] a breaking change — please ensure the base branch is the latest dev/ branch

Description & motivation

Checklist

[x] I have verified that these changes work locally on the following warehouses (Note: it's okay if you do not have access to all warehouses, this helps us understand what has been covered)

[ ] BigQuery
[ ] Postgres
[ ] Redshift
[ ] Snowflake

[x] I have "dispatched" any new macro(s) so non-core adapters can also use them (e.g. the star() source)
[x] I have updated the README.md (if applicable)
[x] I have added tests & descriptions to my models (and macros if applicable)
[ ] I have added an entry to CHANGELOG.md

Hey @TimoKruth, thanks for this PR as well!
In the same vein as my comment on #420 - can you clarify what the motivation is for this change? The dbt Labs style guide is strongly in favour of a final CTE, so I'm not super excited about breaking that convention.
If Exasol has final as a reserved word (I don't have access to an instance so can't query EXA_SQL_KEYWORDS, it might be better to look into a "shim" package as detailed here.

Hi @TimoKruth, thanks for confirming it's a reserved word!
The style guide does call for final "or similar", but in practice it's overwhelmingly final.
It would theoretically be possible to have adapter-specific naming of the CTE, but would create a lot of extra overhead for a database that isn't in scope for dbt-utils. This is where a shim package would come in as discussed above!


Fix API GW CLI swagger config file support

The following error was observed when creating APIs with a swagger configuration file
error: Unable to create API: API route creation failure: {"error":"API configuration failure: {\"message\":\"Cannot read property 'indexOf' of undefined\"....

This PR fixes that failure.

PG3 86

@nwspeete-ibm FYI

@csantanapr - swagger test now added to the end-to-end health check

PG3 93 - failures in other tests

squashed and merged a1a40d18ff4f82faa60f11903d398555ac4befe9


Make past major releases publishable

Refine and implement https://github.com/swisspost/design-system/wiki/How-to-do-a-major-release for v6.

[x] Remove pnpm setup versions (read them from package.json)
[x] Fix netlify-cli to a specific version to ensure it can run also in 2 years

Merged to release/v6 branch


Error doing sudo apt update

sudo edit-chroot -all output:
name: focal
encrypted: no
Entering /media/removable/chromebook/crouton/chroots/focal...
crouton: version 1-20220111101058~master:a9eafaee
release: focal
architecture: arm64
xmethod: xorg
targets: xfce,audio,core,extension,gtk-extra,lxde,lxde-desktop,keyboard,kodi,xorg
host: version 14909.100.0 (Official Build) stable-channel hana
kernel: Linux localhost 4.19.246-13496-g49abd66ff4ba #1 SMP PREEMPT Sat Jul 30 19:30:51 PDT 2022 aarch64 aarch64 aarch64 GNU/Linux
freon: yes
Not unmounting /media/removable/chromebook/crouton/chroots/focal as another instance is using it.

(Yes, I know its running at the moment)
Please describe your issue:
E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/binary-i386/Packages  404  Not Found [IP: 2620:2d:4000:1::19 80]
E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/focal-updates/main/binary-i386/Packages  404  Not Found [IP: 2620:2d:4000:1::19 80]
E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/focal-security/main/binary-i386/Packages  404  Not Found [IP: 2620:2d:4000:1::19 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.

If known, describe the steps to reproduce the issue:
add wines apt repo and key

"binary-i386" should be "binary-arm64", given your reported architecture. check /etc/apt/sources.list and any files in /etc/apt/sources.list.d/

I removed the wine apt key, still no dice
cat /etc/apt/sources.list output:
deb http://ports.ubuntu.com/ubuntu-ports/ focal main restricted universe multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports/ focal main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ focal-updates main restricted universe multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports/ focal-updates main restricted universe multiverse
deb http://ports.ubuntu.com/ubuntu-ports/ focal-security main restricted universe multiverse
deb-src http://ports.ubuntu.com/ubuntu-ports/ focal-security main restricted universe multiverse

ls /etc/apt/sources.list.d/ output:
nothing was in there. (cricket noise)

So you're still getting the output from "apt update" showing that it's looking for "binary-i386"?
What commands did you run to set up the wine repo & key?
What is the output of
dpkg --print-architecture?

Output of dpkg --print-architecture gets me arm64

Now, I installed LXDE first, forgetting about the PID error (no I really don't wanna fix it). I uninstalled it, then reinstalled it using apt. Something weird to note is that there are at least 6 package managers in whisker menu. They are:
apply full upgrade
discover
packages
gdebi package manager
muon package manager
package updater

Are any of those going to mess stuff up?

I'm not familiar with LXDE, but I guess those utilities will all be using apt/dpkg under the covers, so I doubt they'd mess things up.
With your dpkg architecture correct (arm64) and the sources.list contents as you have reported, I really can't see why apt is looking for the i386 packages. But I'm not an expert.
This is not specifically a Crouton issue, and because things are pretty quiet on here these days, I suggest you search/ask a question on the Ubuntu forums, or search for a wiki on apt - the Debian one is quite good.
Good luck.

Alright, thank you. Have a good rest of your day/night.
Note: I'm actually using XFCE right now, and I deleted the lxde startup script.


php analyser not working

Hi
I am trying to run dependency check against a php project i have, and it does not seem to find anything.
Im running the folowing command:
dependency-check/bin/dependency-check.sh -s . --project phptest --disableCentral -f JSON --enableExperimental
Although it finds a composer.lock file, it does not analyse it (0 seconds)
[INFO] Finished Composer.lock analyzer (0 seconds)
Also the project report is empty. It does not even contain the dependencies
"projectInfo": {
"name": "phptest",
"version": "3.1.1",
"reportDate": "2019-02-12T15:31:53.087+0000",
"credits": {
"NVD": "This report contains data retrieved from the National Vulnerability Database: http://nvd.nist.gov",
"NSP": "This report may contain data retrieved from the Node Security Platform: https://nodesecurity.io"
}
},
"dependencies": []
}
Any idea what i might be doing wrong?
Thanks

Does the project use composer?  There is only PHP support when using composer.

Yes, there is a composer.lock file that has been detected
El El mié, 13 feb 2019 a las 10:24, Jeremy Long<EMAIL_ADDRESS>escribió:

Does the project use composer? There is only PHP support when using
composer.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jeremylong/DependencyCheck/issues/1723#issuecomment-463144317,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMK55t4uHcKd81edoaPytQTcXGSv6S75ks5vM-f1gaJpZM4a2uSX
.

For me nothing is found either. The symfony security checker reports 3 issues. Not sure if the same sources are used, but the two CVEs seem to be available at NVD and the dependencies are present in composer.lock.
Symfony Security Check Report
=============================

3 packages have known vulnerabilities.

symfony/form (v3.4.16)
----------------------

 * [CVE-2018-19789][]: Temporary uploaded file path disclosure

symfony/security (v3.4.16)
--------------------------

 * [CVE-2018-19790][]: Open Redirect Vulnerability on login

twig/twig (v2.5.0)
------------------

 * [CVE-NONE-0001][]: Sandbox Information Disclosure

[CVE-2018-19789]: https://symfony.com/cve-2018-19789
[CVE-2018-19790]: https://symfony.com/cve-2018-19790
[CVE-NONE-0001]: https://symfony.com/blog/twig-sandbox-information-disclosure

The HTML report is also empty, no dependencies are reported. The xml report does contain dependencies, but also no vulnerabilities.
Commandline:
dependency-check.bat -s c:\data\project\composer.lock --format ALL --project valentijn --enableExperimental

For me  it looks like hte composer analyzer is not running because DC thinks it's disabled.
2019-04-24 15:11:28,490 org.owasp.dependencycheck.utils.Settings:669
DEBUG - Setting: analyzer.composer.lock.enabled='true'
....
DEBUG - Scanning C:/Data/supplier-hub-symfony/composer*.json
2019-04-24 15:11:28,506 org.owasp.dependencycheck.App:345
DEBUG - Found file C:\Data\supplier-hub-symfony\composer.json
...
DEBUG - Loaded Analyzer Composer.lock analyzer
2019-04-24 15:11:28,566 org.owasp.dependencycheck.analyzer.AnalyzerService:115
...
2019-04-24 15:03:49,799 org.owasp.dependencycheck.Engine:824
DEBUG - Initializing Composer.lock analyzer
2019-04-24 15:03:49,799 org.owasp.dependencycheck.analyzer.AbstractAnalyzer:109
DEBUG - Composer.lock analyzer has been disabled
2019-04-24 15:03:49,799 org.owasp.dependencycheck.Engine:677
DEBUG - Skipping Composer.lock analyzer (not enabled)

I tried to add '--disableComposer "false"' but this has the same result, except that in first log line it now actually says it is disabling the composer analyzer (while the command line should result in it being enabled?)
dependency-check.bat -s "c:\data\project\composer*.json" -project valentijn -n --log output.log --enableExperimental --disableComposer "false"

	Line 30: DEBUG - Setting: analyzer.composer.lock.enabled='false'
	Line 52: DEBUG - Scanning C:/Data/supplier-hub-symfony/composer*.json
	Line 54: DEBUG - Found file C:\Data\supplier-hub-symfony\composer.json
	Line 112: DEBUG - Loaded Analyzer Composer.lock analyzer
	Line 287: DEBUG - Initializing Composer.lock analyzer
	Line 289: DEBUG - Composer.lock analyzer has been disabled
	Line 291: DEBUG - Skipping Composer.lock analyzer (not enabled)
	Line 425: DEBUG - Closing Analyzer 'Composer.lock analyzer'


Update Embedding.Vector property to a method

As per the Arch Board discussion, this PR converts the Embedding.Vector property into the Embedding.ToFloats() method. This change makes it easier to apply EB.Never to the method and allows for the future use of the EmbeddingVector type for the vector property.

CC: @tg-msft


Enable results straight to S3

@suhlrich I had to create a new PR. Please make sure that it is the only things that you needed to add.

@suhlrich go ahead and merge this one if you have tested it.


[python] Update coordinate space <-> JSON converters

Update transform_from_json and transform_to_json to support additional CoordinateSpace types UniformScaleTransform and ScaleTransform
Correct error message in PointCloud.coordinate_space setter

Thanks! We'll need to add these changes to the main branch now too.

Does that mean I should merge this into main instead of spatial?

These changes are needed for #3110. I have these commits merged into that branch too.

Thanks! We'll need to add these changes to the main branch now too.

Does that mean I should merge this into main instead of spatial?

It should be merged into both.


Install the config

Could you explain the details? Also, which CMake version did you target (cpuinfo currently targets CMake 2.8, but we can update it to 3.5. Going above 3.5, however, would be hard as some cpuinfo users target 3.5)

Definitely not above 3.5. I think 3.0.

Just a note: If you set the Travis CI to use the version of CMake you desire, then you never need to worry about compatibility -- it would fail to compile.
It is compiling so I suppose Travis CI CMake is new enough.


New page type selector

Creates a pane to give writers options for creating pages of various types:
https://trello.com/c/3OIIu04o/6-m-ability-to-select-a-layout-when-creating-a-new-page
Updated the way the panes are generated. Pane templates are located at the bottom of the template.nunjucks and then cloned and populated as needed.

Coverage increased (+0.5%) to 86.248% when pulling 73d8e509fcea3d350bfd8c8df7b63495db9f2a03 on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

Coverage decreased (-50.2%) to 35.574% when pulling 18013ef6f7f498a53aef0ce7e3f0f2c38cc078f9 on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

Coverage increased (+0.5%) to 86.248% when pulling bc5b7e19e2dbd2d0301dfb042115f671443ee6fa on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

Coverage increased (+0.5%) to 86.268% when pulling 0942b4c6257d0172000dbd6bc06412a4ab374848 on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

Coverage increased (+0.5%) to 86.268% when pulling 91aafff6af53b30f2df96e07af2982aa70181caa on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

+1. Looks like the branch needs to be rebased.

Coverage decreased (-50.2%) to 35.548% when pulling 5123b873250fe40417f666ed428d690d142bc06a on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

ha, beware of the only

Coverage increased (+0.5%) to 86.262% when pulling 7c9953d9d54cb53952034ef4be992e1e2bbe2083 on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

Coverage increased (+0.5%) to 86.262% when pulling b92252ff5f4d052263ac3ce94524335ae5a40926 on new-page-type-selector into bfd1f7169ebe023a7372d5bc2f6e8a911af916ca on master.

Coverage decreased (-0.5%) to 85.156% when pulling b59bce9ca87098288b878dae3c6fc7e1ad480371 on new-page-type-selector into 4a3eea134f31741d5f1a7c01ffd2d15899621e5a on master.


Please Provide Documentation/Make Example More Accessible

Two requests:

Could you please provide documentation on how to use feathers-swagger?  The instructions listed on the GitHub page are rather deficient (eg. they don't mention the example.html file, or anything about the public directory at all, but having a publicly-served example.htm file is critical to actually being able seeing the generated documentation)

Could you please replace the Bower references on the example file with CDN versions?  This would make it so that anyone could use example.htm "out of the box" instead of having to setup an entire client side environment (with Bower, jQuery, Backbone, Handlebars, etc.).

... or better yet, if you could provide a "base HTML file" that anyone could use to get (even an extremely basic) UI "out of the box", that would be really great.  In fact, anything at all you can do to make it so that users can:

npm install feathers-swagger
add documentation to their feathers server/service
not have to do anything else
see web-based documentation of their server/service

that would be awesome.

We would be happy about any contributions if you are interested in helping to maintain this plugin. This module hasn't been updated in three years and is not actively maintained at the moment. There are plans to bring it up to date eventually but the core team only has very limited resources available so any contributions will help to make it happen sooner.

This module hasn't been updated in three years and is not actively maintained at the moment.
Ah, I didn't realize.  Thanks.

You might want to consider putting that on the project's GitHub front page; no point in misleading people in to using an inactive library.


When loading local terrain with cesium for ue, some hierarchical iamge tiles may be lost

then when I set source "From Ellipsoild", is normal:

It sounds like there is something wrong with your local tileset. Are there any messages in the Output Log?


Missing Core API's (DB exist)

The following tables exist but there are no corresponding APIs.
Required Action: Need to create APIs for the following:
-Class
-ClassMapping
-ClassModule
-Faculty
-Offering
-Registration
-Semester
-StudentProgram
Note - Required testing, After development

I have Developed all these APIs @mqpasta  closing this issue


Nitpicks, typo's and some language errors

Thanks @rmarx but made these changes (well most of them!) outside of this PR.


[Kubic project] Add packages for Ubuntu 20.04 distributions

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Description
The Ubuntu 20.04 was released, but there is no podman package for it currently: https://build.opensuse.org/repositories/devel:kubic:libcontainers:stable

Describe the results you expected:
Packages for Ubuntu 20.04
@lsm5 I saw you added the support for the Ubuntu 19.10. So I am pinging you here. Thanks.

@floating-cat yes we'd like to see that as well but that's blocked on the OBS infra admins setting up 20.04 repos.

https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04 returns 404

https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04 returns 404

https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable
@alitvak69 OBS people have setup the 20.04 envs, but it doesn't look like it's been done correctly yet, as I see find: command not found errors. I'll ping them tomorrow.

20.04 is ready now for x86_64 with other arches except ppc64le being built. Checking with admins about ppc64le setup.

Please re-open if you notice any issues...


Board is showing twice.

After a player makes his turn then board is showing twice in the game.
Do necessary changes to display it one time

Can I do it?

ok @Prem-Mittal


Change download directory to support linux

Change download directory to support linux. Create .gitignore file to ignore video_download directory.

Thank you !:heart:


Gnvim crashes outside Nixos

Describe the bug
Gnvim crashes when editing files seems due to missing svg libraries according to this issue
Notify maintainers
@minijackson
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.8.3-300.fc33.x86_64, Fedora, 33 (Thirty Three Prerelease)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.7
channels(root): "nixpkgs-20.09pre239581.1c014d4a0ec"
channels(me): "home-manager"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixpkgs

That's a common problem with all opengl apps, see https://github.com/guibou/nixGL

Generally the applications having problems with opengl don't even launch outside Nixos. The Issue is happening due to missing librsvg libs so wouldn't adding that as dependency solve the issue?

I said that because of
Cannot get default EGL display: EGL_BAD_PARAMETER
WaylandCompositor requires eglCreateImage and eglDestroyImage.
Nested Wayland compositor could not initialize EGL

But you are right, I had not realized that gnvim actually successfully starts.


ReLU6 issue

Some Mobilenet v1 utilize ReLU6 as the activation function.  If I replaced ReLU6 with ReLU, the accuracy drop is obvious even I didn't do any compensation and quantization.  Do you have any comment on such situation?

That probably means the value of those layers are truly bounded by the ReLU6. Maybe you can check the feature value of those layers.


setup jest and webpack

Hey @mosidrum , In this Pr I've done these tasks:

Setup webpack;
Setup Jest;
Create the Readme.md file;
Setup files structure;
Setup linters

Thank you for the review. But since we are using image URLs provided by a CDN rather than images files, we don't need an image loader in the Webpack configuration

APROVED.. :ok_hand:
Let's move to the next task


🐛 False positive unused export for barrel like file

Prerequisites

[X] I'm using the latest version
[X] I've read the relevant documentation
[X] I've searched for existing issues
[X] I've checked the list of known issues
[X] I've read the issue reproduction guide

Reproduction url
https://stackblitz.com/edit/github-99dfwi73-hxo2rmv8?file=index.ts
Reproduction access

[X] I've made sure the reproduction is publicly accessible

Description of the issue
Observed behavior
The example produces:
Unused exports (1)
bar  mod1  function  mod1.ts:5:17

while bar is actually used in index.ts.
Expected behavior
No error

Thanks for the repro. Personally I wouldn't call this "barrel-like", btw.
Either way, it's a bit of an unfortunate case:

By default, Knip assumes all members of mod1Exports used because of the default heuristics: https://knip.dev/guides/namespace-imports
Then there's --include nsExports but the destructured ...mod1Exports is something Knip is unable to follow further.
And there's --include-libs to hand it over to TypeScript internals (which should be documented better for this use case), but even LS.findReferences doesn't find it. You could verify in your IDE with a "Find All References" from export function bar: this won't bring you to it's usage.

Yeah, didn't a more fitting term for this construct. However IntelliJ is able to follow along this usage path, but it might use an internal heuristic there.

In case someone runs into the same issue: I found a workaround now that is also understood by knip.
I replaced the export const AllExports = { ...mod1Exports,  ...mod2Exports }; with an intermediate module (AllExports.ts) that re-exports all the symbols.
export * from './mod1';
export * from './mod2';

and then export * as to export those as a namespace.
export * as AllExports from './AllExports';


PhysicalOptimizer rule 'ProjectionPushdown' failed, due to generate a different schema

Describe the bug
Found in PR #8840.
When no projection is pushed down to TableProvider, the physical optimization rule ProjectionPushdown may fail.
I think the root cause is in this function, when the source parameter is None.
https://github.com/apache/arrow-datafusion/blob/8a4bad46540598c6acdf432bde08c2a4c76c5039/datafusion/core/src/physical_optimizer/projection_pushdown.rs#L834-L837
To Reproduce
There may be some complex queries that can reproduce the problem.
But the simplest way is to disable projection pushdown during the logical optimization phase.
DataFusion CLI v35.0.0

❯ create table t(a int, b int);
0 rows in set. Query took 0.007 seconds.

❯ set datafusion.optimizer.max_passes=0;
0 rows in set. Query took 0.002 seconds.

❯ select a from t;
ProjectionPushdown
caused by
Internal error: PhysicalOptimizer rule 'ProjectionPushdown' failed, due to generate a different schema,

original schema: Schema { fields: [Field { name: "a", data_type: Int32, nullable: true, dict_id: 0, dict_is_ordered: false, metadata: {} }], metadata: {} },

new schema: Schema { fields: [], metadata: {} }.

This was likely caused by a bug in DataFusion's code and we would welcome that you file an bug report in our issue tracker

Expected behavior
No response
Additional context
Not only MemoryTable, others like CsvTable also have the same problem.

cc @berkaysynnada


Add support for phi-3-vision-128k-instruct

As per #28

Oh wow, thanks! Will do right away.

Thanks for updating the test cases!
Looking at the model structure, I think we can sanitize the weights to create the following structure:
Model

language_model
vision_model -> vision_embed_tokens

This way we'll have a single structure:
class Model(nn.Module):
    def __init__(self, config: ModelConfig):
        self.model_type = config.model_type
        self.config = config

        self.vision_model = VisionModel(config.vision_config)
        self.language_model = LanguageModel(config.text_config)

    def __call__(
        self,
        inputs: mx.array,
        pixel_values=None,
        image_sizes=None,
        cache=None,
    ):
       h = self.language_model.embed_tokens(inputs)
       p = np.argwhere(inputs < 0).tolist()
       if pixel_values is not None:
            h = self.vision_model(pixel_values, h, image_sizes, p)
       return self.language_model(h)

Example: https://github.com/Blaizzy/mlx-vlm/blob/main/mlx_vlm/models/nanoLlava/nanoLlava.py#L240

Hey @JosefAlbers
Any updates?

@Blaizzy sorry, not yet.

Hey @JosefAlbers
Any updates?

Hi @Blaizzy, Thanks again for the feedback and for patiently guiding me through this process. I apologize for the delay in responding.
After further reflection on the proposed model restructuring, however, I believe it might be more practical to defer this change for a future iteration. While I see the value in standardizing the model structure across the repository, the current structure aligns better with the original Phi-3-Vision model implementation, and maintaining this alignment could be beneficial in the short term.
My primary reason is to prioritize getting this model available for users as quickly as possible. There already are many newer and possibly better VLM models than Phi-3-Vision at this point (e.g., Kosmos-G, Florence, ...), and introducing a structural change now could potentially delay the merge, as it would require additional testing to ensure everything still functions as expected. I'd propose the following approach:

Merge the model in its current state.
Add a note to the issue tracker or project roadmap highlighting the potential for future refactoring to align with other models in the repository.

This would allow us to revisit the structure at a later time when we have more bandwidth for potential adjustments and testing. I'm open to discussing this further and collaborating on the best path forward. Please let me know your thoughts on this approach.
Lastly, I want to thank you again for the great codes you've been writing in this repository. Your work has been an invaluable learning resource for me.

Most welcome!
Ayt, we can merge it and then update it.
Before that, can you rebase your branch and test it still works as expected.

@Blaizzy, Yeap, got a new branch rebased it up to date, copy pasted files from original to the new rebased branch, ran precommits and tests. I'm pretty exhausted at this point..🤞🏾

Please rebase this branch with the main to fix the conflicts, run the tests and precommit.
pytest .
pre-commit run --all-files

Sorry for the silly error, I realize I might have not pushed after running the pre-commit on my local machine. I fixed them.

Thank you very much @JosefAlbers for your hard work! 🎉👏🏾
We got some more models to port here: https://github.com/Blaizzy/mlx-vlm/issues/39

@JosefAlbers what's your twitter handle?

@Blaizzy You're very welcome, I'm just happy to help this awesome project grow. And I can't wait to see these new model ports in action!

Thank you very much!
You are an absolute legend 👏🏾
Please feel free to share more suggestions or pick any of the good first issues.
I'm currently working on the trainer 🚀


KEP-1397: descheduler integration with evacuation API as an alternative to eviction API

Is your feature request related to a problem? Please describe.
The descheduler eviction policy is built on top of the eviction API. The API currently does not support eviction requests that are not completed right away. Instead, any eviction needs to either succeed or be rejected in response. Nevertheless, there are cases where an eviction request is expected to only initiate eviction. While getting confirmation or rejection of the eviction initiation (or its promise).
Describe the solution you'd like
Utilize evacuation API as an alternative to eviction API. As an interim solution (until the evacuation API is available) allow to interpret pods with a special annotation as a request for eviction initiation instead of expecting an immediate eviction.
Resolves: https://github.com/kubernetes-sigs/descheduler/issues/1397

Hi, @ingvagabund . I have a question about how does this KEP works in Descheduling Framework.

Do you expect to use this new eviction handling mechanism to replace existing PodEvictor （who call Eviciton API directly）, so that all users evict their pods through it?
Do you consider to take one more step to make it as a extension point, e.g. Evict, so that users can decide which way to evict their pods, and existing PodEvictor or your extension by this KEP can both be implemented as a EvictPlugin(different with existing EvictorPlugin)?

@songtao98 thank you for asking the right questions.

Do you expect to use this new eviction handling mechanism to replace existing PodEvictor （who call Eviciton API directly）, so that all users evict their pods through it?

Eventually, that's the ultimate goal. However, the first implementations will provide both eviction API and evacuation API. So we have some soft time for early adopters to share their experience and corner case for which evacuation API does not work/scale well. Followed by discussions with evacuation API designers about possible resolutions before the new API goes GA.

Do you consider to take one more step to make it as a extension point, e.g. Evict, so that users can decide which way to evict their pods, and existing PodEvictor or your extension by this KEP can both be implemented as a EvictPlugin(different with existing EvictorPlugin)?

Not right now. Ultimately, the new evacuation API should be a special case of the eviction API. The details are yet to be discussed.

thank you for asking the right questions.

@ingvagabund Thank you for your reply! For question 1, the strategy sounds great. For question 2, I'm not sure if someone has ever proposed a custom Evictor mechanism(to customize the real evictor like PodEvictor, not currently EvictorPlugin), but we think this capability will eventually be meaningful and already implemented one. We are also looking forward to more discussion about details, and if the community think it's the right way, we will be more than happy to contribute : )

We think this capability will eventually be meaningful and already implemented one. We are also looking forward to more discussion about details, and if the community think it's the right way, we will be more than happy to contribute : )

Few sig calls back we discussed the possibility of writing mini-keps. Turning the low level eviction mechanism into a plugin is a good example for it :) If there are good use cases where a user can benefit from a custom eviction mechanism. Would you be willing to write a proposal for this? The current proposal focuses mainly on integration with the new evacuation API (and annotation as an interim solution). Pluginazing the evictor itself is related, yet it deserves its own attention.

Few sig calls back we discussed the possibility of writing mini-keps. Turning the low level eviction mechanism into a plugin is a good example for it :) If there are good use cases where a user can benefit from a custom eviction mechanism. Would you be willing to write a proposal for this? The current proposal focuses mainly on integration with the new evacuation API (and annotation as an interim solution). Pluginazing the evictor itself is related, yet it deserves its own attention.

For sure! We are certainly willing to draft a proposal for customizing the eviction mechanism. However, it might take some time as I need to organize some details and perform the necessary abstractions. BTW, regarding the mini-keps you mentioned, are there any specific format requirements? If not, I will follow the current KEP template.

BTW, regarding the mini-keps you mentioned, are there any specific format requirements? If not, I will follow the current KEP template.

We don't have any dedicated template for the mini-keps atm. I have utilized the upstream k8s template (which might put the bar too high). Nevertheless, I find it quite useful. Even filling in the parts that seem to be too far away from the descheduler project. Yet, they help me to ask myself questions that are important to answer. Let's use the upstream template for now until we find a better one.

Hey, this is something that I'm interested in also. The idea of Descheduler evicting Kubevirt VM pods to Live Migrate then will help a lot the community.

Hey @gcezaralmeida, I'd be interested in hearing more about your use cases. Happy to extend the proposal with other use cases if you have any in mind.

Do we consider the alpha implementation here to be an workaround until the until the evacuation API is fully integrated (in the future, in beta)?
I understand trying to deliver value earlier and then already start to get feedback, but have you checked with Feature Requesters and stakeholders if that is really what they want? Maybe it makes sense to start with the evacuation API integration from the start.

In Filip's proposal (I need to read it in more detail, but I skimmed it already), there is this notion for Evacuator Prioritization and multiple evacuators (and a lot of other details not considered here). To me it sounds like when going from alpha implementation (here) to beta, and trying to assimilate the other complexities from the real evacuator API too much would change to call the graduation here a graduation from alpha to beta? Maybe it would be another alpha for a while before becoming beta? (or, again, as above comment, it would be worth to consider all those things from the start...)

This looks great and is very detailed. I need to read both proposals a bit more deeply to give more insights, but wanted to give my initial thoughts so the KEP can go forward

Do we consider the alpha implementation here to be an workaround until the until the evacuation API is fully integrated (in the future, in beta)?
I understand trying to deliver value earlier and then already start to get feedback, but have you checked with Feature Requesters and stakeholders if that is really what they want? Maybe it makes sense to start with the evacuation API integration from the start.

FIY, we are still discussing the Evacuation API feature and it was deferred from 1.31

In Filip's proposal (I need to read it in more detail, but I skimmed it already), there is this notion for Evacuator Prioritization and multiple evacuators (and a lot of other details not considered here). To me it sounds like when going from alpha implementation (here) to beta, and trying to assimilate the other complexities from the real evacuator API too much would change to call the graduation here a graduation from alpha to beta? Maybe it would be another alpha for a while before becoming beta? (or, again, as above comment, it would be worth to consider all those things from the start...)

Currently, the promotion to beta requires implementation of the evacuation API. Thus, we need to stay aligned with it and can not promote to beta until the evacuation API is beta.

Do we consider the alpha implementation here to be an workaround until the until the evacuation API is fully integrated (in the future, in beta)?

Yes

I understand trying to deliver value earlier and then already start to get feedback, but have you checked with Feature Requesters and stakeholders if that is really what they want? Maybe it makes sense to start with the evacuation API integration from the start.

I did. This is an important feature for KubeVirt. There's a strong interest to have this feature merged sooner than later. Waiting until the Evacuation API is implemented/alpha would be the best course of actions. Yet, it's not a blocker for implementing the first alpha of this feature.

I know it is not a blocker. I see it more from the frame of:
Is this delivering enough value when implemented as a workaround to justify not waiting for the actual thing that you want to use? Is the feedback and initial users you will get now be worth implementing this, even if the thing will be quite different when the Evacuation API is here (in beta or when it is safe to use it or w/e)?

Is this delivering enough value when implemented as a workaround to justify not waiting for the actual thing that you want to use? Is the feedback and initial users you will get now be worth implementing this, even if the thing will be quite different when the Evacuation API is here (in beta or when it is safe to use it or w/e)?

Disclaimer: this is my personal comment and it does not have to reflect the current reality.
We don't have any participating initial users besides the discussions I have had with some KubeVirt representatives. So currently there's only one user. The feedback is currently limited and influenced by the evacuation API proposal. I don't have any solid data to support anything I have proposed in the current proposal. The design was crafted in a best-effort manner in my best conscience. Taking into account many what-if scenarios. We still don't have many participating contributors in the descheduler community to extend the discussions/reviews and hand craft a better design. Practically, any contribution from my side is done either in my free time of when I prioritize my work in my current company.
I am aligned with your perspective and acknowledge you asked the right and important questions. I see two options. To wait (hard to say for how long) and collect more feedback with an assumption the design will improve. Or, pin the current design, produce v1alpha1 implementation, collect the feedback and see how well/bad the design proved the be.

We still don't have many participating contributors in the descheduler community to extend the discussions/reviews and hand craft a better design

You focus on the design reviews not being comprehensive for lack of contributors, but that is actually an argument to wait, no? Since if you consider the repo to have less support than it needs it would be harder to maintain a workaround than it would be to maintain what you envision to be the final implementation (that would also start at alpha, but would not have big changes of core internals).

To wait (hard to say for how long) and collect more feedback with an assumption the design will improve. Or, pin the current design, produce v1alpha1 implementation, collect the feedback and see how well/bad the design proves the be.

I also see these two options, and I see pros and cons coming from both of them. I think the workaround design is great, I wouldn't consider it to be bad. I think it was detailed and a lot has been considered. Just raised this discussion to be the devil's advocate and check other paths.

with an assumption the design will improve

But you also assume that, or the goal of migrating to the intended final implementation using the actual evacuation API (and ditching the previous one) would not be written down here in you EP.

Reading the great discussion here! To me, the proposal looks good, and thank you for this effort!

This is an important feature for KubeVirt -> but how urgent, I think that's the question. Also, do they know of the plan to migrate later to the evacuation API approach? Would they explicitly prefer not to wait, or did they just say they need it asap?

Answering this question: Yes, this is an essential feature for KubeVirt.
Let's start from the beginning: live migration is a key feature of KubeVirt; it allows the workload not to be compromised. For this reason, it is chosen as the default behavior during an eviction, drain, etc...
KubeVirt is also shipped by default with Openshift, and currently, Descheduler and KubeVirt behavior are not compatible with each other. Without this workaround, a cluster admin would have to choose between having an active KubeVirt core feature and the Descheduler, and this would put them in a difficult situation that would be best avoided.
As expressed above this is a workaround that will be overridden with the evacuation API and KubeVirt will move to the evacuation API accordingly.
IOW, yes, KubeVirt side it would definitely be better to have this ASAP.
Thank you!

Reading the great discussion here! To me, the proposal looks good, and thank you for this effort!

This is an important feature for KubeVirt -> but how urgent, I think that's the question. Also, do they know of the plan to migrate later to the evacuation API approach? Would they explicitly prefer not to wait, or did they just say they need it asap?

Answering this question: Yes, this is an essential feature for KubeVirt. Let's start from the beginning: live migration is a key feature of KubeVirt; it allows the workload not to be compromised. For this reason, it is chosen as the default behavior during an eviction, drain, etc... KubeVirt is also shipped by default with Openshift, and currently, Descheduler and KubeVirt behavior are not compatible with each other. Without this workaround, a cluster admin would have to choose between having an active KubeVirt core feature and the Descheduler, and this would put them in a difficult situation that would be best avoided. As expressed above this is a workaround that will be overridden with the evacuation API and KubeVirt will move to the evacuation API accordingly. IOW, yes, KubeVirt side it would definitely be better to have this ASAP. Thank you!

Thanks! Having your direct input here is important. Thanks for chiming in!

I am currently refactoring the current code base so at the end the changes required to implement v1alpha1 of this KEP are minimal. The current PoC is under https://github.com/ingvagabund/descheduler/tree/eviction-in-background-code-2024-07-02.

/approve

Thank you Mike for going through the proposal.

Should we have any continued support for direct eviction requests? Or is eviction going away entirely?

@atiratree will know better though based on my understand the eviction API will not go away. Instead, users will still have option to choose between the evacuation (delayed eviction) and the eviction APIs. Yet, with strong recommendation to prefer the evacuation API as it will serve as a cluster scoped coordinator for any eviction.
Wrt. to https://github.com/kubernetes-sigs/descheduler/issues/1253 we will need to decide whether the descheduler will eventually switch to the evacuation API by default or not. Yet, we will still keep the direct eviction API and any potential immediate deletion configurable. It will take some time before the evacuation API becomes GA.

@atiratree will know better though based on my understand the eviction API will not go away. Instead, users will still have option to choose between the evacuation (delayed eviction) and the eviction APIs. Yet, with strong recommendation to prefer the evacuation API as it will serve as a cluster scoped coordinator for any eviction.

@ingvagabund yes the eviction API is not going away. A better version of it (e.g. Evacuation API, etc.) is still being discussed upstream in sig-apps and should eventually be used by all the major components like the descheduler, cluster autoscaler, etc. Normal users do not really use eviction much.

in accordance with the above consensus
/lgtm


Niger on the map links to the Netherlands

Please fix.

I suggested a change to fix this issue, could however be that you have a master spreadsheet yourself that hosts the error. The country code of the Netherlands is NL, not NE.