text:
prepareTempProfile id with Firefox breaks default configuration

I may be using this incorrectly, but I ran into a problem trying to modify the default configuration by adding Firefox preferences. Using prepareTempProfile with id breaks the browser.
When I run the code (that I think demonstrates the problem in the minimal way) below with workingBrowser, Firefox opens and shows Google. When I run it with notWorkingBrowser I get.
*** Exception: ResponseTimeout

And here is the output from the selenium standalone server:
	at org.openqa.selenium.firefox.internal.NewProfileExtensionConnection.start(NewProfileExtensionConnection.java:112)
	... 19 more
17:39:09.942 WARN - Exception: Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms. Firefox console output:
e/extensions/webdriver-staging
1483234705056	addons.xpi	INFO	Mapping fxdriver@googlecode.com to /tmp/anonymous3561515299500743470webdriver-profile/extensions/fxdriver@googlecode.com
1483234705057	addons.xpi	INFO	SystemAddonInstallLocation directory is missing
1483234705058	addons.xpi	INFO	Mapping webcompat@mozilla.org to /nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/webcompat@mozilla.org.xpi
1483234705058	addons.xpi	INFO	Mapping e10srollout@mozilla.org to /nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/e10srollout@mozilla.org.xpi
1483234705058	addons.xpi	INFO	Mapping firefox@getpocket.com to /nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/firefox@getpocket.com.xpi
1483234705058	addons.xpi	INFO	Mapping aushelper@mozilla.org to /nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/aushelper@mozilla.org.xpi
1483234705059	addons.xpi	INFO	Mapping {972ce4c6-7e08-4474-a285-3208198ce6fd} to /nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
1483234705060	addons.xpi	DEBUG	checkForChanges
1483234705061	addons.xpi	DEBUG	Loaded add-on state from prefs: {}
1483234705061	addons.xpi	DEBUG	New add-on fxdriver@googlecode.com in app-profile
1483234705062	addons.xpi	DEBUG	getModTime: Recursive scan of fxdriver@googlecode.com
1483234705064	addons.xpi	DEBUG	New add-on webcompat@mozilla.org in app-system-defaults
1483234705065	addons.xpi	DEBUG	getModTime: Recursive scan of webcompat@mozilla.org
1483234705065	addons.xpi	DEBUG	New add-on e10srollout@mozilla.org in app-system-defaults
1483234705066	addons.xpi	DEBUG	getModTime: Recursive scan of e10srollout@mozilla.org
1483234705066	addons.xpi	DEBUG	New add-on firefox@getpocket.com in app-system-defaults
1483234705066	addons.xpi	DEBUG	getModTime: Recursive scan of firefox@getpocket.com
1483234705067	addons.xpi	DEBUG	New add-on aushelper@mozilla.org in app-system-defaults
1483234705067	addons.xpi	DEBUG	getModTime: Recursive scan of aushelper@mozilla.org
1483234705068	addons.xpi	DEBUG	New add-on {972ce4c6-7e08-4474-a285-3208198ce6fd} in app-global
1483234705068	addons.xpi	DEBUG	getModTime: Recursive scan of {972ce4c6-7e08-4474-a285-3208198ce6fd}
1483234705068	addons.xpi	DEBUG	getInstallState changed: true, state: {"app-profile":{"fxdriver@googlecode.com":{"d":"/tmp/anonymous3561515299500743470webdriver-profile/extensions/fxdriver@googlecode.com","st":1483234704000,"mt":1483234704000}},"app-system-defaults":{"webcompat@mozilla.org":{"d":"/nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/webcompat@mozilla.org.xpi","st":1000},"e10srollout@mozilla.org":{"d":"/nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/e10srollout@mozilla.org.xpi","st":1000},"firefox@getpocket.com":{"d":"/nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/firefox@getpocket.com.xpi","st":1000},"aushelper@mozilla.org":{"d":"/nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/features/aushelper@mozilla.org.xpi","st":1000}},"app-global":{"{972ce4c6-7e08-4474-a285-3208198ce6fd}":{"d":"/nix/store/fzl12qd0ycpisc0v7k6733ij619gyg1q-firefox-unwrapped-50.0.2/lib/firefox-50.0.2/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi","st":1000}}}
1483234705077	addons.xpi-utils	DEBUG	Opening XPI database /tmp/anonymous3561515299500743470webdriver-profile/extensions.json
1483234705078	addons.xpi-utils	DEBUG	New add-on fxdriver@googlecode.com installed in app-profile
*** Blocklist::_loadBlocklistFromFile: blocklist is disabled
None of the following is a 64-bit version of Xlib: /usr/lib/libX11.so.6
 /usr/lib/x86_64-linux-gnu/libX11.so.6
 /usr/lib/i386-linux-gnu/libX11.so.6
 /usr/lib64/libX11.so.6
 /usr/lib32/libX11.so.6

Here is the code:
import Test.WebDriver
import Test.WebDriver.Firefox.Profile

workingBrowser = useBrowser (firefox { ffProfile = Nothing}) defaultConfig

notWorkingBrowser = do
  profile <- prepareTempProfile id
  return $ useBrowser (firefox { ffProfile = Just profile}) defaultConfig

main = do
  b <- notWorkingBrowser
  -- runSession workingBrowser $ do
  runSession b $ do
    openPage "https://www.google.com"

Environment:
webdriver-0.8..4
ghc 7.10.3
Linux laptop1 4.9.0 #1-NixOS SMP Sun Dec 11 19:17:54 UTC 2016 x86_64 GNU/Linux
nixos 16.09 unstable (can provide hash of nixpkgs and configuration if needed)

is the issue specifically with using id or do other functions work here?

Based on the error message it looks like something is wrong with your environment. Firefox is looking for a 64-bit Xlib but can't find one.

is the issue specifically with using id or do other functions work here?

I've tried using other functions that actually modify profile configuration and they fail too.

Based on the error message it looks like something is wrong with your environment. Firefox is looking for a 64-bit Xlib but can't find one.

Right, but why does it work with useBrowser, but fails with identity passed to prepareTempProfile? Somehow prepareTempProfile is doing something different with the configuration?

Yes, it's possible that the way profiles are handled in newer versions of Selenium has changed. Some time will need to be spent investigating the official APIs to see how they differ in this regard.

Hi, i got a similar problem. The browser loads and everything works, but the extension is just not installed.
Any idea why?

authors: dataO1 kallisti-dev ryantm

repo: kallisti-dev/hs-webdriver


text:
exists() references methods that are not imported

In models.py on line 76:
@staticmethod
def exists(name):
    return cache.exists(Experiment.key_for_name(name))

I believe you want a "import cache" line at the beginning of the file. In addition the import logging line at the top of models.py is not used.

Are you using this function? I'm partially tempted to remove it.
On Sat, Feb 4, 2012 at 11:38 PM, Kevin Burke <
reply@reply.github.com

wrote:

In models.py on line 76:
@staticmethod
def exists(name):
return cache.exists(Experiment.key_for_name(name))
I believe you want a "import cache" line at the beginning of the file. In
addition the `import logging

Reply to this email directly or view it on GitHub:
https://github.com/kamens/gae_bingo/issues/8

No I'm not. My editor just red-flagged it and I thought I'd report it.
--
Kevin Burke | Twilio
phone: 925.271.7005 | kev.inburke.com
On Wed, Feb 8, 2012 at 11:45 AM, Ben Kamens <
reply@reply.github.com

wrote:

Are you using this function? I'm partially tempted to remove it.
On Sat, Feb 4, 2012 at 11:38 PM, Kevin Burke <
reply@reply.github.com

wrote:

In models.py on line 76:
@staticmethod
def exists(name):
return cache.exists(Experiment.key_for_name(name))
I believe you want a "import cache" line at the beginning of the file. In
addition the `import logging

Reply to this email directly or view it on GitHub:
https://github.com/kamens/gae_bingo/issues/8

Reply to this email directly or view it on GitHub:
https://github.com/kamens/gae_bingo/issues/8#issuecomment-3874533

source: gharchive/issue

authors: kamens kevinburke

license: mit

license_type: permissive

license_source: bigquery


text:
Auth0 Example

Looking for an auth0 example since it's defacto authentication platform nowadays

I've an basic example of authentication using Auth0, I still do not have a solid architecture and can improve, but I hope it will guide you.
Preview:

Just for tracking, it was mention on #6 to have an examples showcase section. This could be included there as well. We can close this.

Thanks @cdiaz

@cdiaz provides a web application example, but what about an API example?

There's an API example from auth0 https://auth0.com/blog/full-stack-typescript-apps-part-1-developing-backend-apis-with-nestjs/
It's just really out of date.

I actually ended up making an example myself: https://github.com/jajaperson/nest-auth0

Thanks @jajaperson I found it 2 days ago once I started searching for 'nest auth0' instead of 'nestjs auth0'

authors: alexjoverm blee-smcoe cdiaz gsogol jajaperson

repo: kamilmysliwiec/nest


text:
Use react-datepicker instead of airbnb's react-dates

react-dates doesn't support setting the date of the datepicker directly (i.e. via changing its date value).

We've abandoned having a calendar, for now.

repo: kamiyo/sycpiano

license: MIT

license_source: github-api


text:
Add GpioCounter, a HardwareCounter implementation

GpioCounter implements HardwareCounter by utilizing the gpio interrupt
functionality of that class. On each interrupt event, the counter is
incremented.
Resolves #955

Superseded by #962

source: gharchive/pull-request


text:
installerでlibavのコンパイルが失敗する件について

gentoo Linux 3.18.1-gentoo で使用しております。
libx264の共有ライブラリが発見できないエラーが出ますので、有効化したところコンパイルできました。
--- chinachu    2015-01-18 10:16:11.008915429 +0900
+++ chinachu.mod        2015-01-18 10:15:22.592027905 +0900
@@ -230,6 +230,7 @@
./configure
--prefix=$USR_DIR
--enable-static \

--enable-shared
--disable-opencl
--disable-cli
--disable-ffms \

いんすとーる時のログでほかに何かエラーが出てたりしませんか。

$ ./chinachu installer の後, full install を選んだ結果です。
(前略)
removed `libvorbis-1.3.3'
removed ‘libvorbis-1.3.3.tar.gz’
removed `/home/user01/chinachu_test/usr/src/libvorbis'
libvorbis --> done.
Installing libav from git://git.libav.org/libav.git
Cloning into '/home/user01/chinachu_test/usr/src/libav'...
remote: Counting objects: 3371, done.
remote: Compressing objects: 100% (2769/2769), done.
remote: Total 3371 (delta 833), reused 1547 (delta 471)
Receiving objects: 100% (3371/3371), 7.41 MiB | 1.03 MiB/s, done.
Resolving deltas: 100% (833/833), done.
Checking connectivity... done.
ERROR: libx264 not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
libav-tools@libav.org mailing list or IRC #libav on irc.freenode.net.
Include the log file "config.log" produced by configure as this will help
solving the problem.
Makefile:1: config.mak: No such file or directory
Makefile:97: /common.mak: No such file or directory
Makefile:135: /libavutil/Makefile: No such file or directory
Makefile:135: /library.mak: No such file or directory
Makefile:137: /doc/Makefile: No such file or directory
Makefile:212: /tests/Makefile: No such file or directory
make: *** No rule to make target '/tests/Makefile'.  Stop.
couldn't make libav

Chinachu/usr/src/libav/config.log の後半です。
check_lib2 vpx/vpx_encoder.h vpx/vp8cx.h vpx_codec_enc_init_ver VPX_CQ -lvpx
check_func_headers vpx/vpx_encoder.h vpx/vp8cx.h vpx_codec_enc_init_ver VPX_CQ -lvpx
check_ld -lvpx
check_cc
BEGIN /tmp/ffconf.lI7Drcu4.c
    1   #include <vpx/vpx_encoder.h>
    2   #include <vpx/vp8cx.h>
    3   long check_vpx_codec_enc_init_ver(void) { return (long) vpx_codec_enc_init_ver; }
    4   long check_VPX_CQ(void) { return (long) VPX_CQ; }
    5   int main(void) { return 0; }
END /tmp/ffconf.lI7Drcu4.c
gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/home/user01/chinachu_test/usr/include --static -std=c99 -fomit-frame-pointer -fPIC -pthread -c -o /tmp/ffconf.BVDtTrwi.o /tmp/ffconf.lI7Drcu4.c
gcc -L/home/user01/chinachu_test/usr/lib -Wl,--as-needed -o /tmp/ffconf.VU6QgS0A /tmp/ffconf.BVDtTrwi.o -lvpx -lvorbisenc -lvorbis -logg -lfdk-aac -lm -lbz2 -lz -pthread
check_lib x264.h x264_encoder_encode -lx264
check_header x264.h
check_cpp
BEGIN /tmp/ffconf.lI7Drcu4.c
    1   #include <x264.h>
    2   int x;
END /tmp/ffconf.lI7Drcu4.c
gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/home/user01/chinachu_test/usr/include --static -std=c99 -fomit-frame-pointer -fPIC -pthread -E -o /tmp/ffconf.BVDtTrwi.o /tmp/ffconf.lI7Drcu4.c
In file included from /tmp/ffconf.lI7Drcu4.c:1:0:
/home/user01/chinachu_test/usr/include/x264.h:36:4: warning: #warning You must include stdint.h or inttypes.h before x264.h [-Wcpp]
 #  warning You must include stdint.h or inttypes.h before x264.h
    ^
check_func x264_encoder_encode -lx264
check_ld -lx264
check_cc
BEGIN /tmp/ffconf.lI7Drcu4.c
    1   extern int x264_encoder_encode();
    2   int main(void){ x264_encoder_encode(); }
END /tmp/ffconf.lI7Drcu4.c
gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/home/user01/chinachu_test/usr/include --static -std=c99 -fomit-frame-pointer -fPIC -pthread -c -o /tmp/ffconf.BVDtTrwi.o /tmp/ffconf.lI7Drcu4.c
gcc -L/home/user01/chinachu_test/usr/lib -Wl,--as-needed -o /tmp/ffconf.VU6QgS0A /tmp/ffconf.BVDtTrwi.o -lx264 -lvpx -lvorbisenc -lvorbis -logg -lfdk-aac -lm -lbz2 -lz -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: /home/user01/chinachu_test/usr/lib/libx264.a(cabac-a.o): relocation R_X86_64_32 against `x264_cabac_range_lps' can not be used when making a shared object; recompile with -fPIC
/home/user01/chinachu_test/usr/lib/libx264.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
ERROR: libx264 not found

x264のビルドは成功してるんでしょうか？

成功してるようです。
user01@matilda ~ $ ls chinachu_test/usr/lib/
libfdk-aac.a   libogg.a   libvorbis.a     libvorbisenc.la  libvorbisfile.la  libvpx.a   pkgconfig
libfdk-aac.la  libogg.la  libvorbisenc.a  libvorbisfile.a  libvorbis.la      libx264.a

usr/include/x264* はどうですか？
installer で libx264 単体ビルドに成功してますか？

ls usr/include/x264*の結果です。
user01@matilda ~/chinachu_test/usr/include $ ls x264*
x264_config.h  x264.h

installer で libx264 を選んだときのログです。
rm -f libx264.a
ar rc libx264.a  common/mc.o common/predict.o common/pixel.o common/macroblock.o common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/osdep.o common/rectangle.o common/set.o common/quant.o common/deblock.o common/vlc.o common/mvpred.o common/bitstream.o encoder/analyse.o encoder/me.o encoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o encoder/lookahead.o common/threadpool.o common/x86/mc-c.o common/x86/predict-c.o common/x86/const-a.o common/x86/cabac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/mc-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x86/quant-a.o common/x86/cpu-a.o common/x86/dct-64.o common/x86/bitstream-a.o common/x86/sad-a.o common/x86/trellis-64.o
ranlib libx264.a
install -d /home/user01/chinachu_test/usr/include
install -d /home/user01/chinachu_test/usr/lib
install -d /home/user01/chinachu_test/usr/lib/pkgconfig
install -m 644 ./x264.h /home/user01/chinachu_test/usr/include
install -m 644 x264_config.h /home/user01/chinachu_test/usr/include
install -m 644 x264.pc /home/user01/chinachu_test/usr/lib/pkgconfig
install -m 644 libx264.a /home/user01/chinachu_test/usr/lib
ranlib /home/user01/chinachu_test/usr/lib/libx264.a
rm -f  common/mc.o common/predict.o common/pixel.o common/macroblock.o common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/osdep.o common/rectangle.o common/set.o common/quant.o common/deblock.o common/vlc.o common/mvpred.o common/bitstream.o encoder/analyse.o encoder/me.o encoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o encoder/lookahead.o common/threadpool.o common/x86/mc-c.o common/x86/predict-c.o common/x86/const-a.o common/x86/cabac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/mc-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x86/quant-a.o common/x86/cpu-a.o common/x86/dct-64.o common/x86/bitstream-a.o common/x86/sad-a.o common/x86/trellis-64.o  x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/avs.o input/thread.o    *.a *.lib *.exp *.pdb x264 x264.exe .depend TAGS
rm -f checkasm checkasm.exe tools/checkasm.o tools/checkasm-a.o  x264_lookahead.clbin
rm -f example example.exe example.o
rm -f common/mc.gcda common/predict.gcda common/pixel.gcda common/macroblock.gcda common/frame.gcda common/dct.gcda common/cpu.gcda common/cabac.gcda common/common.gcda common/osdep.gcda common/rectangle.gcda common/set.gcda common/quant.gcda common/deblock.gcda common/vlc.gcda common/mvpred.gcda common/bitstream.gcda encoder/analyse.gcda encoder/me.gcda encoder/ratecontrol.gcda encoder/set.gcda encoder/macroblock.gcda encoder/cabac.gcda encoder/cavlc.gcda encoder/encoder.gcda encoder/lookahead.gcda common/threadpool.gcda common/x86/mc-c.gcda common/x86/predict-c.gcda x264.gcda input/input.gcda input/timecode.gcda input/raw.gcda input/y4m.gcda output/raw.gcda output/matroska.gcda output/matroska_ebml.gcda output/flv.gcda output/flv_bytestream.gcda filters/filters.gcda filters/video/video.gcda filters/video/source.gcda filters/video/internal.gcda filters/video/resize.gcda filters/video/cache.gcda filters/video/fix_vfr_pts.gcda filters/video/select_every.gcda filters/video/crop.gcda filters/video/depth.gcda input/avs.gcda input/thread.gcda common/mc.gcno common/predict.gcno common/pixel.gcno common/macroblock.gcno common/frame.gcno common/dct.gcno common/cpu.gcno common/cabac.gcno common/common.gcno common/osdep.gcno common/rectangle.gcno common/set.gcno common/quant.gcno common/deblock.gcno common/vlc.gcno common/mvpred.gcno common/bitstream.gcno encoder/analyse.gcno encoder/me.gcno encoder/ratecontrol.gcno encoder/set.gcno encoder/macroblock.gcno encoder/cabac.gcno encoder/cavlc.gcno encoder/encoder.gcno encoder/lookahead.gcno common/threadpool.gcno common/x86/mc-c.gcno common/x86/predict-c.gcno x264.gcno input/input.gcno input/timecode.gcno input/raw.gcno input/y4m.gcno output/raw.gcno output/matroska.gcno output/matroska_ebml.gcno output/flv.gcno output/flv_bytestream.gcno filters/filters.gcno filters/video/video.gcno filters/video/source.gcno filters/video/internal.gcno filters/video/resize.gcno filters/video/cache.gcno filters/video/fix_vfr_pts.gcno filters/video/select_every.gcno filters/video/crop.gcno filters/video/depth.gcno input/avs.gcno input/thread.gcno *.dyn pgopti.dpi pgopti.dpi.lock *.pgd *.pgc
removed `/home/user01/chinachu_test/usr/src/libx264'
libx264 --> done.

最初に挙げた patch とこちらのどちらが正しいのか分からないのですが、
当方ではこの変更で、h264ストリーミング再生まで動作しています。
--- chinachu_test/chinachu      2015-01-18 17:52:19.992551965 +0900
+++ chinachu_self/chinachu      2015-01-18 18:23:59.711826723 +0900
@@ -235,6 +235,7 @@
     --disable-ffms \
     --disable-gpac \
     --disable-lavf \
+    --enable-pic \
     --disable-swscale

   make || fail "couldn't make libx264"

修正しました。
2644eb2f60ce8e4bd007d69cccd704d0c894bfaa

repo: kanreisa/Chinachu


text:
How much graphics memory do you need for training? Can you give me a minimum formulation?

How much graphics memory do you need for training? Can you give me a minimum formulation?

depends on the your batch size. I use a GTX 1080 and could run up to 32 instances each batch. If GPU memory is your concern, you can try smaller batch size, like 8/16.

Thanks


text:
Update sbt to 1.10.4

About this PR
📦 Updates org.scala-sbt:sbt from 1.10.2 to 1.10.4
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-sbt", artifactId = "sbt" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #44.

repo: karadzhov/scala-iso-language

license: Unlicense


text:
Add Makefile to editorconfig

This change is

bors r+

repo: karen-irc/option-t


text:
Laravel 10.x Shift

This pull request includes the changes for upgrading to Laravel 10.x. Feel free to commit any additional changes to the shift-80683 branch.
Before merging, you need to:

Checkout the shift-80683 branch
Review all pull request comments for additional changes
Run composer update (if the scripts fail, add --no-scripts)
Clear any config, route, or view cache
Thoroughly test your application (no tests?, no CI?)

If you need help with your upgrade, check out the Human Shifts. You may also join the Shifty Coders Slack workspace to level-up your Laravel skills.

:information_source: Laravel 9 moved the resources/lang folder to the top level of the project. While Shift moved and replaced references to this folder, you may have additional references to this folder which need to be updated.

:information_source: Shift updated your dependencies for Laravel 10. While many of the popular packages are reviewed, you may have to update additional packages in order for your application to be compatible with Laravel 10. Watch dealing with dependencies for tips on handling any Composer issues.

:x: Shift could not upgrade the following files since they differed from the default Laravel version. You will need to compare these files against the default Laravel 10 versions and merge any changes:

[ ] app/Http/Middleware/Authenticate.php

:information_source: Laravel 10 added PHP type hints to all user-land code included in a new Laravel application. In an effort to modernize your code, Shift added type hints to any method which is used by Laravel, as well as any method which had types defined in its PHP DocBlock.

:information_source: Now with type hints in your code, defining types within PHP DocBlocks is redundant. Laravel has removed all of the @param and @return tags from its DocBlocks where types are defined with PHP. Similarly, Shift removed these tags from any DocBlock where the code now has equivalent type hints.

:information_source: Shift understand developers have different preferences when it comes to type hints. All of Shift's automation is done in nice, atomic commits. This makes it easier to undo any of the changes Shift makes.
If you wish to undo any of these changes, you may first revert the DocBlock changes by running git revert 01d2796. Then undo the added type hints by running git revert 09a6200.

:information_source: All of the underlying Symfony components used by Laravel have been upgraded to Symfony 6.2. Shift detected references to Symfony classes within your application. You should review the Symfony change log for any additional changes.

:tada: Congratulations, you're now running the latest version of Laravel!
Next, you may optionally run the following Shifts to ensure your application is fully upgraded, adopts the latest Laravel conventions, and easier to maintain in the future:

Upgrade Checker ensures your application is fully upgraded by detecting any outdated code.
Laravel Fixer automatically updates your code to the latest Laravel conventions.
Tests Generator intelligently generates model factories, HTTP Tests, and configuration for your application.
CI Generator intelligently generates CI jobs to lint PHP, check code style, and run tests, including Dusk.

You may also use the Shift Workbench to automate common tasks for maintaining your Laravel and PHP applications.

:x: PHP syntax errors were detected after running your Shift. Often these are simply differences between the PHP version on the Shift server (8.1) and your project. Occasionally they are misplaced lines or duplicate import statements.
You may quickly check the PHP syntax locally by running php -l on the following files:

[ ] app/Http/Controllers/WelcomeController.php

:alembic: This Shift is still being refined. Please report any issues or suggestions to shift@laravelshift.com. Your feedback is what helps improve the experience for everyone.


text:
🛑 Habilitación is down

In c4ab664, Habilitación (https://catalogo-vpfe-hab.dian.gov.co/User/Login) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Habilitación is back up in 3a306c0.


text:
Update the documentation to reflect deprecation of "external" profile value in istioctl

What type of PR is this?
/kind documentation

What this PR does / why we need it:
This PR updates the documentation to reflect the deprecation of the "external" profile value in istioctl and its replacement with "remote" to align with the latest changes.

Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

@windsonsea
Sorry, I don't understand.
Could you explain with some screenshots?

repo: karmada-io/website


text:
Adding License File;

(1) Primary author of the project is Andrej Karpathy;
(2) Modifications have not been attributed (yet);
Solves issue #37.

looks good thank you!

authors: karpathy kingtaurus

repo: karpathy/arxiv-sanity-preserver


text:
Salinity, windSpeed10m, and windDirection10m still don't do anything

Something got lost in the shuffle, and  the wiring to these guys went away. Put them back!

fixed with merge!

repo: karpob/pycrtm


text:
Abnormal operation when deleting an item by dragging

https://github.com/karvulf/flutter-reorderable-grid-view/assets/18232924/9cc3835b-6495-4a53-a9be-a0fc78d9d64b
Changing the GlobalKey causes another error.
This part will be registered as a new issue.
import 'package:flutter/material.dart';
import 'package:flutter_reorderable_grid_view/widgets/custom_draggable.dart';
import 'package:flutter_reorderable_grid_view/widgets/reorderable_builder.dart';
import 'package:flutter_reorderable_grid_view_example/widgets/change_children_bar.dart';

enum ReorderableType {
  gridView,
  gridViewCount,
  gridViewExtent,
  gridViewBuilder,
}

void main() {
  runApp(const MaterialApp(home: MyApp()));
}

class MyApp extends StatefulWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  static const _startCounter = 3333;
  final lockedIndices = <int>[0];

  int keyCounter = _startCounter;
  List<int> children = List.generate(_startCounter, (index) => index);
  ReorderableType reorderableType = ReorderableType.gridViewBuilder;

  var _scrollController = ScrollController();
  var _gridViewKey = GlobalKey();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      backgroundColor: Colors.white70,
      body: SafeArea(
        child: Padding(
          padding: const EdgeInsets.fromLTRB(20, 20, 20, 0),
          child: Column(
            children: [
              ChangeChildrenBar(
                onTapAddChild: () {
                  setState(() {
                    // children = children..add(keyCounter++);
                    children.insert(0, keyCounter++);
                  });
                },
                onTapRemoveChild: () {
                  if (children.isNotEmpty) {
                    setState(() {
                      // children = children..removeLast();
                      children.removeAt(0);
                    });
                  }
                },
                onTapClear: () {
                  if (children.isNotEmpty) {
                    setState(() {
                      children = <int>[];
                    });
                  }
                },
                onTapUpdateChild: () {
                  if (children.isNotEmpty) {
                    children[0] = 999;
                    setState(() {
                      children = children;
                    });
                  }
                },
                onTapSwap: () {
                  final child1 = children[0];
                  final child2 = children[1];
                  children[0] = child2;
                  children[1] = child1;
                  setState(() {});
                },
              ),
              DropdownButton<ReorderableType>(
                value: reorderableType,
                icon: const Icon(Icons.arrow_downward),
                iconSize: 24,
                elevation: 16,
                itemHeight: 60,
                underline: Container(
                  height: 2,
                  color: Colors.white,
                ),
                onChanged: (ReorderableType? reorderableType) {
                  setState(() {
                    _scrollController = ScrollController();
                    _gridViewKey = GlobalKey();
                    this.reorderableType = reorderableType!;
                  });
                },
                items: ReorderableType.values.map((e) {
                  return DropdownMenuItem<ReorderableType>(
                    value: e,
                    child: Text(e.toString()),
                  );
                }).toList(),
              ),
              const SizedBox(height: 20),
              Expanded(child: _getReorderableWidget()),
            ],
          ),
        ),
      ),
    );
  }

  Widget _getReorderableWidget() {
    switch (reorderableType) {
      case ReorderableType.gridView:
        final generatedChildren = _getGeneratedChildren();
        return ReorderableBuilder(
          key: Key(_gridViewKey.toString()),
          children: generatedChildren,
          onReorder: _handleReorder,
          lockedIndices: lockedIndices,
          onDragStarted: _handleDragStarted,
          onUpdatedDraggedChild: _handleUpdatedDraggedChild,
          onDragEnd: _handleDragEnd,
          scrollController: _scrollController,
          builder: (children) {
            return GridView(
              key: _gridViewKey,
              controller: _scrollController,
              children: children,
              gridDelegate: const SliverGridDelegateWithFixedCrossAxisCount(
                crossAxisCount: 4,
                mainAxisSpacing: 4,
                crossAxisSpacing: 8,
              ),
            );
          },
        );

      case ReorderableType.gridViewCount:
        final generatedChildren = _getGeneratedChildren();
        return ReorderableBuilder(
          key: Key(_gridViewKey.toString()),
          children: generatedChildren,
          onReorder: _handleReorder,
          lockedIndices: lockedIndices,
          scrollController: _scrollController,
          fadeInDuration: Duration.zero,
          enableLongPress: true,
          builder: (children) {
            return GridView.count(
              key: _gridViewKey,
              controller: _scrollController,
              scrollDirection: Axis.horizontal,
              crossAxisCount: 3,
              shrinkWrap: true,
              mainAxisSpacing: 5,
              crossAxisSpacing: 5,
              children: children,
            );
          },
        );
      case ReorderableType.gridViewExtent:
        final generatedChildren = _getGeneratedChildren();
        return ReorderableBuilder(
          key: Key(_gridViewKey.toString()),
          children: generatedChildren,
          onReorder: _handleReorder,
          lockedIndices: lockedIndices,
          scrollController: _scrollController,
          builder: (children) {
            return GridView.extent(
              key: _gridViewKey,
              controller: _scrollController,
              children: children,
              maxCrossAxisExtent: 200,
              padding: EdgeInsets.zero,
              mainAxisSpacing: 12,
              crossAxisSpacing: 12,
            );
          },
        );

      case ReorderableType.gridViewBuilder:
        return ReorderableBuilder.builder(
          key: Key(_gridViewKey.toString()),
          onReorder: _handleReorder,
          lockedIndices: lockedIndices,
          onDragStarted: _handleDragStarted,
          onUpdatedDraggedChild: _handleUpdatedDraggedChild,
          onDragEnd: _handleDragEnd,
          scrollController: _scrollController,
          childBuilder: (itemBuilder) {
            return GridView.builder(
              key: _gridViewKey,
              controller: _scrollController,
              itemCount: children.length,
              itemBuilder: (context, index) {
                return itemBuilder(
                  _getChild(index: index),
                  index,
                );
              },
              gridDelegate: const SliverGridDelegateWithFixedCrossAxisCount(
                crossAxisCount: 4,
                mainAxisSpacing: 4,
                crossAxisSpacing: 8,
              ),
            );
          },
        );
    }
  }

  List<Widget> _getGeneratedChildren() {
    return List<Widget>.generate(
      children.length,
      (index) => _getChild(index: index),
    );
  }

  Widget _getChild({required int index}) {
    if (index == 0) {
      return CustomDraggable(
          key: Key(children[index].toString()),
          data: index,
          child: DragTarget(
            onAccept: (v) {
              setState(() {
                children.removeAt(v as int);
              });
            },
            builder: (context, candidateData, rejectedData) {
              return Container(
                height: 100.0,
                width: 100.0,
                child: Center(
                  child: Icon(Icons.delete),
                ),
              );
            },
          ));
    }

    return CustomDraggable(
      key: Key(children[index].toString()),
      data: index,
      child: Container(
        decoration: BoxDecoration(
          color: lockedIndices.contains(index) ? Colors.black : Colors.white,
        ),
        height: 100.0,
        width: 100.0,
        child: Center(
          child: Text(
            'test ${children[index]}',
            style: const TextStyle(),
          ),
        ),
      ),
    );
  }

  void _handleDragStarted(int index) {
    _showSnackbar(text: 'Dragging at index $index has started!');
  }

  void _handleUpdatedDraggedChild(int index) {
    _showSnackbar(text: 'Dragged child updated position to $index');
  }

  void _handleReorder(ReorderedListFunction reorderedListFunction) {
    setState(() {
      children = reorderedListFunction(children) as List<int>;
    });
  }

  void _handleDragEnd(int index) {
    _showSnackbar(text: 'Dragging was finished at $index!');
  }

  void _showSnackbar({required String text}) {
    ScaffoldMessenger.of(context).clearSnackBars();
    final snackBar = SnackBar(
      content: Text(text),
      duration: const Duration(milliseconds: 1000),
    );
    ScaffoldMessenger.of(context).showSnackBar(snackBar);
  }
}

version : 5.0.0-dev.8

Hello I have some news for you, I found the bug in the code.
The main issue was that the dragged item was removed from the list and disposed. In that case the callback that the drag was cancelled didn't get called and the dragging internally never finished. This is the reason why the behavior was so buggy afterwards.
I implemented a solution that should fix the issue. I will improve that one later but unfortunately in the next days I won't have much time for it. So you could try the current solution if that works for you, just add the following to your pubspec.yaml:
flutter_reorderable_grid_view:
  git:
    url: https://github.com/karvulf/flutter-reorderable-grid-view.git
    ref: 1f6f22fec77fa70382ff63ec9d51b9b61e882db9

Let me know if that helped you! :)

I also will close the other issue because this one should solve it

I checked.
It's been resolved.
thank you!!

repo: karvulf/flutter-reorderable-grid-view


text:
Revisit definition of "Synced"

For now make shorter as function of bps. Consider conditioning config on testnet due to hash instability.
Another possibility: identify the case where headers selected tip is too far above sink (which happens in IBD headers phase) and consider it not synced.

Fixed in #356

repo: kaspanet/rusty-kaspa

license: ISC


text:
Being able to invoke qemu through libvirt

Which feature do you think can be improved?
On Fedora, qemu is normally never invoked directly, but rather through libvirt.
This improves security, notably by allowing qemu to run as a non-root user.
How can it be improved?
Instead of starting qemu directly, the VM could be started through libvirt.
This presumably requires creating an XML file to pass around the required configuration
(not saying that this is easy…)

I think a contribution enabling libvirt as one of the supported hypervisor interfaces for kata would be most welcome.
Historically (aka, a loooong time ago), fore-runners to kata avoided libvirt as the time/space/complexity overhead outweighed the benefits (things back then were probably more focussed on size and speed than security). As an option though, if having libvirt as an option added security benefits, I think that could be well accepted.
/cc @gnawux @egernst @sameo for any thoughts.

Hello everyone,
Note: I'm speaking only for myself in this message.
In my view it'd be preferable to focus on adding support to kata-runtime to support vfio device assignment to the guest with qemu running without privileges, or whatever else microvm hotplug with paravirtualized hotplug support for virtio-mmio yet to be developed, depending on whataever use case requiring vfio, hotplug and device assignment emerges and requires to be supported in the future.
Just dropping root with virtiofs and without PCI device assignment is a trivial change to kata-runtime: upstream qemu already supports it with the -runas option.
https://github.com/qemu/qemu/blob/c1e667d2598b9b3ce62b8e89ed22dd38dfe9f57f/os-posix.c#L187
If libvirtd can somehow handle unprivileged vfio device assignment, so can kata-runtime can without libvirtd, it's just a matter of implementing it.
The ideal objective of avoiding code duplication by adding libvirt support to kata-runtime sounds like an oxymoron: sure you won't have to add the code that does unprivileged vfio support to kata-runtime anymore, but it'll backfire by creating instant duplication at the selinux-svirt/namespaces/cgroups/seccomp level, which are all things that are commonly already handled by CRI-O by all other containers.
Overall the most important objective that is worth investing on, is that kata-runtime and qemu are always upgraded atomically and they're effectively monolithic, so that there will be zero userland stable API that needs to be maintained with backwards compatibility (i.e. kata-runtime needs to speak a single version of the qemu command line at any given time) in between the enduser/customer deploying a container and the host kernel syscall ABI.

it'll backfire by creating instant duplication at the selinux-svirt/namespaces/cgroups/seccomp level, which are all things that are commonly already handled by CRI-O by all other containers.

Are you thinking of libcontainer/runc rather than CRI-O? If you mean that there would be duplicated code between the two runtime classes then yeah, there would be some duplication between libcontainer and libvirt.
In my opinion the advantage of libvirt is that it can be considered a black box as far as Kata is concerned, especially with the new daemon-less operation. The fact that the cgroups code is duplicated between libcontainer and libvirt is irrelevant as far as Kata is concerned. If it's something that either libcontainer or libvirt folks want to unify it's great, but libvirt strictly gives Kata fewer things to worry about than go-vmm (and of course go-vmm is basically part of Kata while the libvirt-go and libvirt-xml-go bindings are maintained by someone else).

Are you thinking of libcontainer/runc rather than CRI-O?

It doesn't really matter where the duplication materializes, that's a minor implementation detail.
The point is that all software when it's containerized, uses the standard support to apply selinux/namespaces/cgroups/seccomp. qemu is not magic, it's just a plain normal process like every other and it needs to reuse the container runtime isolation like every other process.
The exception where qemu (or any other app for that matter) still needs to apply a strictier isolation like a strictier seccomp filter or an empty-chroot-like fs-namespace view, during its runtime (like after forking a child that has an higher surface of attack), but this isn't what we're talking about here: what libvirt applies is still a fixed coarse kind of isolation, nothing finegrined depending on the actual runtime that can only be applied at runtime, so there's no justification to make qemu a special case and to add a "special security wrapper" for commoditized isolation security features already done by the container runtime.
Upstream shouldn't focus on short term issues, we need to focus on what is more secure overall: if anything is missing then it should be applied to the standard container runtime, not kept in libvirt for the only benefit of qemu. If qemu can't live with the standard runtime security isolation and it needs to carry its own security wrapper, then imagine all other bare metal containers that don't even have the virt isolation on top of the bare metal isolation, how can all containers live without their own libvirt?
Furthermore I don't see the support for PR_SET_NO_NEW_PRIVS in libvirt, while there is in firejail/crun etc... I mean if something libvirt is already falling behind the standard and it's more likely stuff would need to be added to libvirt than moved from libvirt to crun.

Upstream shouldn't focus on short term issues, we need to focus on what is more secure overall

Define "short term issues" and "more secure overall". Possibly with actual examples of privilege escalation that are not prevented by libvirt.

Furthermore I don't see the support for PR_SET_NO_NEW_PRIVS in libvirt, while there is in firejail/crun etc... I mean if something libvirt is already falling behind the standard and it's more likely stuff would need to be added to libvirt than moved from libvirt to crun.

The seccomp policy forbids completely the spawning of child processes, and...
With no_new_privs set to 1, execve(2) promises not to grant privileges to do anything
that could not have been done without the execve(2) call

... you can't get privileges from execve if you cannot execve.

Define "short term issues" and "more secure overall". Possibly with actual examples of privilege escalation that are not prevented by libvirt.

"short term issues": I meant being able to apply the current libvirt  security isolation without having to port it to the container runtime first (i.e. svirt, namespaces, cgroup). It may an effect in the short term to be able achieve the standard libvirt security practice quicker perhaps (a not even sure about that: it may still take more time to add libvirt support to kata-runtime than to port the security isolation to the container runtime, but I just couldn't think of other possible benefits so I said "short term issues" as "short term concerns").
"more secure overall": I wasn't talking about qemu, I am talking about everything: podman, on-prem cloud, public clouds running k8s. I already justified it, quote: "if anything is missing then it should be applied to the standard container runtime, not kept in libvirt for the only benefit of qemu".

The seccomp policy forbids completely the spawning of child processes, and...
... you can't get privileges from execve if you cannot execve.

The seccomp policy can be opted-out in qemu: there is no justification for libvirt not to add PR_SET_NO_NEW_PRIVS at the very least if the seccomp policy isn't runtime enabled in qemu. It's less an issue for kata because we'd apply it at the container runtime and also the seccomp policy, but here I was purely making an example of stuff that needs to move from crun to libvirt, not the way around. To explain not only it would be possible to do the same security isolation libvirt does through the container runtime without having to write code, it would be possible to do more.
And as said above, if code has to be written, the end result will be "more secure overall" (if ignoring "short term issues").

The seccomp policy can be opted-out in qemu

When Libvirt invokes QEMU it knows that the seccomp policy will be there, because it uses -sandbox. Am I misunderstanding what you mean?

it would also be possible to do more.

What is "more"? Adding no_new_privs is not "more", it's security theater if QEMU is anyway disallowed from spawning child processes. (Besides, QEMU already knows how to set no_new_privs when it applies the seccomp filter. Libvirt doesn't ask because it's pointless).

When Libvirt invokes QEMU it knows that the seccomp policy will be there, because it uses -sandbox. Am I misunderstanding what you mean?

First of all this took a tangent offtopic with kata: we're discussing the worth of adding PR_SET_NO_NEW_PRIVS knowledge to libvirt.
Even if I'd be entirely wrong about this, it changes nothing with everything else that was discussed actually related to kata.
So first of all qemu can be built without CONFIG_SECCOMP:
#ifdef CONFIG_SECCOMP
int parse_sandbox(void *opaque, QemuOpts *opts, Error **errp)
and even when it's built in, it can be disabled at runtime and it looks like libvirt allows to opt-out of seccomp:
{ "sandbox", "enable", QEMU_CAPS_SECCOMP_SANDBOX },
{ "sandbox", "elevateprivileges", QEMU_CAPS_SECCOMP_BLACKLIST },

[..]
if (cfg->seccompSandbox == 0) {
    if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_SECCOMP_SANDBOX))
        virCommandAddArgList(cmd, "-sandbox", "off", NULL);
    return 0;
}

What is "more"? Adding no_new_privs is not "more", it's security theater if QEMU is anyway disallowed from spawning child processes. (Besides, QEMU already knows how to set no_new_privs when it applies the seccomp filter. Libvirt doesn't ask because it's pointless).

fork and exec aren't disallowed unless secomp enabled which isn't guaranteed as shown above.
So to be more clear, I should rephrase the words "there is no justification for libvirt not to add PR_SET_NO_NEW_PRIVS" with "there is no justification for libvirt not to add PR_SET_NO_NEW_PRIVS when it executes qemu with the sandbox off or when it executes any of the other dozen of hypervisors that may have an userland and may not have a sandbox".
The only reason qemu supports elevateprivileges at all (which is the only option that would set PR_SET_NO_NEW_PRIVS if equal to "children") is to allow bridge helpers or other scripts to run, but those would never need to run with libvirt, they're entirely mutually exclusive. When libvirt is on there is never a justification for qemu to ever run any suid at all.
In other words libvirt simply needs to add a PR_SET_NO_NEW_PRIVS, and if something breaks, it means they will have found a major bug, not that PR_SET_NO_NEW_PRIVS should be made conditional. It's making PR_SET_NO_NEW_PRIVS conditional to whatever lowevel qemu detail that is a security theater. Qemu has to make that conditonal in case it doesn't run under libvirt and it uses an helper suid to setup the network, but even that is bad design and qemu should be totally in control like sshd root server is, and it should setup the network while the child qemu does seccomp and all the other stuff unconditionally.
The fact seccomp is not unconditionally set by libvirt nor qemu and the fact PR_SET_NO_NEW_PRIVS is not unconditional in qemu either, and the fact libvirt even pretends to support a dozen of other hypervisors that may not support seccomp nor PR_SET_NO_NEW_PRIVS, makes me wonder if the lack of PR_SET_NO_NEW_PRIVS in libvirt  is a security theater or if it should be fixed and be set unconditonal no matter what is the qemu command line, at least if qemu is the hypervisor invoked.

fork and exec aren't disallowed unless secomp is enabled which isn't guaranteed as shown above.

Right, if the user explicitly chooses an insecure setup with sandboxing disabled it's probably for a reason, why would Libvirt enable some sandboxing in that case? Chance are that it would break something.
Note that --security-opt no-new-privileges is opt-in for docker/podman, while the whole of sandboxing (seccomp) is opt-out for Libvirt. Showing how Libvirt will just do the right thing.

libvirt even pretends to support a dozen of other hypervisors that may not support seccomp nor PR_SET_NO_NEW_PRIVS,

I suggest that you tone down your messages and study Libvirt a bit more, because Libvirt won't even exec anything for most non-QEMU hypervisors so it doesn't have anything to sandbox. I also don't see how those other hypervisors are relevant to Kata.

To solve that qemu should remain in control

This is also irrelevant for either Libvirt or Kata as you say, but anyway patches are welcome on qemu-devel@nongnu.org if you believe that would be an improvement.

Right, if the user explicitly chooses an insecure setup with sandboxing disabled it's probably for a reason, why would Libvirt enable some sandboxing in that case? Chance are that it would break something.

I covered that in my previous post: "if something breaks, it means they will have found a major bug".

Note that --security-opt no-new-privileges is opt-in for docker/podman, while the whole of sandboxing (seccomp) is opt-out for Libvirt. Showing how Libvirt will just do the right thing.

So it's perfectly correct that --security-opt no-new-privileges is an opt-in for docker/podman. docker/podman have to run everything under the sun including /bin/su itself, there's no way it can unconditionally set PR_SET_NO_NEW_PRIVS.
That is not the case with libvirt which has been specifically designed to no never require any privilege from qemu.
libvirt will never run qemu as root, as such it also should not allow qemu to gain privilege from any suid. No matter if the sandbox is enabled or not.

libvirt even pretends to support a dozen of other hypervisors that may not support seccomp nor PR_SET_NO_NEW_PRIVS,

I suggest that you tone down your messages and study Libvirt a bit more, because Libvirt won't even exec anything for most non-QEMU hypervisors so it doesn't have anything to sandbox. I also don't see how those other hypervisors are relevant to Kata.

I know qemu will benfit, I supposed others would benefit (see the "may not support .."), if I'm wrong that's fine and it  only means it'll only benefit qemu.
About how the other hypervisors, they are relevant for kata. I don't think we should include any dependency on any project that pretends to supports additional hypervisors and additional qemu versions.
This is also why I said above, quote: "kata-runtime needs to speak a single version of the qemu command line at any given time".

This is also irrelevant for either Libvirt or Kata as you say, but anyway patches are welcome on qemu-devel@nongnu.org if you believe that would be an improvement.

I never intended to talk about things that are irrelevant to kata, I just made an example about a security feature that we can tweak on by default in the container runtime and that is missing in libvirt if libvirt is configured to use qemu and to start qemu without the sandbox. You then disagreed that it's useful and you justify the lack of its enforcement at all times on the libvirt side by comparing libvirt to docker/podman.

libvirt will never run qemu as root, as such it also should not allow qemu to gain privilege from any suid. No matter if the sandbox is enabled or not.

"Opt out" means literally that you are renouncing something. Opting out of sandboxing disables all of it, including PR_SET_NO_NEW_PRIVS. Why does it matter? It's a non-default setting that should not be used in production. Instead, when the next security feature will come (and, for good reasons, it will be opt in for libcontainer), you can just count on libvirt to apply it and, if it doesn't, you can contribute a patch to libvirt to do so, just like you would contribute a patch to kata-runtime that turns on the appropriate libcontainer knob.

I don't think we should include any dependency on any project that pretends to supports additional hypervisors and additional qemu versions.

Again, please justify your assertion. Why would one care if Libvirt can drive QEMU, ESX or anything else? Libvirt is modular, if you don't want to waste disk space on ESX support you just don't install the .so for ESX. And of course Kata won't talk to any hypervisor other than QEMU if the Libvirt bridge hardcodes QEMU as the hypervisor to connect to.

"Opt out" means literally that you are renouncing something. Opting out of sandboxing disables all of it, including PR_SET_NO_NEW_PRIVS. Why does it matter? It's a non-default setting that should not be used in production, basically a debugging tool.

Why exactly would you need not to set PR_SET_NO_NEW_PRIVS during any libvirt+qemu debugging? Do you have debug apps running as suid in your system? Could you mention which one and in which realistic scenario the lack of PR_SET_NO_NEW_PRIVS in libvirt provides a debug aid to either libvirt or qemu?
Can you confirm that the the lack of the prctl(PR_SET_NO_NEW_PRIVS) is considered a feature in libvirt?

Again, please justify your assertion.

How can I possibly justify a fact? It is a fact that reducing dependencies for a project is a win if those dependencies provide no benefit?
It's not me asking kata-runtime upstream to add a dependency on a project that supports a multitude of other hypervisors besides qemu that would never be used by kata-runtime (and that doesn't support cloud hypervisor).
In my view it's such request that should be justified with a long term benefit to kata-runtime.

Why would one care if Libvirt can drive QEMU, ESX or anything else? Libvirt is modular, if you don't want to waste disk space on ESX support you just don't install the .so for ESX. And of course Kata won't talk to any hypervisor other than QEMU if the Libvirt bridge hardcodes QEMU as the hypervisor to connect to.

I care if a project pretends to support hypervisors that are useless to kata-runtime, because no amount of overhead and source complexity, even if only in the git grep results, is justified, not matter how small, even if only in the harddisk of the devs, unless it provides a long term benefits to kata-runtime.
The fact "you can" add the dependency doesn't imply "we should". The fact "you can" alone is not good enough justification.
Earlier you also mentioned "especially with the new daemon-less operation": you omitted that is still in the works and it's not a done thing usable in production in the short term.
Looking at the short term: it'd be surprised if it's less work to make libvirt run daemon-less than to add the vfio unprivileged support to kata-runtime on top of the -runas option to drop root.
Looking at the long term: if we can reduce the dependencies with zero feature loss it's win (are you going to ask me again to justify a fact?). The end result will have the effect of reducing the code duplication with the container runtime by reusing the standard security isolation practices of applying part of the cgroup/namespaces/selinux/seccomp/PR_SET_NO_NEW_PRIVS/dropcapetc.. through the container schema. (the seccomp more finegrined filter will still have to be applied by qemu on itself).
About the "the advantage of libvirt is that it can be considered a black box as far as Kata is concerned": if the common security isolation practices of the container runtime are secure enough for bare metal containers that lack the virt isolation (where they act as first line of defence), we'd have a problem if they are not enough for qemu (where they act only as second line of defense). The "black box" would hide the problem for qemu, but what about all the other containers out there that can't run under the "black box" then? Shouldn't we worry about fixing the first line of defense for the bare metal containers, before worrying about the second line of defence for the kata-containers?
All the above assumes kata-runtime upstream will then accept patches to add unprivileged vfio or anything else missing that would be currently available if adding the "black box" to the equation.

Could you mention which one and in which realistic scenario the lack of PR_SET_NO_NEW_PRIVS in libvirt provides a debug aid to either libvirt or qemu?

For example if you are implementing a feature that requires a privileged helper and you haven't implemented yet the code to launch the helper from Libvirt.

Can you confirm that the the lack of the prctl(PR_SET_NO_NEW_PRIVS) is considered a feature in libvirt?

It's a feature if you opt out of sandboxing. It's irrelevant if you don't.

About the "the advantage of libvirt is that it can be considered a black box as far as Kata is concerned": if the common security isolation practices of the container runtime are secure enough for bare metal containers that lack the virt isolation (where they act as first line of defence), we'd have a problem if they are not enough for qemu (where they act only as second line of defense).

You already have answered this yourself, didn't you? As you said, podman/docker/libcontainer have to run every kind of container, therefore many security features cannot be active by default. You have to care about these manually if you use libcontainer. Libcontainer is not a black box in that sense. Libvirt is more specific and therefore it can take care of all the security knobs.

Looking at the long term: if we can reduce the dependencies with zero feature loss it's a win (are you going to ask me again to justify a fact?)

There would be a maintenance cost associated to the extra code in Kata. Of course it's not possible to know the answer without seeing the code for both approaches, but people can use their judgment to decide whether a dependency is good or bad. Otherwise we'd be writing everything on assembly to avoid the lobc dependency (that's of course an exaggeration).

All the above assumes kata-runtime upstream will then accept patches to add unprivileged vfio or anything else missing that would be currently available if adding the "black box" to the equation.

I am sure Kata would accept these patches if they were proposed. It's probably not so easy, the relevant issues have been open  for almost 2 years, and there are people not using Kata in multi-tenant scenarios because of this missing feature (some are even using instead a custom version of Libvirt with Firecracker support!).

Could you mention which one and in which realistic scenario the lack of PR_SET_NO_NEW_PRIVS in libvirt provides a debug aid to either libvirt or qemu?

For example if you are implementing a feature that requires a privileged helper and you haven't implemented yet the code to launch the helper from Libvirt.

Can you confirm that the the lack of the prctl(PR_SET_NO_NEW_PRIVS) is considered a feature in libvirt?

It's a feature if you opt out of sandboxing. It's irrelevant if you don't.

Libvirt has privileges it cannot possibly need suid helpers, that is the whole point of leaving the privilge to libvirt, so nothing else shall be trusted, isn't it?
In other words libvirt should also run under PR_SET_NO_NEW_PRIVS at all times, not just qemu.
If libvirt ever need suids to function, it has a much bigger problem than lack of PR_SET_NO_NEW_PRIVS. (i.e. the debug "feature")

You already have answered this yourself, didn't you? As you said, podman/docker/libcontainer have to run every kind of container, therefore many security features cannot be active by default. You have to care about these manually if you use libcontainer. Libcontainer is not a black box in that sense. Libvirt is more specific and therefore it can take care of all the security knobs.

libvirt is non-manual, non-libvirt is manual?
It's actually software in both cases, there's no such thing as "non-manual" here, there is no AI involvement in the software development in both cases, ideally it would be written by the same developers too.
There's no reason why it can't be "ported" to the new model. What is fixed in stone and static for the whole runtime of qemu can be offloaded to the container schema, you just make sure through software that it get applied correctly. The rest is done by kata-runtime and qemu (seccomp finegrined filter as example). The idea is purely to reuse the container runtime facility, and to put the software in the compose.
Whatever shall work securely for all containers, I'm not sure why it can't work for qemu where it's actually a second line of defense.
The idea that you can't trust any software except a very specific black box has no technical justifications in the long term, it's a non technical argument as far as I'm concerned.

There would be a maintenance cost associated to the extra code in Kata. Of course it's not possible to know the answer without seeing the code for both approaches, but people can use their judgment to decide whether a dependency is good or bad. Otherwise we'd be writing everything on assembly to avoid the libc dependency (that's of course an exaggeration).

Let's assume for a second libvirt was actually a lib.
Assume you need a single function from such a lib.
However that single function is also available in the standard libopenssl (i.e. container runtime), but you need to change the way things work to use it. Well you need in fact to change the code a bit anyway, even to call such function from the other lib.
Do you pick the de facto standard libopenssl that every other container already sues, or you go with the lib that isn't installed by default and that can only be used by a single app (qemu)?
Now in reality, libvirt currently is not a lib, but a a daemon, so until the daemon-less libvirt is available, no comparison with any lib, glibc included, can hold here.

I am sure Kata would accept these patches if they were proposed.

I hope so too, I specified it for completeness.

It's probably not so easy, the relevant issues have been open for almost 2 years, and there are people not using Kata in multi-tenant scenarios because of this missing feature (using instead a custom runtime, I even know of one that has patched Libvirt with Firecracker support!).

It's "probably not so easy", I agree, but you didn't answer to the part where I specified the daemonless libvirt is not ready yet and that also requires work. So the question is: is libvirt daemon-less "probably easy" and with a lower time to market than taking the "probably not so easy" approach?
NOTE: if the "probably not so easy" fails because the complexity gets too hard to implement unprivileged vfio in kata, then of course libvirt can and should remain the plan B. What I'm objecting is the starting with integrating libvirt without looking at any other option that may provide long term advantages (and in my expectation also short term advantages).

In other words libvirt should also run under PR_SET_NO_NEW_PRIVS at all times, not just qemu.

If you can get code execution in libvirt, you get root:root and pretty much all capabilities too. It would be a no-op and deceiving for Libvirt to set PR_SET_NO_NEW_PRIVS on itself

The idea that you can't trust any software except a very specific black box has no technical justifications in the long term, it's a non technical argument as far as I'm concerned.

That's absolutely not what I said.

Now in reality, libvirt currently is not a lib, but a a daemon, so until the daemon-less libvirt is available

It will be available (though experimental) in Libvirt 6.1.0. Release candidate can already be downloaded.

What I'm objecting is the starting with integrating libvirt without looking at any other option that may provide long term advantages

I think everybody agrees that choosing a dependency over another is a tradeoff. I suggest respectfully that you avoid making blind assertions and wait until code is available. In the meanwhile, you could work on a proof of concept of your suggested approach so that it's possible to compare their relative advantages.

In other words libvirt should also run under PR_SET_NO_NEW_PRIVS at all times, not just qemu.

If you can get code execution in libvirt, you get root:root and pretty much all capabilities too. It would be a no-op and deceiving for Libvirt to set PR_SET_NO_NEW_PRIVS on itself

It is not a noop, it makes a difference to all children of libvirt, instead of forking and setting it in the qemu child libvirt should set it in the parent.
By doing so, it will also make sure that your "debug" example where supposedly somebody was debugging an helper running a suid from qemu, in order to later move it to libvirt, will not risk to work neither in qemu nor in libvirt because it'd be a design mistake (again not a noop).
Even if it was a noop, I don't get what you mean with deceiving, if something it will prevent somebody to do a design mistake, even if it would have no other effect, it's a good hint of what libvirt should keep not doing.

The idea that you can't trust any software except a very specific black box has no technical justifications in the long term, it's a non technical argument as far as I'm concerned.

That's absolutely not what I said, but I don't think it's necessary to discuss this further.

What you said is "advantage of libvirt is that it can be considered a black box as far as Kata is concerned, especially with the new daemon-less operation" and then "Libcontainer is not a black box in that sense. Libvirt is more specific and therefore it can take care of all the security knobs.".
There is no technical argument here that you provided other than we should trust you that a black box should be better "than taking care of many security features manually",  which implies black box isn't manual, non-black-box is manual, which again is not a technical argument.
So ultimately all I can conclude is that you trust the black box more than doing things "manually" for non technical reasons, simply because there's no such thing as a black box or a manual process here, it's just different software.

I think everybody agrees that choosing a dependency over another is a tradeoff. I suggest respectfully that you avoid making blind assertions and wait until code is available. In the meanwhile, you could work on a proof of concept of your suggested approach so that it's possible to compare their relative advantages.

It's the second time you keep asking me to send patches, in case it's not obvious, if I had the time to work on kvm userland, I obviously wouldn't be writing a message here but I would already have sent a patchset instead. If nobody else does it I can still try to find the time to do it myself, but for now my message is only to the kata-runtime upstream developers that have the libvirt integration enhancement in "need-review" mode. They will have to take a decision eventually and I think it's only fair enough that they hear another point of view in case I may have pointed out anything that wasn't already obvious to them.

So ultimately all I can conclude is that you trust the black box more than doing things "manually" for non technical reasons, simply because there's no such thing as a black box or a manual process here, it's just different software.

I think the meaning is obvious. "It's a black box" means "the kata developers can expect Libvirt to set up sandboxing and not care about how that is done" like OpenStack, oVirt, Boxes, virt-manager, Cockpit developers are already doing; while with libcontainer you would have to invoke the APIs manually. That's not bad per se, but it's an aspect that should be taken into account.
I think everybody here is experienced enough to understand that it's just different software, on the other hand ignoring code reuse is more than a bit disingenuous. Is it a "technical reason" or not? I guess that depends on the definition you have of "technical reason".

for now my message is only to the kata-runtime upstream developers that have the libvirt integration enhancement in "need-review" mode.

Ok, thanks for making this clear.

authors: aagit bonzini c3d grahamwhaley

repo: kata-containers/runtime


text:
Is it possible to make a Guess Command?

I wanted to know if it is possible to do something like this with Pawn.CMD, and if it is possible how to do it, thank you very much.
What do I mean by Guess Command? An example would be:
When you type e.g. "/hel"

public OnPlayerCommandPerformed(playerid, cmd[], params[], result, flags)
{
	if(result == -1)
	{
        new guessCmd[32];
        Command_GuessFunc(guessCmd, cmd);
        SendClientMessageEx(playerid, -1, "{FF0000}ERROR:{FFFFFFFF} \"%s\" is not found, did you mean \"%s\"?", cmd, guessCmd);
	}
	return 1;
}
CMD:help(playerid) return 1;

Sorry for my bad English.

Technically, you could use these functions:
native CmdArray:PC_GetCommandArray(); // to get all commands in an array
native CmdArray:PC_GetAliasArray(const cmd[]); // to get all aliases of a command in an array
native PC_GetArraySize(CmdArray:arr); // to get the number of elements of an array (all commands or all aliases array)
native PC_GetCommandName(CmdArray:arr, index, dest[], size = sizeof dest); // get the name of a command from an array, the index from 0 to n (where n is the result of PC_GetArraySize)
native PC_FreeArray(&CmdArray:arr); // to clear the array from the memory, to prevent memory leak

Then, you should be able to create a function that makes use of something like the Levenshtein Distance, which may help you to return the closest matching command name. You can see an example recently done by Y_Less here.
This may get pretty slow, I guess, especially in Pawn.

authors: IstuntmanI noizza


text:
--nofreeze-stdlib fails to include the stdlib

Nuitka version: 0.5.29rc4@60b7d44 on Mint 18 (essentially the same as Ubuntu 16.04)
Installed via pip install git+https://github.com/kayhayen/Nuitka
Repro:

import os

Running nuitka --nofreeze-stdlib --python-flag=no_site --standalone foo.py yields the following:
$ ./foo.dist/foo.exe
Traceback (most recent call last):
  File "/tmp/foo.dist/foo.py", line 1, in <module>
ImportError: No module named os

I can reproduce this. Seems nothing outside foo.py will get compiled unless one also specifies "--recurse-stdlib", which does then. I guess in standalone mode they should be joined. As freezing the stdlib is only relevant there, this kind of shows the whole option is bogus. I will remove it. I think you are not the first to fall for it.

Fixed in 0.5.29

authors: kayhayen mathrick

repo: kayhayen/Nuitka


text:
Make spec pulls more robust

Use gzipped github releases and the github API to pull spec updates.
Added a sanity check test case and some minimal docs
Related issue https://github.com/kbase/relation_engine_api/issues/10

Regarding pulling prereleases for CI, we could make a PR later on. (agile!!) Made an issue for it here: https://github.com/kbase/relation_engine_api/issues/13
My plan was to hit the https://api.github.com/repos/kbase/relation_engine_api/releases endpoint to get the latest prerelease.


text:
Add option for CronJob

@TomAugspurger @yuvipanda @arokem
Having an option to specify a schedule for your job is a feature I think kbatch and it's potential users might benefit from. I've taken a stab at some basic implementation which you can find here: iameskild/cronjob branch diff.
This implementation assumes that the underlying pod-spec template for both Job and CronJob resources are the same. This makes it simple to fold these pod-specs templates into different models, V1Job and V1CronJob respectively. This does ultimately abstracts away the difference between the two different models, at least from the user perspective: "they are all jobs, specify a schedule if you want to".
To specify that you want to run a cronjob instead of a job, you can simply specify a --schedule="* * * * *" from the CLI or config file. I believe this is all that we might need from the user in order to create a cronjob versus a regular job.
The diff reference above has a handful of outstanding to-do's / questions before it's ready to go.

[ ] how does a user stop the cron job?
perhaps there should be a default number of successfully completed jobs after which the cronjob is terminated, something the user can specify
[ ] when the jobs are listed, should there be an additional column for the schedule? or a separate cli command altogether?

This is my attempt at starting a discussion on around this topic but if and when ready, I'd be happy to open a PR and see it through.
Thanks again for considering this feature request :)
cc @Adam-D-Lewis @costrouc

Thanks for opening this up @iameskild, and apologies for the delay. Adding support for CronJobs is totally in scope, and your implementation seems pretty reasonable. I'd say make a PR whenever you're ready.

how does a user stop the cron job?

something like kbatch job --schedule cancel "<job-id>" or similar

when the jobs are listed, should there be an additional column for the schedule? or a separate cli command altogether?

I would say additional column that shows schedule

There is a different between removing a stuck/bad job and removing it from the schedule. Not quite sure how you make the different clear via the cli options.

Closed by #40

authors: TomAugspurger dharhas iameskild

repo: kbatch-dev/kbatch


text:
Extension point enabling custom web sockets

Microsoft's default WebSocket implementation does not work on Windows 7 and Windows 2008 R2 platforms. Alternative web sockets implementation exist that do work on those platforms. Therefore it makes sense to add an extension point, so library users can use Puppeteer on these platforms, without Puppeteer becoming dependent on other WebSocket implementations.

This pull request addresses issue #512.

We have a real fail in AppVeyor

The AppVeyor fail is related to Connection.CloseAsync not being suffciently re-entrant/thread-safe. I am happy to propose an adjustment, but it isn't related to this pull request.

@ggeurts We can't merge a red build, so we'd need a complete solution.

Fine, I will commit a fix

Many thanks for considering, reviewing and using this contribution!

Thank for contributing @ggeurts !

authors: ggeurts kblok

repo: kblok/puppeteer-sharp


text:
Add SPARQL queries to interlink contributors from BnF

During data integration we extract relevant links from BnF dumps to own named graphs

ISNI links in <http://bnf-contributors-isni>
VIAF links in <http://bnf-contributors-viaf>
Wikidata links in <http://bnf-contributors-wikidata>

The sparql query in this file creates links for ISNI according to the Bibframe ontology. The same is needed for VIAF and Wikidata
Then the queries can be written.

There are now 3 SPARQL update queries which try to enrich existing BELTRANS contributor records (via ISNI, VIAF or Wikidata). Additionally, there is 1 SPARQL update query which creates BELTRANS contributors from BnF data in case none of the existent records links already via schema:sameAs.

repo: kbrbe/beltrans-data-integration


text:
Error on starting up homebridge

Dear,
I've installed the plugin and added the lines to the config file:
{
"platform": "telenet-tv-box",
"name": "Telenet TV-box",
"username": "username",
"password": "password"
}
Error on booting homebridge:
4/21/2020, 9:40:32 AM] ====================
[4/21/2020, 9:40:32 AM] ERROR LOADING PLUGIN homebridge-telenet-tv-box:
[4/21/2020, 9:40:32 AM] Error: Cannot find module 'request'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at /homebridge/node_modules/homebridge-telenet-tv-box/node_modules/request-promise/lib/rp.js:11:16
at module.exports (/homebridge/node_modules/homebridge-telenet-tv-box/node_modules/stealthy-require/lib/index.js:62:23)
at Object. (/homebridge/node_modules/homebridge-telenet-tv-box/node_modules/request-promise/lib/rp.js:10:19)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/homebridge/node_modules/homebridge-telenet-tv-box/index.js:2:17)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
[4/21/2020, 9:40:32 AM] ====================
[4/21/2020, 9:40:46 AM] Error: The requested platform 'telenet-tv-box' was not registered by any plugin.
at API.platform (/usr/local/lib/node_modules/homebridge/lib/api.js:134:13)
at Server._loadPlatforms (/usr/local/lib/node_modules/homebridge/lib/server.js:327:45)
at Server.run (/usr/local/lib/node_modules/homebridge/lib/server.js:90:36)
at module.exports (/usr/local/lib/node_modules/homebridge/lib/cli.js:59:10)
at Object. (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

I have the same problem. I also work for Telenet. if there is something I could do please let me know

so I have been looking at the files and compared them to the Ziggo-next plugin...
And it just seems all the words "ziggo" have been replaced with the words "Telenet"
I also see that one of the source links is
https://web-api-prod-obo.horizon.tv/oesp/v3/NL/nld/web/session
horizon is the project name of the ziggo box but the Telenet tv box has another project name...

so I have been looking at the files and compared them to the Ziggo-next plugin...
And it just seems all the words "ziggo" have been replaced with the words "Telenet"
I also see that one of the source links is
https://web-api-prod-obo.horizon.tv/oesp/v3/NL/nld/web/session
horizon is the project name of the ziggo box but the Telenet tv box has another project name...

The API's from all countries work with the horizon.tv link, it just needs to be modified to the right country. It works in every country where they use the Horizon platform (horizon.tv, ziggogo.tv and upctv.ch,...) because they have a login screen on the site itself (you can try it yourself).
However, Telenet decided to make the login process more secure by redirecting to login.prd.telenet.be/openid/login so this plugin won't work.
I don't know how to make it work with this kind of login so if you could help, that would be amazing.

Can you tell me what information exactly you would need to get it to work?
Also the projectname is EOS. for telenet

I have no idea how to bypass this login. The developer of the Ziggo plugin doesn't respond on my question.

I have sent this to one of the guys from Inhome improvement.
also
Error: The requested platform 'telenet-tv-box' was not registered by any plugin.
this error is not because of the extra login of telenet itself

True. The plugin has problems with starting up. However, changing the API's on the Ziggo plug in does not do the job either.

spoken with a guy from Inhome improvement. I don't think this is gonna work... mostly because security issues
maybe you need a new approach.  the controller is working with Zigbee protocol. so might want to use a Zigbee plugin to replace the remote

This is interesting. Does the box also uses Zigbee and any idea how to set them in pairing mode so the Zigbee gateway can find them?

Are you Belgian? maybe we should get a private chat up
FB Wesley Liekens
WA 0486045922

The issue with the plugin not being loaded should be fixed in #2
The plugin is still not working due to not being able to authenticate towards https://web-api-prod-obo.horizon.tv/oesp/v3/NL/nld/web/session (HTTP 500)

This will never works since Telenet uses another login mode than the other companies.

I'm testing as well. Doesn't work, but @kdb-be, could you elaborate? I'm seeing the session url in "network' under developer tools when looking at the telenettv.be web traffic.

any progress

Does this work with all Telenet boxes? Also the old ones? Is there any specific configuration needed on the Digicorder?

Are there any updates on this issue?

same issue over here:
Error loading platform requested in your config.json at position 4
[1/13/2021, 1:05:11 AM] Error: The requested platform 'telenet-tv-box' was not registered by any plugin.
at PluginManager.getPluginForPlatform (/usr/local/lib/node_modules/homebridge/src/pluginManager.ts:224:15)
at /usr/local/lib/node_modules/homebridge/src/server.ts:387:37
at Array.forEach ()
at Server.loadPlatforms (/usr/local/lib/node_modules/homebridge/src/server.ts:374:27)
at Server.start (/usr/local/lib/node_modules/homebridge/src/server.ts:153:29)
at cli (/usr/local/lib/node_modules/homebridge/src/cli.ts:80:10)
at Object. (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
at internal/main/run_main_module.js:17:47

same issue over here:
Error loading platform requested in your config.json at position 4
[1/13/2021, 1:05:11 AM] Error: The requested platform 'telenet-tv-box' was not registered by any plugin.
at PluginManager.getPluginForPlatform (/usr/local/lib/node_modules/homebridge/src/pluginManager.ts:224:15)
at /usr/local/lib/node_modules/homebridge/src/server.ts:387:37
at Array.forEach ()
at Server.loadPlatforms (/usr/local/lib/node_modules/homebridge/src/server.ts:374:27)
at Server.start (/usr/local/lib/node_modules/homebridge/src/server.ts:153:29)
at cli (/usr/local/lib/node_modules/homebridge/src/cli.ts:80:10)
at Object. (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
at internal/main/run_main_module.js:17:47

This plugin will never work. Telenet has an extra layer of security compared to other daughter companies.

This plugin will never work. Telenet has an extra layer of security compared to other daughter companies.

Someone "from the inside" is working on that 😀

Someone "from the inside" is working on that 😀

@WesleyLiekens So maybe we will get a working Hombridge plugin for the Telenet TV Box soon?

I can confirm a successful logon has been achieved and that its being implemented into the plug-in for further testing

I can confirm a successful logon has been achieved and that its being implemented into the plug-in for further testing

What do you mean with "for further testing" by the developers of this plug-in or already for those who installed the plug-in on their homebridge? Because I installed the last version today and I get still this error message:
[2/8/2021, 12:55:23 PM] ERROR LOADING PLUGIN homebridge-telenet-tv-box:
[2/8/2021, 12:55:23 PM] Error: Cannot find module 'request'
Please let me know when I can test it again and if I have to modify something in my config file to define this Telenet TV Box platform.
Thanks

By the developer and his beta testers.

a working plugin has just been released at
https://github.com/jsiegenthaler/homebridge-eosstb
Ideas for updates and contributions are welcome

a working plugin has just been released at
https://github.com/jsiegenthaler/homebridge-eosstb
Ideas for updates and contributions are welcome

I can confirm this too, installed this new beta plugin and works fine with my Telenet TV Box

authors: JonasVanduffel Maffiow WesleyLiekens Wilmaxe arkadicolson iwanvandaele kdb-be keennandebie mcielen modparts wvanvlaenderen

repo: kdb-be/homebridge-telenet-tv-box


text:
KAB-46 prepare structure for metastore metadata to be stored with storage objects

KAB-46

@odinuv přidal jsem teda ty konfigurační metadata jak jsem psal ráno na Slack s tím, že zatím se provider ignoruje. Jakmile to bude ready v connection, tak pošlu další PR na to, aby to fungovalo i s ním.

sem ti dal práva, tak si to mergni a otaguj sám
Aspoň budeš moct říct, že jsi Python vyvojář :)

authors: odinuv tomasfejfar

repo: keboola/sapi-python-client


text:
enable/disable table export&upload

https://keboola.productboard.com/inbox/notes/47380
https://keboola.productboard.com/inbox/notes/141638

related  https://github.com/keboola/connection/issues/763

authors: kacurez odinuv

repo: keboola/tde-exporter


text:
Find a way to monitor adoption and basic usage

Not sure what flavor this will take (docker pulls, optional phone home? Etc) but would be good to have some pipeline to know how many people are using KEDA, and ideally which features, to help us plan and prioritize better. Realize this may not be possible given the open nature but wanted to at least have the conversation

Docker pull sounds feasible indeed, a phone home is more tricky as this can be "an issue" from a security perspective.
If the goal is to prioritize scalers then I think this will grow over time once the community starts to grow.

authors: jeffhollan tomkerkhove

repo: kedacore/keda


text:
Kafka scalers to support multiple topics

Proposal
The kafka scaler is autoscaling based on single topic, but in some of scenarios we have multiple topics for 1 service and instead of adding multiple kafka scaledobject/triggers, the request is to provide support to autoscaling based on multiple topics in one Kafka trigger.

type: kafka
metadata:
bootstrapServers: localhost:9092
consumerGroup: my-group
eventSources:
- topic: test-topic-1
lagThreshold: "50"
-  topic: test-topic-2
lagThreshold: "50"

Ref Issue - https://github.com/kedacore/keda/issues/828
Use-Case
This will help to reduce extra effort of creating multiple scaledobject.
Is this a feature you are interested in implementing yourself?
No
Anything else?
No response

The current implementation doesn't allow this, the preferred solution is to create a separater trigger for each topic.
There is a proposal to support more flexible Kafka configuration https://github.com/kedacore/keda/issues/2447 you can take a look and contribute :)


text:
Behaviour on non active scaling triggers

Current behaviour is is that when the metric is not available ("unkown") keda scales the deployment to minimum. It will be nice to configure what to do with this case: Not scale at all (leave the previous number of pods), scale to a configurable number of pods or to minumum.
EDIT: Not sure whether this is the isActive (I checked it on 0 min so I got to it but it seems that isActive is to scale form 0 or not). Anyway, keda scales my deployment to zero when metrics are unavailable (checked by changing the promtheus address to wrong address)
Use-Case
Option to deal with disaster of Prometheus (or other scalers sources) falling/not responding.
Specification

Option to configure static number of pods (different from minimum) when metrics source is unavailable (trigger is inactive)
Option to disable the scaling when trigger is inactive (leave the number of pods as it was when it was last active)

Interesting idea. As you proposed this would require to change the logic of isActive and introducing additional logic.
My concern is, that I am not sure that for all scalers we can distinguish between "unknown" and "not active" state. But I am not sure about this.

This seems like the same request, am I right? https://github.com/kedacore/keda/issues/965

Yes, #965 seems like the same problem


text:
Add a scaler based on a GCP Stackdriver metric

feat: Add a scaler based on a GCP Stackdriver metric
Add a scaler based on a metric value obtained from GCP Stackdriver
Fixes: #2661
Signed-off-by: Ram Cohen ram.cohen@gmail.com

/run-e2e gcp-stackdriver.test.ts

@RamCohen one last nit, update Changelog please 🙏

It seems that you have any commit that it's not singed.
Could you solve it?

/run-e2e gcp-stackdriver.test.ts

Thanks a lot @RamCohen!

authors: JorTurFer RamCohen zroubalik


text:
chore: build with keda-tools:1.22.5

Provide a description of what has been changed
This PR is to build keda container images with an updated version of keda-tools with latest version of Go to resolve CVE-2024-24790, CVE-2024-24789, and CVE-2024-24791. Related PR: https://github.com/kedacore/test-tools/pull/169
Also bumping github.com/Azure/azure-sdk-for-go/sdk/azidentity to resolve CVE-2024-35255.
Checklist

[x] Changelog has been updated and is aligned with our changelog requirements
[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

CVE-2024-24790
CVE-2024-24789
CVE-2024-24791
CVE-2024-35255

Relates to #
https://github.com/kedacore/test-tools/pull/169

I guess that we need to bump the user version too:

I'd say that it's a good moment to bump go version, don't you think @zroubalik ?

I guess that we need to bump the user version too:
I'd say that it's a good moment to bump go version, don't you think @zroubalik ?

I tested locally for both go 1.21 and go 1.22 set and it seemed to work fine either way.

You can check all the places to change here: https://github.com/kedacore/keda/pull/5734/files

Also, I think we should bump go version in the Devcontainer too, right?

Yeah, you can check all the places to change here: https://github.com/kedacore/keda/pull/5734/files

In the Devcontainer's Dockerfile, I had to change the way go modules were installed. Bumping to 1.22.5 gave me errors about running go get outside of a module. So I had to use go install instead.
Also, after looking through the Devcontainer files, there seems to be a bit of code that could use some cleanup. For instance, in the Dockerfile I see that it configures a non-root user vscode but runs as root (probably for Docker CLI). Also, might be able to leverage devcontainer features in the devcontainer.json file to load some of the tooling instead of baking them all into the container. I can create an issue for this and work on cleaning this up if that's okay.

I can create an issue for this and work on cleaning this up if that's okay

Yeah, let's do it

I can create an issue for this and work on cleaning this up if that's okay

Yeah, let's do it

Sounds good! Anything else I need to do for this particular pull request?

Revert the changes related with the devconainter to not break the CI and solve merge conflicts please.
@zroubalik , do you see any problem updating golang version for the release?

Merge conflict has been resolved 😁

Hi @JorTurFer,
Once this PR is merged, is it possible to cut a release for KEDA 2.14.1?

We plan to ship v2.15 next week and I'd like to include the golang bump. Is it enough? We don't plan any other release for v2.14

/run-e2e internal

/run-e2e azure

authors: JorTurFer pauldotyu qpetraroia


text:
kedro-datasets: Rename MatplotlibWriter to MatplotlibDataset

Description
MatplotlibWriter has been the only dataset with inconsistent naming for a while. There are a couple of more subtle issues with it still to be fixed (see
https://github.com/kedro-org/kedro/issues/1645), but I think we should use the dataset renaming (which is a breaking change whatever) as an opportunity to make it consistent with the rest of the codebase
Context
Consistency is better :)
Possible Implementation
Rename MatplotlibWriter to MatplotlibDataset.
Possible Alternatives
Don't do it ;)
This is likely a great ticket for Hacktoberfest if the project is eligible?

Nice idea, I asked in the team and start tagging issues.

This affects Kedro-Viz, since they use MatplotlibWriter in various places. To retain backwards compatibility, they would probably have to do some try ... except with imports. cc @rashidakanchwala @tynandebold
I think this goes to some of our findings in https://github.com/kedro-org/kedro/issues/1936: that we don't really intend to implement _load for certain datasets (including this one) because they're meant to be artifacts and not really full I/O components.

Regardless, for consistency I agree we should rename it 👍🏽

https://kedro-org.slack.com/archives/C03RKP2LW64/p1695929737315389
An user ask why load is not supported? Maybe this is the reason why it is called Writer but not Dataset. I don't use this dataset myself so I can't remember is it always like this.

Maybe we could have a MatplotlibFigureDataset (that saves and loads figures objects as pickles) (although maybe we shouldn't and we should tell users to use PickleDataset for this) and MatplotlibImageDataset (that only saves images and has no _load)

Actually it totally makes sense that some dataset don't have _save method (API Dataset didn't for a while, SQLQueryDataset still doesn't...). Can I start a PR for this or the impact is too high on kedro-viz?

Yeah I don't think it's a problem that some datasets don't have _save. What's problematic is the monkeypatching that kedro-viz does on some of them https://github.com/kedro-org/kedro-viz/issues/1352
About the impact on Kedro Viz, cc @rashidakanchwala @tynandebold

Yes, it will. We will be looking at making sure Kedro-viz is not so coupled with Kedro-datasets. And we are going to prioritise this work in the second half of November most likely. Until then, we could pin kedro-viz to kedro-datasets to the current version.

I don't think this is a good first issue, there's some uncertainty still https://github.com/kedro-org/kedro-plugins/issues/353#issuecomment-1740974418 removing the label, when we have more clarity we'll update this issue

Kedro-Viz has made significant changes to decouple from kedro-dataset, would renaming MatplotlibWriter still be an issue @rashidakanchwala ?

nope this is not an issue. Kedro-viz only reads NewType = 'image' from preview method so it should be fine.

authors: Galileo-Galilei astrojuanlu merelcht noklam rashidakanchwala

repo: kedro-org/kedro-plugins


text:
Next day in evening?

Sometimes it thinks it's the next day after 9pm or so, not sure why. Maybe time zone is not set?

It uses UTC time. There is an option in the config.ini file to supposedly fix this, but it seems to not be working.

repo: keeganstoner/taskell