Docker may easily support seccomp on Ubuntu 14.04 without the need for static binaries

Quoting https://github.com/docker/docker/blob/master/docs/security/seccomp.md:

Note: seccomp profiles require seccomp 2.2.1 and are only available starting with Debian 9 "Stretch", Ubuntu 15.10 "Wily", Fedora 22, CentOS 7 and Oracle Linux 7. To use this feature on Ubuntu 14.04, Debian Wheezy, or Debian Jessie, you must download the latest static Docker Linux binary. This feature is currently not available on other distributions.

In Ubuntu 14.04 I'm able to install the Ubuntu 16.04 kernel (currently 4.4.8) by installing the linux-generic-lts-xenial package and the current version of seccomp (2.2.3) by installing from the trusty-backports repository.  All the SECCOMP kernel configuration variables are enabled in /boot/config-$(uname -r).

@ricardobranco777 yes, it's possible, and you can possibly install a dynamically linked binary from the "wily" repository to get it to work, however, it's not a default install, so for that reason it's not enabled in the binary.
If you're using aufs, running a static binary should work fine though, so that's the "official" way to get it supported.

See also https://github.com/docker/docker/issues/22453 for discussion of whether to support seccomp in Debian Jessie via backports.

I'm closing this, because this is not something we'll change, but as mentioned, there's other ways to get this working. Thanks for suggesting, and possibly this will help someone to get it working

@thaJeztah Ubuntu Wily (15.10) is based on systemd and it's not a LTS release...  Also remember that Docker dropped support for Ubuntu Vivid (15.04) for the 1.10 release, so it's not a viable option.
I consider that adding support for seccomp to a LTS release such as 14.04 is the sensible and correct approach.  It wouldn't be that hard to add the necessary bits and I'm more than willing to submit the necessary patches.
Regards,
R.

@ricardobranco777 Ubuntu 16.04 is a LTS release, and offers seccomp out of the box; I don't think forcing people to switch to a different kernel than the one that's default by the upstream distro is the way to go. To my knowledge, 3.13 is still the default for Ubuntu 14.04, and the Xenial kernel not yet supported; https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Kernel.2FSupport.A14.04.x_Ubuntu_Kernel_Support

@thaJeztah The kernel version shipped with 14.04.4 is 4.2:
https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes
The kernel shipped with 14.04.3 was 3.19; with 14.04.2 it was 3.16.
Regards,
R.

PD: Requiring users to install the Xenial kernel isn't at all necessary.  Migrating to Ubuntu 16.04 is not an option to many users considering that it was released just recently, and the updated GCC changed the ABI.  This ABI change breaks a lot of stuff.

@ricardobranco777 for a bare-metal install, but on cloud providers, 14.04.4 still runs with the standard "trusty" kernel in many cases. Breaking those installs is not something we can easily do; especially not if there are alternatives. Also see this note on the same page;

Those running virtual or cloud images should not need this newer hardware enablement stack and thus it is recommended they remain on the original Trusty stack.

@thaJeztah The LTS HWE stack (something I use on my Linux Mint 17.3 laptops and Ubuntu servers) let the users upgrade their kernels and X11 libraries to the ones used by the latest version of Ubuntu.  It's irrelevant to this particular situation, I think.
We just need to detect if a suitable kernel & seccomp version is available, either on installation or initialization time, and voilà! =)
Static binaries are cumbersome because we cannot patch them when security updates are available for libraries like gcrypt, and requiring static binaries to use a vital security component like seccomp is crazy.  A bug in libgcrypt and the decission must be made to drop seccomp.
I think this issue needs reconsideration.  There is a large user base for Ubuntu 14.04 that will remain for at least a year o so.
Regards,
R.

Can we reopen this issue to allow more people to contribute their opinions on this subject?  We need a sensitive approach for this...
I've just finished reading https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/april/understanding-and-hardening-linux-containers/ and consider that enabling seccomp should be mandatory.  Also the broad user base of Ubuntu 14.04 would help in testing.

I'll reopen so that others can weigh in, but this won't make it into a 1.11 release, 1.12 at it's earliest; making these kind of changes are dangerous, and can break a lot of installs easily

ping @jfrazelle @tianon as well

Thanks a lot! @thaJeztah =)

If canonical wants to include seccomp support (and the required minimum version) in a stock 14.04 install, then great.
We could probably even add docs "if you really want seccomp on 14.04 you must do X,Y,Z"...
But otherwise I'd say 👎

@cpuguy83 We could use the same approach that is used with AppArmor...  If the apparmor package is installed, then a profile is installed.

@ricardobranco777 the build of docker we ship is always linked to libapparmor on ubuntu, and installing docker will always install that package.

@justincormack Maybe we could link to libseccomp2 as well and display a warning when 2.2.1 is not being used?
The libseccomp-golang library that Docker uses supports 2.1.0 as the minimal version, exactly the one that comes with Trusty as default.
We can not use the official wily binary.  Here is the output from ldd(1):

$ ldd docker | grep not.found
./docker: /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1: version `DM_1_02_97' not found (required by ./docker)
libsystemd.so.0 => not found

Regards,
R.

Any objections so far?
I compiled the example C program from seccomp_rule_add(3), dynamically linked to the default libseccomp2 library from Trusty, then installed the libseccomp2 library from trusty-backports.  The linker runs just fine.
Before:

$ ldd a.out | grep libseccomp
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fc988cea000)

After:

$ ldd a.out | grep libseccomp
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f466d4e8000)

Missing libdevmapper is a lot different that missing the seccomp lib. We
cannot break everyone's binaries when they upgrade on trusty just for this.
I would love to have it supported but until it is easy for people on trusty
to get the correct version we can't just be like YOLO can't upgrade and if
you do pls install libseccomp from src
On Fri, May 27, 2016 at 10:16 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

Any objections so far?
I compiled the example C program from seccomp_rule_add(3), dynamically
linked to the default libseccomp2 library from Trusty, then installed the
libseccomp2 library from trusty-backports. The linker runs just fine.
Before:
$ ldd a.out | grep libseccomp
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2
(0x00007fc988cea000)
After:
$ ldd a.out | grep libseccomp
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2
(0x00007f466d4e8000)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222202595,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbANS2C57mAh_8qif92I5NkWKG3rBks5qFybTgaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

We link to libapparmor and install it for people it is in the packages provided by the OS, what we check IS if apparmor is enabled in the kernel.

this is very very different

@jfrazelle Then it's just a question to make libseccomp a hard dependency and the linker will take care.  There's no need to install the proper libseccomp from src as the binaries come from trusty-backports.

What if they dont have backports.
On Fri, May 27, 2016 at 10:39 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

@jfrazelle https://github.com/jfrazelle Then it's just a question to
make libseccomp a hard dependency and the linker will take care. There's no
need to install the proper libseccomp from src as the binaries come from
trusty-backports.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222208111,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbKIgzBIxWYubtWR5Fx5Q3TYX1jI9ks5qFyw3gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

The trusty-backports repository comes in a line commented by default in /etc/apt/sources.list.  Any security conscious user would just uncomment that line, run "apt-get update" and "apt-get install libseccomp2/trusty-backports" and the issue is gone.

See the problem is many many users do not do this, and there will be
massive amounts of issues to us when people cannot upgrade docker.
On Fri, May 27, 2016 at 10:45 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

The trusty-backports repository comes in a line commented by default in
/etc/apt/sources.list. Any security conscious user would just uncomment
that line, run "apt-get update" and "apt-get install
libseccomp2/trusty-backports" and the issue is gone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222209560,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbIGRtaK8HXpH3pGAfbLzuvY69E0Lks5qFy21gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Trusty is one of the most popular distros. I really fear doing this.
On Fri, May 27, 2016 at 10:48 AM, Jessica Frazelle<EMAIL_ADDRESS>wrote:

See the problem is many many users do not do this, and there will be
massive amounts of issues to us when people cannot upgrade docker.
On Fri, May 27, 2016 at 10:45 AM, Ricardo Branco<EMAIL_ADDRESS>
wrote:

The trusty-backports repository comes in a line commented by default in
/etc/apt/sources.list. Any security conscious user would just uncomment
that line, run "apt-get update" and "apt-get install
libseccomp2/trusty-backports" and the issue is gone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222209560,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbIGRtaK8HXpH3pGAfbLzuvY69E0Lks5qFy21gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

The docker apt repo gets hit by CIs, people building AMIs, etc etc, this
results in millions of downloads per day. I cannot recommend this. I'm
sorry.
On Fri, May 27, 2016 at 10:48 AM, Jessica Frazelle<EMAIL_ADDRESS>wrote:

Trusty is one of the most popular distros. I really fear doing this.
On Fri, May 27, 2016 at 10:48 AM, Jessica Frazelle<EMAIL_ADDRESS>wrote:

See the problem is many many users do not do this, and there will be
massive amounts of issues to us when people cannot upgrade docker.
On Fri, May 27, 2016 at 10:45 AM, Ricardo Branco <
<EMAIL_ADDRESS>wrote:

The trusty-backports repository comes in a line commented by default in
/etc/apt/sources.list. Any security conscious user would just uncomment
that line, run "apt-get update" and "apt-get install
libseccomp2/trusty-backports" and the issue is gone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222209560,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbIGRtaK8HXpH3pGAfbLzuvY69E0Lks5qFy21gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Indeed, as Jess has pointed out, it wouldn't be just security-conscious
users that would need to do that, but all users (if a ".so" file we link
against is unavailable, libc will refuse to allow our binary to run).

Running Docker without seccomp support, or running the static binaries with a possibly outdated libgcrypt is not what security-conscious users need.
Consider the large user base of Ubuntu Trusty users that may help in testing seccomp on Docker.  Those users will not migrate en masse to Ubuntu 16.04 just to get seccomp for at least 2 years because of:

The ABI breakage that came with the updated GCC package makes it impossible for us to use some Debian Jessie packages (and Debian Stretch is unstable).

Ubuntu 16.04 was released just recently and many will expect a point release.

Systemd

Trusty is one of the most popular distros. I really fear doing this.

Precisely because it is one of the most popular distros, we need to include seccomp.  Just making libseccomp2 a hard dependency in the .deb package is what we need.

@ricardobranco777 So we fail the install if libseccomp2 isn't available?
No, we can't do this. This is effectively a major breaking change.

I understand the urge to want to make everyones lives better w seccomp.
Really I wish we could. But you unfortunately will not be on the other side
of the huge influx of breakage to people if we do this. The risk is not
worth it. We have a duty to our users to not break them by default.
On Fri, May 27, 2016 at 10:52 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

Running Docker without seccomp support, or running the static binaries
with a possibly outdated libgcrypt is not what security-conscious users
need.
Consider the large user base of Ubuntu Trusty users that may help in
testing seccomp on Docker. Those users will not migrate en masse to Ubuntu
16.04 just to get seccomp for at least 2 years because of:

The ABI breakage that came with the updated GCC package makes it
impossible for us to use some Debian Jessie packages (and Debian Stretch is
unstable).
2.
Ubuntu 16.04 was released just recently and many will expect a point
release.
3.
Systemd
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222211214,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbCyODi4CXwVuk3Nl_rP_vZKGEBXlks5qFy9ggaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@cpuguy83 apt-get install docker-engine will take care of installing the needed dependencies...

No. And I will not argue any further about this. The point is clear. People
will break. We do not support breaking people.
On Fri, May 27, 2016 at 10:54 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

Trusty is one of the most popular distros. I really fear doing this.
Precisely because it is one of the most popular distros, we need to
include seccomp. Just making libseccomp2 a hard dependency in the .deb
package is what we need.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222211686,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbPIw43zTnnQQsh0EFfF8WCPIYjTlks5qFy_agaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@ricardobranco777 if the package is available, which it won't be for many.
Again, if Canonical wants to put support the right version of libseccomp on 14.04 in the trust repos, then great, otherwise nope.

libseccomp2 2.1.0 resides in the main repository for Trusty.  It is the 2.2.3 version that resides in trusty-backports.  It won't break anything...

No it will not if they dont have backports enabled. I know some users do
this but A LOT do NOT.
On Fri, May 27, 2016 at 10:56 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

@cpuguy83 https://github.com/cpuguy83 apt-get install docker-engine
will take care of installing the needed dependencies...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222212169,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbFHnKP2PL_UaiW4uockEQcuKQKxeks5qFzA_gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

We have a minimum req of v 2.2.1.

@cpuguy83 Yes, but it won't break anything.  It's a question of detecting at runtime if the right version is available...

No because if we compile and link to one then it will try to find that
version. There are errors in apt for this. We are not going to have people
install the wrong version just to install the wrong version.
On Fri, May 27, 2016 at 11:01 AM, Ricardo Branco<EMAIL_ADDRESS>wrote:

@cpuguy83 https://github.com/cpuguy83 Yes, but it won't break anything.
It's a question of detecting at runtime if the right version is available...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222213506,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbCqOa5Fk08JeG5H8Bp2WTPQhmBxMks5qFzGMgaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

I guess we're drowning in a cup of water...
There won't be APT errors if we use the version in main.  It would be up to the user to upgrade using trusty-backports.  The linker will take care of everything.

Without reading the entire thread I wanted to chime and say we are desperate for this feature without a static install on 14.04 because we cannot upgrade to 16.04.  The block storage we use (at Packet) has problems with 16.04 because there were a lot of changes between 14.04 and 16.04, we currently use that block storage for container storage.

Why can't you use a static binary
On Sat, May 28, 2016 at 12:30 PM, Jordon Bedwell<EMAIL_ADDRESS>wrote:

Without reading the entire thread I wanted to chime and say we are
desperate for this feature without a static install on 14.04 because we
cannot upgrade to 16.04. The block storage we use (at Packet) has problems
with 16.04 because there were a lot of changes between 14.04 and 16.04, we
currently use that block storage for container storage.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222325620,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbGuuyoXpD4OWpT0NgQs91TUBGytOks5qGJe-gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

I am curious, but I hope you will read the thread and see why we can't do
this :)
On Sat, May 28, 2016 at 12:35 PM, Jessica Frazelle<EMAIL_ADDRESS>wrote:

Why can't you use a static binary
On Sat, May 28, 2016 at 12:30 PM, Jordon Bedwell<EMAIL_ADDRESS>
wrote:

Without reading the entire thread I wanted to chime and say we are
desperate for this feature without a static install on 14.04 because we
cannot upgrade to 16.04. The block storage we use (at Packet) has problems
with 16.04 because there were a lot of changes between 14.04 and 16.04, we
currently use that block storage for container storage.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222325620,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbGuuyoXpD4OWpT0NgQs91TUBGytOks5qGJe-gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@jfrazelle we can use a static binary, we just prefer not to because the static binary requires us to adjust the way we automate and test our servers on upgrade, meaning right now most of our stuff is handled by apt and Docker, we would have to introduce a new recipe to deal with static Docker because AFAIW it's not provided by the apt repositories.

It's just not the entire thread but this book:
Understanding and Hardening Linux Containers
Basically, Docker without seccomp is just another devops toy.  The only objection so far is the libseccomp dependency that I've - hopefully - demonstrated as a non-issue.
Regards,
R.

@envygeeks Do not use static binaries.  You can't upgrade libraries like libgcrypt when security issues arise, and these issues DO arise and the binaries are not updated, just like the nginx Docker image when the recent OpenSSL issues appeared just recently.

So I have no idea why you are the ones arguing with us when we are doing
what is right for the majority of people here. Same goes into the design of
the seccomp feature to begin with since it is secure by default. A LOT of
thought went into the syscalls blocked by the profile so we would not break
people. That is the same idea here. I honestly hope you can understand we
take a lot of thought into these things and unfortunately this hack could
break a lot of people with backports not set up and involves linking to
packages that are not provided in the default trusty repos.
On Sat, May 28, 2016 at 1:03 PM, Ricardo Branco<EMAIL_ADDRESS>wrote:

It's just not the entire thread but this book:
Understanding and Hardening Linux Containers
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/april/understanding-and-hardening-linux-containers/
Basically, Docker without seccomp is just another devops toy. The only
objection so far is the libseccomp dependency that I've - hopefully -
demonstrated as a non-issue.
Regards,
R.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-222327066,
or mute the thread
https://github.com/notifications/unsubscribe/ABYNbAF0emilGrnM7Ur6iKD_Cxrt9qxYks5qGJ98gaJpZM4IjpKD
.

--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

@jfrazelle There's no "hack" involved.  Just a hard dependency on libseccomp2 (which Ubuntu pulls from  the main repository), and security-conscious users just have to upgrade to libseccomp2 from trusty-backports if they want to.  No breakage will happen because the linker takes care of everything and the ABI is stable.

PD: Please just test it. ;)

I hope you're not currently deploying on Virtual Machines, or (shudder) bare metal, because there's no seccomp profiles there at all.
seriously though; we get your point, and we too like to have seccomp profiles available to as many people as possible. Weighing between no seccomp (by default) and bringing down thousands of installations, we decided to go for the first one.
then again, it's all open source, so pull requests are always an option

@thaJeztah No deployment on VM's, just bare metal. =)

What I don't understand is why all can't be pleased? It's just as easy to supply docker-engine-backports that compiles against Ubuntu Backports constantly and will fail to install unless you use Backports and regular old Docker.  This problem is going to arise again for Ubuntu 16.04 regardless, because Docker is a fast moving target and will eventually demand a current version of a library that isn't available and will need backports again, having two packages would solve that problem no?

@envygeeks As long as there's no ABI breakage (the real breakage we should worry about), there's no problem.  It's just an issue for secure deployment to install the updated version.
Indeed, it should be possible to install the latest seccomp from sources and Docker should have no problems at all.  If there's no ABI breakage, everything is fine

Make a pull request and I will personally test it :) and if you are right it would be great
On Sat, May 28, 2016 at 1:36 PM -0700, "Jordon Bedwell"<EMAIL_ADDRESS>wrote:
What I don't understand is why all can't be pleased? It's just as easy to supply docker-engine-backports that compiles against Ubuntu Backports constantly and will fail to install unless you use Backports and regular old Docker.  This problem is going to arise again for Ubuntu 16.04 regardless, because Docker is a fast moving target and will eventually demand a current version of a library that isn't available and will need backports again, having two packages would solve that problem no?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

And yes this will always be a problem if we are adding new things that link to new libraries we are not obtuse and no we are not the enemy here. Package managers are... Just kidding but really we all just want to do the right thing

I'll see what I can work out this week when I have time.

This is the patch to contrib/builder/deb/amd64/ubuntu-trusty/Dockerfile
`--- a/contrib/builder/deb/amd64/ubuntu-trusty/Dockerfile.old
+++ b/contrib/builder/deb/amd64/ubuntu-trusty/Dockerfile
@@ -4,7 +4,7 @@
FROM ubuntu:trusty
-RUN apt-get update && apt-get install -y apparmor bash-completion btrfs-tools build-essential curl ca-certificates debhelper dh-apparmor dh-systemd git libapparmor-dev libdevmapper-dev libltdl-dev  libsqlite3-dev pkg-config libsystemd-journal-dev --no-install-recommends && rm -rf /var/lib/apt/lists/*
+RUN apt-get update && apt-get install -y apparmor bash-completion btrfs-tools build-essential curl ca-certificates debhelper dh-apparmor dh-systemd git libapparmor-dev libdevmapper-dev libltdl-dev libseccomp-dev libsqlite3-dev pkg-config libsystemd-dev --no-install-recommends && rm -rf /var/lib/apt/lists/*
ENV GO_VERSION 1.6.2
RUN curl -fSL "https://storage.googleapis.com/golang/go${GO_VERSION}.linux-amd64.tar.gz" | tar xzC /usr/local
@@ -12,5 +12,5 @@ ENV PATH $PATH:/usr/local/go/bin
ENV AUTO_GOPATH 1
-ENV DOCKER_BUILDTAGS apparmor pkcs11 selinux
-ENV RUNC_BUILDTAGS apparmor selinux
+ENV DOCKER_BUILDTAGS apparmor pkcs11 seccomp selinux
+ENV RUNC_BUILDTAGS apparmor seccomp selinux`

@jfrazelle I'm pushing this change in upstream too, but having Docker support seccomp just in case (because there is really no problem at all) would help a lot.
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1580558/comments/2
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1586496
But, please, do not expect Ubuntu package maintainers to upgrade just as soon.  Docker may work just as easily with seccomp compiled from sources too.

Ya I tried the upstream route as well when we first added it. It's very hard to get them to change a package like that.

@jfrazelle they might placed it in backports if you would have provided an updated version and sent a backport request linking the current version against the version of seccomp in Trust-Backports.

@envygeeks Dynamic linking works with the package in main and the package in trusty-backports because there's no ABI breakage.

After its in backports it's less likely to be moved up to stable, at the time jessie didn't have it in backports and we were hopeful, the maintainer of the jessie package is also the main author of seccomp, but sometimes there is nothing anyone can do.

@ricardobranco777 I understand that (and I already knew that,) there is no need to keep repeating it.  I was making a statement that was async to all that.

@jfrazelle what I would normally do is make the changes for the release above it and then backport it.  So I would make the change in 16.10, request it be backported to 16.04 once it works in 16.10.  I guess I should have mentioned that but I'm doing a million things at once right now.

Better would be to make the change in Debian Unstable, request a resync, then request a backport, then you hit Debian and Ubuntu and win all the way around!  It's really early in the 16.10 cycle so if those seccomp changes haven't at least landed for 16.10 we can get it in there and into 16.04 before the next release (16.10 and 16.04.1 and then 14.04.)

On the importance of libseccomp, released just recently by the NCC Group:
Abusing Privileged and Unprivileged Linux
Containers

Looks like there's an error in that document though;

However, as of Docker 1.11.1, seccomp is now used by default on trusty as well.

It's not like we are depriving you :) maybe check out a issue from yesterday that would show just how many people would have your throat if installing docker broke
On Fri, Jun 3, 2016 at 6:48 AM -0700, "Ricardo Branco"<EMAIL_ADDRESS>wrote:
On the importance of libseccomp, released just recently by the NCC Group:
Abusing Privileged and Unprivileged Linux
Containers
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

They might have meant the static binaries but I'm sure we can let the author know

@jfrazelle oh was already writing in the #sec channel, but are you in contact with Jesse?

I know Aaron his coworker the own who wrote the War and Peace version I can let him know :)

@jfrazelle cool, thanks; I also slacked it, so let him know that he may be spammed from two sides

@jfrazelle - @NathanMcCauley knows how to contact him, so it's should be taken care of 👍

Sweet because I've started too many fires already today and it's only 8am

Looks like there's an error in that document though;

However, as of Docker 1.11.1, seccomp is now used by default on trusty as well.

I read this quickly by skim and then got so excited and then I was like OH, boo.

The discussion on LWN:
http://lwn.net/Articles/689453/#Comments
On Fri, Jun 3, 2016 at 9:29 AM, Jordon Bedwell<EMAIL_ADDRESS>wrote:

Looks like there's an error in that document though;
However, as of Docker 1.11.1, seccomp is now used by default on trusty as
well.
I read this quickly by skim and then got so excited and then I was like
OH, boo.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/22870#issuecomment-223593756,
or mute the thread
https://github.com/notifications/unsubscribe/AJw3N90CNXNbpib8PfI8biGPc-hOYjmJks5qIDpQgaJpZM4IjpKD
.

I'm still unsure what you are trying to prove to us we have established we aren't against this but we are against breaking people. But maybe you've never experienced being on the front page of hacker news when people can't download or install your project

We obviously aren't obtuse, we implemented the feature in the first place! To make people secure by default! Which a lot of other container runtimes do not do. So I'd appreciate it if this conversation was kept towards implementation and testing to make sure there is no breakage. Thanks.

@ricardobranco777 I'm the author of the War and Peace on Containers you referenced while back. I talked with my co-worker Jesse and we'll be updating the paper to reflect that, unfortunately it's not enabled by default, sorry for this misstatement. @jfrazelle is fighting the good fight though, there are a LOT (too many) people still using ole Trusty, and the devs are just trying to be careful. I agree the Docker docs should be 100% clear though, nobody wants a false sense of security.

Thanks @dyn-, and thanks for a great writeup!

LOL.  The War and Peace title fits perfectly.  Thanks a lot @dyn-
I stick to my stance that nothing would break, given the reasons above.

Done, instructions for testing are on the PR https://github.com/docker/docker/pull/23245

Thanks a lot, @jfrazelle !!

Close this as 23245 was closed as well.

Will reopen when get some upstream progress.

Meh, Ubuntu 14.04 is dead to me.  I don't care.

I filed the bug upstream and no response.  They don't care.  I won't, neither


pell: 0.0.3 -> 0.0.4

Motivation for this change

New features
New options

Things done

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

[x] NixOS
[] macOS
[x] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thanks!


SAK-33515 Wrapped hibernate flush in try catch

Hibernate will throw an exception if there is no current session.

Nice


Fix exp standardize

Init block size was not used correctly as noticed in https://github.com/TNTLFreiburg/braindecode/issues/56
Test was too unspecific to catch it. Now fixed it and made test more specific (would have failed on old code).

superstrangeto me that test_trialwise_decoding now fails . It doesn't use the changed functions at all. also still runs fine on my machine, so I maybe something changed in an underlying library? like mne/skorch? errors seem a bit big to be due too hardware fluctuations I would say? very strange.

I just compared versions between this log and our master build and the most suspected one is skorch 0.7.0 -> 0.8.0.
If we want to test it, mybe we can add skorch version 0.7.0 to the requirements file and in the environment.yml?
There is also a change in numpy and mne, that's what I checked so far, but I do not think that it may be responsible for that.

I confirmed also on my machine it fails with skorch 0.8.
These are change in skorch 0.7->0.8: https://github.com/skorch-dev/skorch/compare/v0.7.0...v0.8.0#diff-7cbd7999ce1895528c101345c52cbae4 https://github.com/skorch-dev/skorch/releases
From the tests:

Seems that first values is always correct (like at start of training), then from second on, values are different
test_cropped_decoding.py still everything correct

To me still not clear how this is possible. If it is change in randomization, would expect also test_cropped_decoding.py to fail. If change in scoring logic, why are the first values always ok?


@conda-forge-admin, please add bot automerge

@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/robotframework-sapguilibrary-feedstock#3.


crash when trying to set spawner

hey I tried to ask on discord, but you don't seem to be active there and on another post you mentioned asking on the github instead, but let me know if this needs to be removed or is breaking a rule :)

https://mclo.gs/aVYcwPm


MQTT not working with Home Assistant 0.78.3

Home Assistant release with the issue:
0.78.3
Last working Home Assistant release (if known):
0.77.3 (working version of a friend)
Operating environment (Hass.io/Docker/Windows/etc.):
Raspian Lite
Component/platform:
https://www.home-assistant.io/docs/mqtt/
Description of problem:
As you can see in the changelog of the 0.78.0 release there was a version upgrade of hbmqtt to 0.9.4. After the upgrade this error occurs multiple times:
WARNING (MainThread) [hbmqtt.mqtt.protocol.handler] BrokerProtocolHandler Unhandled exception in reader coro: IncompleteReadError('0 bytes read on a total of 1 expected bytes',)
When I downgrade hbmqtt to version 0.9.2 with pip3 it works again, until I restart hass.io and it gets automatically upgraded again.
pip3 install hbmqtt==0.9.2
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
sensor:
  - platform: mqtt
    state_topic: "room/humidity"
    name: "Room Humidity"
    unit_of_measurement: "%"
    value_template: "{{ value | round(2) }}"
    device_class: humidity

Additional information:
The problem occurs also, if I use the MQTT "Publish a packet" on the frontend.

The warning you get is a known issue (https://github.com/beerfactory/hbmqtt/issues/119) but it isn't affecting the usage of hbmqtt. At least not for me. Your configuration works fine on dev.
sensor:
  - platform: mqtt
    state_topic: "room/humidity"
    name: "Room Humidity"
    unit_of_measurement: "%"
    value_template: "{{ value | round(2) }}"
    device_class: humidity

$ mosquitto_pub -V mqttv311 -u homeassistant -P <your api password>  -t "room/humidity" -m 53.89556

Service call mqtt.publish works as well.
{
   "payload":59.2234234,
   "topic":"room/humidity"
}

So if it's working on dev, I'll wait for the next release and update this issue.

still not working with latest 0.79 release
Manual publish:
(homeassistant) homeassistant@iot:~$ hbmqtt_pub --url mqtt://<IP_ADDRESS> -t "auto/sensor1/temperature" -m "25.0" -q 1
[2018-09-28 20:53:24,956] :: INFO - hbmqtt_pub/2675-iot.mcplayman.de Connecting to broker
[2018-09-28 20:53:24,967] :: INFO - Exited state new
[2018-09-28 20:53:24,967] :: INFO - Entered state connected
[2018-09-28 20:53:24,967] :: INFO - hbmqtt_pub/2675-iot.mcplayman.de Publishing to 'auto/sensor1/temperature'
[2018-09-28 20:53:24,972] :: INFO - Exited state connected
[2018-09-28 20:53:24,972] :: INFO - Entered state disconnected
[2018-09-28 20:53:24,972] :: INFO - hbmqtt_pub/2675-iot.mcplayman.de Disconnected from broker

creates this error in home assistant:
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
    result = coro.send(None)
  File "/home/homeassistant/lib/python3.5/site-packages/hbmqtt/mqtt/packet.py", line 104, in from_stream
    byte1 = yield from read_or_raise(reader, 1)
  File "/home/homeassistant/lib/python3.5/site-packages/hbmqtt/codecs.py", line 52, in read_or_raise
    data = yield from reader.read(n)
  File "/home/homeassistant/lib/python3.5/site-packages/hbmqtt/adapters.py", line 146, in read
    data = yield from self._reader.readexactly(n)
  File "/usr/lib/python3.5/asyncio/streams.py", line 666, in readexactly
    raise IncompleteReadError(incomplete, n)
asyncio.streams.IncompleteReadError: 0 bytes read on a total of 1 expected bytes

While using my ESP8266 MQTT clients or the Hassio webinterface this error is not thrown, but the values for the sensors are not updated anyway.
Manually downgrading hbmqtt to 0.9.2 fixes everything.

0.79.3 is still exhibiting this behavior when connecting without username/password from an ESP8266 client running Arduino-MQTT.  Downgrading hbmqtt to 0.9.2 resolves the issue (until hass restarts).

I can also confirm the behavior that this only is a problem with unauthenticated connections. @fabaff I think the reason your test worked is because you're using an unauthenticated connection.  With a bone-stock hass venv installation on ubuntu 18.04 with no config changes outside of enabling MQTT, I can toggle this behavior by enabling or disabling MQTT auth.

I have the same issue. None of my mqtt connections (even esphomelib) works. And I now basically have no functionality working at all.

Is this still an issue you are experiencing? Can you please try upgrading to the latest version of Home Assistant (0.90) and report back if this is still a problem? Thanks!

Not sure if it helps, but I am still getting the same error on 90.2...
[hbmqtt.mqtt.protocol.handler] BrokerProtocolHandler Unhandled exception in reader coro: IncompleteReadError('0 bytes read on a total of 1 expected bytes')

I am having what seems the same issue for several versions now, but now in 0.92.1 ha will not even start if I enable mqtt.
Here is my simple config.. hassio works when I comment this 2 lines, but not with them( can still access log via samba and it is full of errors, but no frontend)
mqtt:
password: !secret http_pwd
Tks in advance.

Yes this problem starts to be annoying when it is happening every 5 seconds.

No stale


本地如何添加其他模型

Describe your problem
下载在本地运行后，假如想使用在本地跑的ollma，或者在云服务器上运行的模型。我需要修改哪些代码呢？因为云上的接口有一些额外的鉴权字段填入来访问对应的api，

We intend to create an international community, so we encourage using English for questions and answers.
For local deployment LLM, do you read the document?  https://ragflow.io/docs/dev/deploy_local_llm
For LLM SaaS, you may find lots of LLM SaaS have already been supported. For not-supported LLM SaaS, you can check this PR which is going to integrates Baichuan into RAGFlow.


cannot get it do anything :)

Hi there,
I installed it, followed instructions and so on. There's no apparent changes in etherpad's behavior.
Do I need to set anything else up in settings.json? I don't want a full fledged auth/oauth mechanism, and this seems like the most sensible thing to do: present a password form - if correct set the headers and load etherpad.
Thanks

Is your reverse proxy setting the header?  You need something in between etherpad and your browser here..  Nginx/apache/Varnish et al..

Yes, nginx is between my browser and etherpad. I tried with both the header set and without it.
// from intranetwork machine, through nginx still:
Nov  7 20:32:52 etherpad node[19142]: #033[31m[2020-11-07 20:32:52.493] [ERROR] console - #033[39m{ inspect: [Function: inspect] }
Nov  7 20:32:52 etherpad node[19142]: #033[32m[2020-11-07 20:32:52.558] [INFO] Minify - #033[39mCompress CSS file css/pad.css.
Nov  7 20:32:52 etherpad node[19142]: #033[32m[2020-11-07 20:32:52.643] [INFO] Minify - #033[39mCompress CSS file skins/colibris/pad.css.
Nov  7 20:32:52 etherpad node[19142]: #033[32m[2020-11-07 20:32:52.816] [INFO] Minify - #033[39mCompress CSS file ../../node_modules/ep_table_of_contents/static/css/toc.css.
Nov  7 20:32:52 etherpad node[19142]: #033[32m[2020-11-07 20:32:52.827] [INFO] Minify - #033[39mCompress CSS file ../../node_modules/ep_comments_page/static/css/main.css.
Nov  7 20:32:52 etherpad node[19142]: #033[32m[2020-11-07 20:32:52.837] [INFO] Minify - #033[39mCompress CSS file ../../node_modules/ep_comments_page/static/css/comment.css.
Nov  7 20:32:53 etherpad node[19142]: #033[32m[2020-11-07 20:32:53.356] [INFO] access - #033[39m[ENTER] Pad "doit": Client tINasB0hOOT-Lw72AAAJ with IP "<IP_ADDRESS>" entered the pad
Nov  7 20:32:53 etherpad node[19142]: #033[32m[2020-11-07 20:32:53.488] [INFO] Minify - #033[39mCompress CSS file ../../node_modules/ep_headings2/static/css/editor.css.
Nov  7 20:32:53 etherpad node[19142]: #033[32m[2020-11-07 20:32:53.539] [INFO] Minify - #033[39mCompress CSS file ../../node_modules/ep_comments_page/static/css/commentIcon.css.
Nov  7 20:33:13 etherpad node[19142]: #033[32m[2020-11-07 20:33:13.330] [INFO] access - #033[39m[LEAVE] Pad "doit": Author "a.ZhmX4U9byjD9pXy2" on client tINasB0hOOT-Lw72AAAJ with IP "<IP_ADDRESS>" left the pad
Nov  7 20:33:18 etherpad node[19142]: #033[31m[2020-11-07 20:33:18.349] [ERROR] console - #033[39m{ inspect: [Function: inspect] }
// from a private mode iOS device on the mobile network not local wifi:
Nov  7 20:33:22 etherpad node[19142]: #033[32m[2020-11-07 20:33:22.208] [INFO] access - #033[39m[ENTER] Pad "doit": Client OCZF5iEJq2UUSY0vAAAL with IP "<IP_ADDRESS>" entered the pad

No mention of the existence of the header or absence thereof, no "authenticate:" log entries. The client did not inherit the name given by proxy_set_header x-authenticated-user "headerme";

Update: the only time this plugin pops up in logs is when I access /admin which means etherpad needs to be ran with "requireAuthentication": true. Not very obvious to a newcomer.
NB: it overrides the /admin login prompt also, aka your admin login will no longer work once you enable this plugin. You'll have to handle admin logins externally as well.


[Bug] Can't use JsonPath with Backend Json Parser

Describe the bug
Can't use JsonPath with Backend Json Parser, get error message:
root object doesn't exist in the response. Root selector:$.*
Steps to reproduce
Set root node to $.*
Version Details:

Grafana version :9.1.5
Plugin version : 1.0.0

Backend parser currently uses selectors specified in https://github.com/tidwall/gjson

I changed JSONPath selector to GJson's and it worked. And this behavior is not mentioned in the docs, that's why I use JSONPath. Thank you so much for your great work.


Use Hyper instead of Express

The HTTP server should use purescript-hyper instead of purescript-express. It's the new hotness.

Happy to help if there's anything! :)

You're welcome to take a stab at it if you want. I won't be able to get to this for a while.
src/Server.purs would need to be rewritten, along with some other alternative to using webpack's express middleware in webpack.config.client.js
It shouldn't be too hard... all the HTTP server is used for is to render the app and serve some static assets. Hot-reloading can make things tricky.

The newest release uses Hyper and works with PureScript 0.11


Missing readme

Without a readme is difficult to know what are you doing, how are you doing it and how to use it

You are just right, thanks to remember it


Fixes to Correct Lost Functionality

Please review these fixes.
These correct functionality for:

Resizing the view canvas when the window size changes
Resting the viewer camera upon hitting the HOT key

Perfect ! tried out both, all fixed 👍


Add COMPONENTS_NAMESPACE as an environment variable and helm value

Description
Use the {{.Values.global.namespaceDefault.name}} in the deployment of the component operator (so that it watches the appropriate components namespace)

COMPONENT_NAMESPACE was already defined - closing issue


Make public discourse analysis generalisable

Test the functions in pd_analysis_utils  are usable for any input data that has:

timestamp
unique identifier
text content

Make functions generalisable if they are not already.
Examples of usage can be found here.
Test with Guardian and Hansard data.
Guardian data will need API setup.
Hansard test data can be found here.

The pd_analysis_utils functions appear generalisable but there is data loading that is specific to guardian data.
We could therefore separate the processing functions from the data loading.
The functions currently use year so this could updated to use timestamp and give an option to group the data monthly/yearly.


Is it possible to support tabs

Many thanks for the fantastic project.
Is it possible to support creating Tabs?

Hello @ascitegong
I'm afraid this repo can not suppor tabs, but if you want to create tabs for TabPane (or NoteBook) you can easily insert them with the code generated using this tool.
Small example:
class Master(tk.Frame):

    def __init__(self, parent, controller, *args, **kwargs):
        tk.Frame.__init__(self, parent, background='#FFFFFF')

        self.controller = controller
        self.pageTwoFrames = []

        self.notebook = ttk.Notebook(self, *args, **kwargs)
        self.notebook.place(
            x=0.0,
            y=60.0,
            width=1024.0,
            height=660.0
        )

        self.canvas = Canvas(
            self,
            bg="#FFFFFF",
            height=55,
            width=1024,
            bd=0,
            highlightthickness=0,
            relief="ridge"
        )
        # You can call this function outside init of the class
        self.addFrame(PaneForNotebook, 'Example - 0 ')

    def addFrame(self, frameType, name: str):
        self.aux = frameType(self.notebook, self.controller, self)
        self.pageTwoFrames.append(self.aux)
        self.notebook.add(self.aux, text=name, padding=5)
        self.notebook.place(
            x=0.0,
            y=60.0,
            width=1024.0,
            height=699.0
        )
        self.notebook.select(self.aux)

class PaneForNotebook(tk.Frame):

    def __init__(self, parent, controller, classParent):
        tk.Frame.__init__(self, parent)

        self.controller = controller
        self.parent = parent
        self.classParent = classParent

        self.canvas = Canvas(
            self,
            bg="#FFFFFF",
            height=650,
            width=1024,
            bd=0,
            highlightthickness=0,
            relief="ridge"
        )

class AnotherPaneForNotebook(tk.Frame):
    def __init__(self, parent, controller):
        tk.Frame.__init__(self, parent)
        # Your code below

Any extra help ask for it,
HackingAll

Thanks @HackingAllYT for the help. I'll close this issue @ascitegong


Add stream_index as an option to VideoDecoder

Adds stream_index as an option to VideoDecoder. Example usage:
decoder = VideoDecoder("myfile.mp4", stream_index=2)

While this is a modest change in the interface, it required:

Adding the concept of streams to our test file generation.
Adding new test files for the new stream.
Adding the concept of streams to our testing utils.
Enhancing some existing tests to parameterize on the stream index.

I suggest reviewing the changes to VideoDecoder first. Everything else is a consequence of that.

@NicolasHug, point taken about the testing framework being frameworky. My goal here is to make something that models the parts of video formats that we care about so that we can declaratively state such things when defining a new kind of test video. Basically, our testing logic is going to be a very simple model of the underlying FFmpeg file formats.
In general, adding a new fundamental capability in our decoder will probably require changing some testing logic. For example, I anticipate having to make some more changes when we add audio decoding. This tendency will level-out as our public capabilities match the underlying capabilities in the C++ layer. This current change is the most disruptive change I can think of, as having to support multiple streams is far-reaching. Most future changes should be less involved.
In general, when adding a new media file for testing, we will probably not require changing testing logic. We'll probably be able to just add a new declaration. I'm anticipating much more of adding new test files in the future, and much less of new fundamental capabilities. That is, I want it to be easy for us to add a new test file and state the metadata we need for tests in a declarative manner.


New version: Google.Chrome version 127.0.6533.73

Created by 🥟 Dumplings in workflow run #6812.

Log
Updated: 126.0.6478.183 → 127.0.6533.73
Submitting WinGet manifests
Creating manifests
Uploading manifests and making commits
The manifests for the last version 126.0.6478.183 will be removed. Reason: No installer URL is changed compared with the last state while the version is updated
Creating a pull request

Microsoft Reviewers: Open in CodeFlow

@ImJoakim it doesn't seem to be merging?

https://github.com/microsoft/winget-pkgs/issues/142854


Move ResponseCaching pubternal types to internal

Addresses ResponseCache portions of https://github.com/aspnet/AspNetCore/issues/6975. This is a breaking change due to the constructor change of the ResponseCachingMiddleware.
Tested locally with the analyzer to ensure all response caching errors are resolved.

Oops need to update generated code and breaking changes.

@aspnet-hello triage https://dev.azure.com/dnceng/public/_build/results?buildId=156384&view=logs&jobId=1bca1137-cedc-5e44-af9b-a27ff406bb70

This comment was made automatically. If there is a problem contact ryanbrandenburg.
I've triaged the above build. I've created/commented on the following issue(s)
https://github.com/aspnet/AspNetCore-Internal/issues/2266
https://github.com/aspnet/AspNetCore-Internal/issues/2263

Don't forget an announcement :).

Announcement: https://github.com/aspnet/Announcements/issues/354


[WIP] feat(kv): kv plugin stabilization

Reason for This PR
closes #640
Description of Changes

Update boltdb, memory, memcached, redis storages according new Storage interface
Update tests

License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.
PR Checklist
[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

[x] All commits in this PR are signed (git commit -s).
[x] The reason for this PR is clearly provided (issue no. or explanation).
[x] The description of changes is clear and encompassing.
[x] Any required documentation changes (code and docs) are included in this PR.
[x] Any user-facing changes are mentioned in CHANGELOG.md.
[x] All added/changed functionality is tested.


can't edit css in devtools(!)

because of this chrome issue, the generated css cannot be edited in chrome devtools, and it doesn't look like that'll get fixed any time soon.
not all hope is lost though, we can simply reconstruct the css like aphrodite does it. must also investigate batching with react's loop, preventing aphrodite's async problem.

thankfully done! with that though... we don't use the CSSStyleSheet api anymore? LOL


I install 'how' by pip3 in CentOS7. But the 'command not found: how' is promoted.

请检查你的PATH变量，确保包括了~/.local/bin（至少我的包都被安装到了这里）。export PATH=$PATH:~/.local/bin


Feat: Translate whole messages_zh_CN.properties

Description
Hi, i have translated the whole 'messages_zh_CN.properties' file and made a little change to some description.
Closes #(issue_number)
Checklist:

[x] I have read the Contribution Guidelines
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings

Contributor License Agreement
By submitting this pull request, I acknowledge and agree that my contributions will be included in Stirling-PDF and that they can be relicensed in the future under the MPL 2.0 (Mozilla Public License Version 2.0) license.
(This does not change the general open-source nature of Stirling-PDF, simply moving from one license to another license)

Had a new one, see https://github.com/Stirling-Tools/Stirling-PDF/pull/987


Question: What is the purpose of switching height calc mode back to default on resetIFrame

We've seen issues with terrible flicker and resize cycles when the height calc mode is set to 'max'.
It seems to be caused by this line in the contentWindow resetIFrame method.
https://github.com/davidjbradshaw/iframe-resizer/blob/master/src/iframeResizer.contentWindow.js#L957
It temporarily sets the height calc method back to 'bodyOffset' which seems to cause a different height value to be calculated (understandably) but then this then results in the parent resizing the iframe.
We see this in response to all kinds of events, e.g. 'Mouse Down', 'Transition End' etc when the size of the page has not actually changed.

I re-read all your readme again - and I suppose the issue we are seeing is just the flicker issue with the 'max' height calculation method which is intended to enable downsizing.

Yep

@davidjbradshaw hey! I was curious what this method is for? Why is it alternating between the default + set calc method?

Thanks @davidjbradshaw  for this wonderful library.
The alternating calculation method caused wrong sizing in our product. We had to fork and change this behavior in order for the library to work correctly for us.

Any context on the rationale of reseting the calculation method each time will be helpful here.

The reason for this is that in some browsers, certain height calculation methods only work in an upwards direction, so you end up having to set height to zero, calc the new size, and then size it up again for it to work reliably.
My advice is to use taggedElement if the default method doesn't work for you.
@lidermanrony you can use custom sizing methods without having to fork the library.
https://github.com/davidjbradshaw/iframe-resizer/blob/master/docs/iframed_page/options.md#heightcalculationmethod--widthcalculationmethod

@davidjbradshaw thanks for the insanely prompt response!
Is there a list of which methods only work in an upwards direction? We were looking to use the "bodyScroll" method as it works best for us - is this prone to the reliability issue?
We used the set height calculation method to set  "bodyScroll" but the alternating of the "bodyOffset" & "bodyScroll" seemed to give us some weird choppy scrolling issues sadly.

The ones marked with a *, which is then explained in the notes below. ;)

Notes:
If the default option doesn't work then the best solutions is to use either taggedElement, or lowestElement. Alternatively it is possible to add your own custom sizing method directly inside the iFrame, see the iFrame Page Options section for more details.
† The lowestElement option is the most reliable way of determining the page height. However, it does have a performance impact, as it requires checking the position of every element on the page. The taggedElement option provides much greater performance by limiting the number of elements that need their position checked.

These methods can cause screen flicker in some browsers.

I wrote this in 2013, memory is a bit hazy on the issues. These methods where for IE6, as it's too slow for anything else. It might be that we don't need to back scroll these days, but I don't have access to enough old browsers to test it on.
These days I recommend you use lowestElement or taggedElement. I expect I should just make a version 5 of this library that removes more of the old IE code.


onMouseEnter is triggered by child elements

Html.Events.onMouseEnter should only activate when mousing over the target element, not its children, like in this example: https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_onmousemove_over_enter. However, in Elm it activates on both:
https://ellie-app.com/LVqfxWnTjxa1/0
module Main exposing (..)

import Html
import Html.Attributes as Att
import Html.Events as Events

type alias Model =
    { bottom : Bool
    }

init =
    Model False

type Msg
    = Enter

update msg model =
    case msg of
        Enter ->
            { model | bottom = not model.bottom }

(=>) =
    (,)

view model =
    Html.div
        [ Att.style
            [ "position" => "absolute"
            , "width" => "100px"
            , "height" => "100px"
            , if model.bottom then
                "background-color" => "blue"
              else
                "background-color" => "red"
            ]
        , Events.onMouseEnter Enter
        ]
        [ Html.div
            [ Att.style
                [ "position" => "absolute"
                , "width" => "50px"
                , "height" => "50px"
                , "top" => "75px"
                , "left" => "75px"
                , "background-color" => "yellow"
                , "opacity" => "0.7"
                ]
            ]
            []
        ]

main =
    Html.beginnerProgram
        { model = init
        , update = update
        , view = view
        }

Browser: chromium version 57.0.2987.110 (64-bit), firefox 52.0.1 (64-bit)
OS: Manjaro linux, kernel version 4.4.55-1

In the w3scools example you linked to, replace this …

onmouseenter:
 Mouse over me!

… with this …

onmouseenter:
 Mouse over me!

… and you'll see that your Ellie example and the w3schools example work the same. Elm is doing nothing wrong here.

Elm is just passing the information to JS. onmouseenter, onmouseover, etc. all work funny, but that's part of the the DOM, not part of Elm.


Feat/merge node

Now it is renamed to coalesce node, impleted the coalesce node backend and frontend

[!IMPORTANT]
Introduce CoalesceNode to replace MergeNode, updating backend and frontend components to handle multiple inputs and output the first non-null value.

Behavior:

Introduce CoalesceNode to replace MergeNode, outputs first non-null value from multiple inputs.
Backend logic in coalesce.py, handles multiple inputs and outputs first non-null value.
workflow_executor.py updated to handle CoalesceNode, skips early failure for None inputs.

Models:

CoalesceNode added to node_types.py.

Frontend:

Replace MergeNode with CoalesceNode in FlowCanvas.tsx and CoalesceNode.tsx.
Update NodeSidebar.tsx to handle CoalesceNode configuration.
Adjust flowSlice.ts to manage CoalesceNode state, including schema rebuilding logic.

Misc:

Update .env.example to reflect new repository name.
Minor script update in test-release.sh for Docker compose command.

This description was created by  for 490c2d104cbae79d0c763317f881820e263a10d0. It will automatically update as commits are pushed.

@ellipsis review this.

LGTM!


Document metaclasses and static methods

Thought I'd have a go at this which is currently marked as a TODO.

The wording about the fact that "class is strange/unusual" is bad. Instead the documentation should extract: https://github.com/wren-lang/wren/blob/c2a75f1eaf9b1ba1245d7533a723360863fb012d/src/vm/wren_core.c#L1276-L1296
in some form, and this should be referenced instead, to justify the behavior.

Well, 'Class' is an unusual class in that it has no metaclass (the only one that doesn't) and  I think people will regard it as  strange that it's an instance of itself - a bit reminiscent of the Russell paradox.
This isn't intended as a criticism as I can understand why it's been done this way and object hierarchies of any programming language tend to have a certain amount of strangeness.
Personally, I'm not in favor of including the object hierarchy diagram in what is intended to be simple, readable documentation and I don't think it highlights the strangeness of the 'Class' class very well in any case. The examples I've chosen hopefully do that.

Well I think, the diagram should belong to the documentation, for advanced explanations of how the object model is implemented. Referring it from that change would seems logical, and would would allow some "not-personal" comments like:
System.print(Class is Class) // true, look here for details

Well, if we were to include a link to the diagram in the Class docs, then the best place to do it would be in the 'Inheritance' section which needs looking at anyway as it doesn't integrate too well with the 'Super' section at present.
I'm still not keen on referencing it in the 'Metaclasses' section (I can't include a clickable link to it in a code comment anyway) as I don't think the last two examples are easy to understand without a written explanation.

OK, I've changed the 'Metaclasses' section so that it no longer refers to 'Class' as being unusual or strange.

I've added some wording to the 'Static methods' sub-section to make it clear that static getters, setters and operators are supported and that, whilst this can be used in a static method,  it refers to the class object itself rather than an instance of it.

Reading through the whole lot again, I noticed that I'd missed out a word in the 'static methods' section. Fixed now.


Add config option for minimum local representative weight

Default 1000 Nano
Large services can set higher values to limit votes CPU load, while singe users willing to have small working representative can set it lower

The purpose of this patch is so node operators can choose a weight amount which much be reached for an account before the node will spend effort sending out votes.
LGTM

Tests fail:
[  FAILED  ] node.fork_publish
[  FAILED  ] node.rep_self_vote

@rkeene fixed in https://github.com/nanocurrency/raiblocks/pull/1281

Oh I see, I thought this was targeting master


Sending mails from alias fails after upgrading to version 0.10.0

Behaviour
After upgrading to 0.10.0 recently I noticed sending mails now causes an error claiming SPF/DMARC validation to have failed.
Attempting to send a mail results in a message like the following being generated.

When checking rspamd for more details, it looks to me everything is as it should be.

Expected behaviour

Mails are sent as they were in version 0.9.0 and earlier.

Actual behaviour

Mails are not sent despite passing required checks as outlined above.

Assumption
I have noticed the configuration file /etc/rspamd/local.d/milter_headers.conf to have the following content:
use = ["authentication-results", "remove-headers", "spam-header"];

routines {
  remove-headers {
    headers {
      "X-Spam" = 0;
      "X-Spamd-Bar" = 0;
      "X-Spam-Level" = 0;
      "X-Spam-Status" = 0;
      "X-Spam-Flag" = 0;
    }
  }
  authentication-results {
    header = "X-AnonAddy-Authentication-Results";
    remove = 0;
  }
  spam-header {
    header = "X-AnonAddy-Spam";
    value = "Yes";
    remove = 0;
  }
}

This is not aligned with the required changes listed in the 0.10.0 release notes suggesting the following:
use = ["authentication-results", "remove-headers", "spam-header", "add_dmarc_allow_header"];

routines {
  remove-headers {
    headers {
      "X-Spam" = 0;
      "X-Spamd-Bar" = 0;
      "X-Spam-Level" = 0;
      "X-Spam-Status" = 0;
      "X-Spam-Flag" = 0;
    }
  }
  authentication-results {
    header = "X-AnonAddy-Authentication-Results";
    remove = 0;
  }
  spam-header {
    header = "X-AnonAddy-Spam";
    value = "Yes";
    remove = 0;
  }
}

custom {
  add_dmarc_allow_header = <<EOD
return function(task, common_meta)
  if task:has_symbol('DMARC_POLICY_ALLOW') then
    return nil,
    {['X-AnonAddy-Dmarc-Allow'] = 'Yes'},
    {['X-AnonAddy-Dmarc-Allow'] = 0},
    {}
  end

  return nil,
  {},
  {['X-AnonAddy-Dmarc-Allow'] = 0},
  {}
end
EOD;
}

As noted there, the mail provider used here seemingly does not enforce its (perfectly valid) DMARC policy, probably causing the issue in the process.
Suggestion
Apply the changes suggested in the release notes.
If this is indeed intended to happen, it would be great to have information about how to configure this behaviour in order to allow such providers to be used regardless.
Despite being a potential spoofing risk, the sheer amount of people using one of the providers affected makes the viability of enforcing a certain policy questionable at this point.

Edit: When manually patching in an updated version of the filter rules into the container the mail was sent fine just now.

I've added the required Rspamd milter_headers.conf changes now - https://github.com/anonaddy/docker/blob/master/rootfs/etc/cont-init.d/14-config-rspamd.sh#L133

Oh I missed that one from the release notes!


No tools_call in message error on ChatVertexAI

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain.js documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain.js rather than my code.
[X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code
`
const calculatorSchema = z.object({
      operation: z
        .enum(['add', 'subtract', 'multiply', 'divide'])
        .describe('The type of operation to execute'),
      number1: z.number().describe('The first number to operate on.'),
      number2: z.number().describe('The second number to operate on.'),
    });

    const model = new ChatVertexAI({
      temperature: 0.7,
      model: 'gemini-1.0-pro',
    }).withStructuredOutput(calculatorSchema);

    const response = await model.invoke('What is<PHONE_NUMBER> times 81623836?');
    console.log(response);`

Error Message and Stack Trace (if applicable)
Error: No tools_call in message [{"message":{"lc":1,"type":"constructor","id":["langchain_core","messages","AIMessageChunk"],"kwargs":{"content":"","additional_kwargs":{},"tool_call_chunks":[],"tool_calls":[],"invalid_tool_calls":[],"response_metadata":{"usage_metadata":{},"safety_ratings":[{"category":"HARM_CATEGORY_HATE_SPEECH","probability":"NEGLIGIBLE","probability_score":0.12973313,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.09912086},{"category":"HARM_CATEGORY_DANGEROUS_CONTENT","probability":"NEGLIGIBLE","probability_score":0.22592856,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.13591877},{"category":"HARM_CATEGORY_HARASSMENT","probability":"NEGLIGIBLE","probability_score":0.16545822,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.08632348},{"category":"HARM_CATEGORY_SEXUALLY_EXPLICIT","probability":"NEGLIGIBLE","probability_score":0.08299415,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.05155819}]}}},"text":""}]
    at JsonOutputToolsParser.parseResult (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@langchain/core/dist/output_parsers/openai_tools/json_output_tools_parsers.cjs:110:19)
    at JsonOutputKeyToolsParser.parseResult (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@langchain/core/dist/output_parsers/openai_tools/json_output_tools_parsers.cjs:215:50)
    at JsonOutputKeyToolsParser._callWithConfig (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@langchain/core/dist/output_parsers/base.cjs:45:72)
    at JsonOutputKeyToolsParser._callWithConfig (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@langchain/core/dist/runnables/base.cjs:208:33)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at RunnableSequence.invoke (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@langchain/core/dist/runnables/base.cjs:1075:27)
    at OpenAiService.langChain (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/src/open-ai/open-ai.service.ts:146:22)
    at FoliosService.langChain (/Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/src/folios/folios.service.ts:181:22)
    at /Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@nestjs/core/router/router-execution-context.js:46:28
    at /Users/talhafayyaz/Documents/workArea/soraUnion/folio/folio-backend/node_modules/@nestjs/core/router/router-proxy.js:9:17

Description
I am trying to integrate ChatVertexAI with withStructuredOutput.
This works fine without withStructuredOutput.
System Info
<EMAIL_ADDRESS>| MIT | deps: 16 | versions: 271
Typescript bindings for langchain
https://github.com/langchain-ai/langchainjs/tree/main/langchain/

keywords: llm, ai, gpt3, chain, prompt, prompt engineering, chatgpt, machine learning, ml, openai, embeddings, vectorstores

dist
.tarball: https://registry.npmjs.org/langchain/-/langchain-0.2.0.tgz
.shasum: 555d84538962720cd7223f6c3ca4bd060978ebf3
.integrity: sha512-8c7Dg9OIPk4lFIQGyfOytXbUGLLSsxs9MV53cLODspkOGzaUpwy5FGBie30SrOxIEFJo+FDaJgpDAFO3Xi4NMw==
.unpackedSize: 3.4 MB

dependencies:
@langchain/core: ~0.2.0          binary-extensions: ^2.2.0        jsonpointer: ^5.0.1              ml-distance: ^4.0.0              uuid: ^9.0.0                     zod: ^3.22.4
@langchain/openai: ~0.0.28       js-tiktoken: ^1.0.12             langchainhub: ~0.0.8             openapi-types: ^12.1.3           yaml: ^2.2.1
@langchain/textsplitters: ~0.0.0 js-yaml: ^4.1.0                  langsmith: ~0.1.7                p-retry: 4                       zod-to-json-schema: ^3.22.3

maintainers:
- nfcampos<EMAIL_ADDRESS>- jacoblee93<EMAIL_ADDRESS>- andrewnguonly<EMAIL_ADDRESS>- davidduong<EMAIL_ADDRESS>- hwchase17<EMAIL_ADDRESS>- basproul<EMAIL_ADDRESS>
dist-tags:
latest: 0.2.0  next: 0.2.0

published 2 days ago by basproul<EMAIL_ADDRESS>

This seems odd. But looking into it.
The system info dependencies list doesn't show any of the @langchain/google-* modules. Can you confirm which ones are installed and their versions?

@afirstenberg  sure

Same problem here. When running in verbose mode it looks like the response when using withStructuredInput is an empty string:
[llm/start] [1:llm:ChatGoogleStructuredOutput] Entering LLM run with input: {
  "messages": [
    [
      {
        "lc": 1,
        "type": "constructor",
        "id": [
          "langchain_core",
          "messages",
          "HumanMessage"
        ],
        "kwargs": {
          "content": "What is<PHONE_NUMBER> times 81623836?",
          "additional_kwargs": {},
          "response_metadata": {}
        }
      }
    ]
  ]
}
[llm/end] [1:llm:ChatGoogleStructuredOutput] [1.39s] Exiting LLM run with output: {
  "generations": [
    [
      {
        "text": "",
        "message": {
          "lc": 1,
          "type": "constructor",
          "id": [
            "langchain_core",
            "messages",
            "AIMessageChunk"
          ],
          "kwargs": {
            "content": "",
            "additional_kwargs": {},
            "tool_call_chunks": [],
            "tool_calls": [],
            "invalid_tool_calls": [],
            "response_metadata": {
              "usage_metadata": {},
              "safety_ratings": [
                {
                  "category": "HARM_CATEGORY_HATE_SPEECH",
                  "probability": "NEGLIGIBLE",
                  "probability_score": 0.12973313,
                  "severity": "HARM_SEVERITY_NEGLIGIBLE",
                  "severity_score": 0.09912086
                },
                {
                  "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
                  "probability": "NEGLIGIBLE",
                  "probability_score": 0.22592856,
                  "severity": "HARM_SEVERITY_NEGLIGIBLE",
                  "severity_score": 0.13591877
                },
                {
                  "category": "HARM_CATEGORY_HARASSMENT",
                  "probability": "NEGLIGIBLE",
                  "probability_score": 0.16545822,
                  "severity": "HARM_SEVERITY_NEGLIGIBLE",
                  "severity_score": 0.08632348
                },
                {
                  "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
                  "probability": "NEGLIGIBLE",
                  "probability_score": 0.08299415,
                  "severity": "HARM_SEVERITY_NEGLIGIBLE",
                  "severity_score": 0.05155819
                }
              ]
            }
          }
        }
      }
    ]
  ],
  "llmOutput": {
    "usage_metadata": {},
    "safety_ratings": [
      {
        "category": "HARM_CATEGORY_HATE_SPEECH",
        "probability": "NEGLIGIBLE",
        "probability_score": 0.12973313,
        "severity": "HARM_SEVERITY_NEGLIGIBLE",
        "severity_score": 0.09912086
      },
      {
        "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
        "probability": "NEGLIGIBLE",
        "probability_score": 0.22592856,
        "severity": "HARM_SEVERITY_NEGLIGIBLE",
        "severity_score": 0.13591877
      },
      {
        "category": "HARM_CATEGORY_HARASSMENT",
        "probability": "NEGLIGIBLE",
        "probability_score": 0.16545822,
        "severity": "HARM_SEVERITY_NEGLIGIBLE",
        "severity_score": 0.08632348
      },
      {
        "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
        "probability": "NEGLIGIBLE",
        "probability_score": 0.08299415,
        "severity": "HARM_SEVERITY_NEGLIGIBLE",
        "severity_score": 0.05155819
      }
    ]
  }
}

same issue here

Same issue here, same problem as well. I get the following error message:
 ⨯ Error: No tools_call in message [{"message":{"lc":1,"type":"constructor","id":["langchain_core","messages","AIMessageChunk"],"kwargs":{"content":"","additional_kwargs":{},"tool_call_chunks":[],"tool_calls":[],"invalid_tool_calls":[],"response_metadata":{"usage_metadata":{},"safety_ratings":[{"category":"HARM_CATEGORY_HATE_SPEECH","probability":"NEGLIGIBLE","probability_score":0.05738754,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.049681153},{"category":"HARM_CATEGORY_DANGEROUS_CONTENT","probability":"NEGLIGIBLE","probability_score":0.09877259,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.09301681},{"category":"HARM_CATEGORY_HARASSMENT","probability":"NEGLIGIBLE","probability_score":0.089136936,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.046378203},{"category":"HARM_CATEGORY_SEXUALLY_EXPLICIT","probability":"NEGLIGIBLE","probability_score":0.116965584,"severity":"HARM_SEVERITY_NEGLIGIBLE","severity_score":0.043528143}]}}},"text":""}]

While the name of the fix doesn't look like it should address it, #5571 should fix the issue. Thanks @talhaFayyazfolio for the test case, which made it much easier to verify.
If you can, check out the patch to see if it looks good to you before merged.

@afirstenberg thanks for this fix. It looks good to me .

Thank you so much @afirstenberg!

Fix is live in 0.0.17 of your @langchain/google-* package!

Tested with the new live version in 0.0.17. If I do not attach a file input, the withOutputParser works great! However, if I attach a file, I am getting an error when I try to invoke the function. Example code below:

const zodChatMessage = z.object({
	chatMessage: z.string().optional().describe("the chat message answer responding to the user's question"),
	chatCitation: z.string().optional().describe('1-3 key sentences from the text segment justifying the extracted chat message'),
	chatPage: z.number().optional().describe('the page number where this answer was extracted from')
});

const model = new ChatVertexAI({
	temperature: 0.7,
	model: 'gemini-1.5-pro',
}).withStructuredOutput(zodChatMessage);

const inputContent: MessageContent = [{ type: 'text', text: 'What is the powerhouse of the cell?' }];
inputContent.push({ type: 'image_url', image_url: `data:application/pdf;base64,${pdfFileString}` });
const input = [new HumanMessage({ content: inputContent })];

const response = await model.invoke(input);
console.log(response);

This looks to be the relevant error message:
errors: [
    {
      message: 'Unable to submit request because Function Calling is not supported with non-text input. Remove the function declarations or remove inline_data/file_data from contents. Learn more: https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/function-calling',
      domain: 'global',
      reason: 'badRequest'
    }
  ],

From the sound of it, the issue seems to be with VertexAI / Gemini itself. However, in my mind it would seem a little odd if this is the case - This seems like it would be something relatively important.
I was hoping we can confirm that this is expected behavior from the withStructuredOutputParser as well? It would be really nice if you could use the same chain with and without input files!

Will check it out - I wonder if it's not forcing the tool call. What if you prompt more strongly?

I can't duplicate the problem.
It looks like Vertex AI is ok with "text/csv", so the documentation seems to be wrong (big shock).
My test code:
    const zodChatMessage = z.object({
      chatMessage: z.string().optional().describe("the chat message answer responding to the user's question"),
      chatCitation: z.string().optional().describe('1-3 key sentences from the text segment justifying the extracted chat message'),
      chatPage: z.number().optional().describe('the page number where this answer was extracted from')
    });

    const model = new ChatVertexAI({
      temperature: 0.7,
      model: 'gemini-1.5-pro',
    }).withStructuredOutput(zodChatMessage);

    const filePath = "src/tests/data/structuredOutput.csv";
    const fileString = loadFile(filePath);

    const inputContent: MessageContent = [{ type: 'text', text: 'What is the price of a shrimp cocktail?' }];
    inputContent.push({ type: 'image_url', image_url: `data:text/csv;base64,${fileString}` });
    const input = [new HumanMessage({ content: inputContent })];

    const response = await model.invoke(input);
    console.log(response);

Gives a response:
{ chatMessage: 'The price of the Shrimp Cocktail is $13.50.' }

When I run the test using the raw JSON it gives me:
{
  "candidates": [
    {
      "content": {
        "role": "model",
        "parts": [
          {
            "text": "The price of the Shrimp Cocktail is $13.50. \n"
          },
          {
            "functionCall": {
              "name": "extract",
              "args": {
                "chatMessage": "The price of the Shrimp Cocktail is $13.50."
              }
            }
          }
        ]
      },
      "finishReason": "STOP",
      "safetyRatings": [
        {
          "category": "HARM_CATEGORY_HATE_SPEECH",
          "probability": "NEGLIGIBLE",
          "probabilityScore": 0.111627996,
          "severity": "HARM_SEVERITY_NEGLIGIBLE",
          "severityScore": 0.1362632
        },
        {
          "category": "HARM_CATEGORY_DANGEROUS_CONTENT",
          "probability": "NEGLIGIBLE",
          "probabilityScore": 0.34620965,
          "severity": "HARM_SEVERITY_NEGLIGIBLE",
          "severityScore": 0.1468197
        },
        {
          "category": "HARM_CATEGORY_HARASSMENT",
          "probability": "NEGLIGIBLE",
          "probabilityScore": 0.24526574,
          "severity": "HARM_SEVERITY_NEGLIGIBLE",
          "severityScore": 0.08787644
        },
        {
          "category": "HARM_CATEGORY_SEXUALLY_EXPLICIT",
          "probability": "NEGLIGIBLE",
          "probabilityScore": 0.17009404,
          "severity": "HARM_SEVERITY_NEGLIGIBLE",
          "severityScore": 0.07356305
        }
      ]
    }
  ],
  "usageMetadata": {
    "promptTokenCount": 421,
    "candidatesTokenCount": 33,
    "totalTokenCount": 454
  }
}

which seems correct.
The only thing I can guess about why my prompt is working and yours isn't is that by the time Gemini gets the tokens, it doesn't see a "file" anywhere. It just sees more tokens. So a prompt that asks about a "file" doesn't make any sense to it unless there is something that explicitly says "here is a file" or something.
The CSV file is a pretty straightforward CSV file that contains a menu item, description, and price.
The loadFile function you see there just loads the file and turns it into Base 64.

Okay I am using a different computer from the one last night, however it seems like the output is still quite inconsistent. When attaching a .csv, I will sometimes get the proper output structure, whereas other times it will not be correct (i.e. a string vs. a number), resulting in a error. For example:
 OutputParserException [Error]: Failed to parse. Text: "{
  "chatCitation": "The length of the lease, in months",
  "chatMessage": "63 months",
  "chatPage": null
}". Error: [{"code":"invalid_type","expected":"number","received":"null","path":["chatPage"],"message":"Expected number, received null"}]

It seems to like to put "null" as the response for optional inputs, however if you use zod's .nullable(), you will get an error. This is an issue with or without the file attachment.
Lastly, it looks like you can still result in a no tools_call in message occasionally if you play around with the input prompt (i.e. ask it something irrelevant to the attached document).

I think the only way to avoid any possibility of "no tools_call" is to add a "fallback" tool and to force it to reply with a tool using the ANY function calling mode (which we haven't implemented  support for yet - see https://github.com/langchain-ai/langchainjs/issues/5072).
Gemini ignoring the type seems odd, however. I haven't encountered that before.
But I'm not sure there is anything that LangChain.js can do differently aside from implementing #5072.


Decouple size from page zoom

Is your feature request related to a problem? Please describe.
I often have different zoom level on different tabs, according to which level makes the text on that page comfortable for me to read. Some times I zoom in a lot. Then it's quite jarring to open Tab Butler and having it huge on one tab and small on another. I'd like it to be consistent across all tabs.
Describe the solution you'd like
The zoom level on a tab should not influence the size of the butler. The size should rather be independent of anything else and possible to change in the settings.
Describe alternatives you've considered
The size could be linked to the size of the browsers chrome/interface, if possible.
Additional context
Using Firefox
Thanks!

Thanks for submitting this issue. Unfortunately, this might not be entirely possible as zoom settings depend greatly on the settings set by the browser and the website that we inject the Tab Butler modal into, and it is better not to mess with any of those. I will continue searching for a potential solution but for now, this won't be worked on.


Update licensing boilerplates

I am adding a shell script to crate-docs (see https://github.com/crate/crate-docs/pull/74)
@amotl has reviewed my PR. he left a comment about the licensing boilerplate (see https://github.com/crate/crate-docs/pull/74#discussion_r601176896) asking whether we should remove this paragraph:
# However, if you have executed another commercial license agreement with Crate
# these terms will supersede the license and you may use the software solely
# pursuant to the terms of the relevant commercial agreement.

my current position is the boilerplate should match the boilerplates in crate/crate. I believe that crate/crate sets the standard and other projects should follow that standard
I checked two files in crate/crate:

https://github.com/crate/crate/blob/master/app/src/main/java/io/crate/bootstrap/CrateDB.java has:
/*
 * Licensed to CRATE Technology GmbH ("Crate") under one or more contributor
 * license agreements.  See the NOTICE file distributed with this work for
 * additional information regarding copyright ownership.  Crate licenses
 * this file to you under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.  You may
 * obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the
 * License for the specific language governing permissions and limitations
 * under the License.
 *
 * However, if you have executed another commercial license agreement
 * with Crate these terms will supersede the license and you may use the
 * software solely pursuant to the terms of the relevant commercial agreement.
 */

https://github.com/crate/crate/blob/master/app/src/bin/crate.in.sh has no boilerplate

I have two questions:

do we still want to keep the last paragraph for CrateDB versions 4.5.x and above?

should we add boilerplate text to files that do not have one?

if the answer is yes to either of these, I would be happy to prepare a PR. I consider this a part of the project's documentation and the changes would be easy to apply

in case it helps: my point of reference is working in the Apache Incubator to prepare podlings for top-level graduation (including, for example, adding boilerplates). one of the ASF's rules is that all files should have a boilerplate (even small scripts, config files, HTML files, and so on) where possible
we are not the ASF and we do not have to follow their rules. however, in the past, and to the best of my knowledge, we have done our best to follow their licensing guidelines (whenever sensible)

@seut @mfussenegger can you help with either question? (see above)

I'd say the safe answer to both is yes, but I don't really feel qualified to answer the questions.

@mfussenegger who do we need to contact to get a definitive answer? do you know?

@seut do you know I should speak to to get a yes/no on this?

@norosa I will clarify the first question in detail, but as we already used it until now, lets keep it for now. We can change that anyhow later on.
On the 2nd, strong yes ;)

@norosa Discussed this and we agree that we want to keep it.

@seut would you like me to perform the addition of boilerplates to all files that are missing one? (asking because it will require me to touch code. which is fine by me. but you may want to take a different approach)

@norosa

would you like me to perform the addition of boilerplates to all files that are missing one?

Yes, isn't this what you asked on 2) ?

@seut on (2) I asked if "we" should do it. I didn't know whether you wanted an engineer to modify the source files. but I am happy to do it. thanks for clarifying!