It allows to pass empty string as metadata value

Hello! I tried to pass S3 prefix as metadata and in some cases, when prefix is empty it raises error. This commit fixes it. I didn't found anything about value can't be blank in tus spec, I guess it should be permitted.

@lysenkooo Thanks for the patch!
The reason why I required value to be nonempty was because I thought it was according to the tus specification, but now I read the Upload-Metadata definition again, and you're right, it only specifies that the key cannot be empty. Thank you for catching that!
Now we can also remove these conditionals as well 🎉


1369 bug incorrect applicant status behavior

Changes:

Fix bug where next application in list get the same status as application set to "Called and rejected" when index is updated. Made Dropdown component controllable by using value instead of initialValue.
Add section for showing applicants that has rejected the offer for position.

Is fukked, will fix


[FEATURE-REQUEST] Guardian integration

Describe the problem you're proposing to solve
I would like to integrate with guardian authentication
Describe the solution you'd like
I would like to provide a pipeline that the controllers use for authentication like
  pipeline :auth do
    plug MyApp.Auth.AuthAccessPipeline
    plug MyAppWeb.Context
 end
use Kaffy.Routes, scope: "/admin", pipe_through: [:browser, :auth

while having the controllers use this auth like
  import MyApp.Auth, only: [load_current_user: 2]
 plug(:load_current_user)

Describe alternatives you've considered
basic_auth on the browser with nginx

Would loading the resource in the pipeline solve this issue?

Will close this for now. Please let me know if you're still having issues with this.

So i do load that in the MyApp.Auth.AuthAccessPipeline class
defmodule MyApp.Auth.AuthAccessPipeline do
  @moduledoc false

  use Guardian.Plug.Pipeline, otp_app: :scotchy_api

  plug(Guardian.Plug.VerifySession, claims: %{"typ" => "access"})
  plug(Guardian.Plug.EnsureAuthenticated)
  plug(Guardian.Plug.LoadResource)
end

But i believe the issue is still in the controllers actually using the load_current_user method to read the session

Yes. This will actually load the user (or whatever resource you're using with guardian) from the session.
You'd be able to access it from conn.private I believe.
Something like conn.private[:guardian_default_resource] I think. You can IO.inspect(conn.private) to see the exact name guardian is using to store the resource.


Show docs on Dashboard

Pull Request Description
Closes: https://github.com/enso-org/cloud-v2/issues/1445
PR is more or less ready for feedback,CR, and QA.
Read before looking into:
Known issues:

[x] Need to adjust timings for the animations (they're a bit out of sync).
[x] After the latest rebase, the side panel might expand while clicking on the sidebar toggle.
[ ] Images no longer display. 🤦
[x] Need to restore the functionality around spotlighting a component

Demo:
https://github.com/user-attachments/assets/8cec9ec0-4753-482e-8637-f3857b4396a5

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[ ] All code follows the
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
[ ] Unit tests have been written where possible.

A though: wouldn't it look better if there wasn't any radius on the right side and the whole row / highlight was touching the bar?

Look at the icons (asst panel and docs) when I switch between project view and dashboard
https://github.com/user-attachments/assets/ea7aba8f-db1f-4216-8b19-076fc1988d8c

How hard would it be to hide tabs with unavailable content? It could also applies when project has no docs

Size and icons between project view bar and dashboard are different.

When I click on project which files request ends with 404 (that something to fix on backend) I need to close and open asset panel to be able to choose and see docs from another project

When I toggle asset panel can we preserve last selected tab? It feels more natural

Size and icons between project view bar and dashboard are different.

It's by design. We'll increase the size of the icons on project view with updating the icons (out of the scope of this PR)

@PabloBuchu your issues are addressed

@PabloBuchu the revalidation is fixed

This doesn't seem to work when using the local backend.
I've pushed an update to the new APIs after #11441. I haven't tested it because my cloud account isn't working today.

partial QA :white_check_mark:


ocis-bin: init at 5.0.0

Description of changes
Adds binary package for Owncloud Infinite Scale Stack. Fixes #230190.
There are currently issues building ocis for Nix independently, leaving us with options to fetch the prebuilt binary or the prebuilt container.
A rudimentary NixOS module is also included.

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/1016/112

why do you need an rc build? What happens to this package when ocis goes to release?

5.0.0 has some significant changes and deprecations (see release notes). Since the package is just starting out in nixpkgs, I just went with rc. There is still couple months till next NixOS release, so still plenty of time.
All that said, I wouldn't mind changing it to stable release if you think that would be safer call.

@MaxwellDupre updated to have 4.0.6 stable tag instead.

Feel free to add me as a maintainer.

@danth  thanks for review, addressed comments and added you as maintainer.

If 5.0 gets released before 24.05 freeze, we can update fairly easily, unstable is called that for good reason anyway. Stable is better in case there are more rcs.

Looks like 5.0 just got released :sweat_smile:
https://github.com/owncloud/ocis/releases/tag/v5.0.0

@danth nice catch, updated to 5.0.0.
@SomeoneSerge good point, addressed.

One question, since this is using the binary, and that appears to be under EULA, should the license be agpl3Only or should it be marked unfree?

It may be useful to add a comment for anyone who comes across this in the future and wonders why it's marked unfree.

A comment directly in the file would avoid the need to search through history to find it, but that's not a major issue.

Added a comment

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1555

@bhankas I think the license change should be squashed into the ocis-bin: init at 5.0.0 commit.
The nixos module should be added to nixos/modules/module-list.nix and referenced in nixos/doc/manual/release-notes/rl-2405.section.md under "New Services"

@bhankas I think the license change should be squashed into the ocis-bin: init at 5.0.0 commit.

Done.

The nixos module should be added to nixos/modules/module-list.nix and referenced in nixos/doc/manual/release-notes/rl-2405.section.md under "New Services"

Done and Done!

I  have no idea why manual building is failing. Its very likely to be something really dumb, but help appreciated

Running locally (with the ... fix) I am getting:
       Failed assertions:
       - Exactly one of users.users.ocis.isSystemUser and users.users.ocis.isNormalUser must be set.
       ```

Casey Link @.***> writes:

Running locally (with the ... fix) I am getting:
       Failed assertions:
       - Exactly one of users.users.ocis.isSystemUser and users.users.ocis.isNormalUser must be set.
       ```

Thanks! I set isSystemUser=true but doesn't appear to work. Doesn't
help the fact that my machine is slow and network is even slower and
unreliable to run nixpkgs-review.
Its a bit of work, but I am happy to keep fixing anything that you or
others may find, this is among my very first module PRs so having to fix
fair bit.

Hey, it worked! It was indeed dumb :) I was using old nested option link, just had to update it.
@danth , @Ramblurr thanks for putting up, feel free to take another look.

@Ramblurr thanks a ton for pointing to the tests, it was indeed super helpful in ironing out the kinks. I've added a test, but since this is unfree package it won't be run by CI nor hydra. It should still be valuable for future module maintenance.
@danth I've learned crapton of systemd-units and nixpkgs from your reviews, thanks for the pointers!
Anyway, I think we are good for next round. Hit me with your finest :)
P.S. I'll probably add config options for enabling/disabling every service in future, because right now we are running the so called fullstack server with every service supported by ocis. I think it is fine for now, because settings example gives all the values that are necessary, but further useability and/or customizability for distributed deployment will certainly help. That can wait though, but let me know what you think.

Awesome. I'll give it a spin tomorrow. For my use case the full stack mode is fine. It's really nice OCIS has that feature.

Awesome. I'll give it a spin tomorrow. For my use case the full stack mode is fine. It's really nice OCIS has that feature.

One problem with the fullstack mode is it starts 33 (!) services right now, that block 33 ports, and the user does not get any control over them. That needs to be addressed.
I need to up my Nix-game. There are so many services, and I'm sure new ones will get added over time, that manually adding config options for them all is going to be painful, not to mention maintenance and debugging.
I'd like to just make a list and generate all the systemd service configs for each of them, but again, my Nix-fu is pretty weak ATM. If you know any other module that does something (autogenerate systemd service config from some list), I'll be happy to work on it over coming weeks.

The basic structure could be something like
systemd.services = lib.genAttrs
  [ "service-one" "service-two" ]
  (name: {
    serviceConfig = { };
  });

Daniel Thwaites @.***> writes:

The basic structure could be something like
systemd.services = lib.genAttrs
  [ "service-one" "service-two" ]
  (name: {
    serviceConfig = { };
  });

Thanks, this will help me get started.
Just to reiterate, that will take time, and I'd prefer it to not hold
this PR back. If it is a blocker, I'd rather close the PR and come back
whenever I'm able to work out service segregation.

Personally I don't think that should be a blocker for this PR.

Thanks, then I'll wait for further review/approval.
On Thu, 28 Mar, 2024, 15:07 Daniel Thwaites, @.***>
wrote:

Personally I don't think that should be a blocker for this PR.
—
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/296679#issuecomment-2024774034,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFZBOUNDSN3NFUAXB7OA3E3Y2PJDTAVCNFSM6AAAAABE2JX6HKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRUG43TIMBTGQ
.
You are receiving this because you were assigned.Message ID:
@.***>

Casey Link @.***> writes:

@Ramblurr requested changes on this pull request.
Nice work @bhankas I think we are almost there.
I made a few comments to the PR.. but I also have some further suggestions. I
coded them up and pushed them to my nixpkgs ocis
branch

Thanks! I fixed the small ones quickly enough, but haven't yet checked
out your branch.

In particular the changes I'm suggesting:

In the nixos test file: use headless firefox to verify that logging in
actually works. This better verifies that ocis is actually running and working

I'm so amazed how fast and simple the nixos integration tests are.. it's really awesome

Yes! Always wondered why people went on about NixOS tests, but writing
one and actually witnessing it in action is quite something!

Adds a ocis-init.service to run ocis init, optionally with a
cfg.adminPasswordFile to set the admin password (otherwise it is randomly
generated and spit out into the journal)
Adds systemd hardening options to the systemd services
Fixes the other issues I mentioned in the PR review

After having to go through the service docs and actually getting the
bloody thing to start up has me unsure on ocis-init.service. We
want users to be configuring their ADMIN_PASSWORD declaratively and put
it in their config using something like sops-nix/agenix. Running an
imperative operation that creates a config, which can easily get
lost/moved/deleted in sea of other files (e.g. impermanence) is undesired,
especially for a service that is intended to not lose users' files,
that'd be ironic :)

Finally: I hope I'm not stepping on your toes or anything by suggesting such a
big change like this. Feel free to copy the changes into this PR, no need to
credit me.

No problem, always nice to have someone to work with than otherwise :)
I will probably be able to take a look at your branch later today, but the weekend
will probably be busy for me to make big changes. If you feel your
branch is further along, I don't mind closing this PR and going with
yours, no feelings hurt :)

I'm also happy to be added as a maintainer if you want.

Thanks, I've added you in maintainers.

My plan this week was to submit a nixos module for ocis, so it's nice we are
able to collaborate on it together.

Definitely. Let me know what you think.
--

Casey Link @.***> writes:

After having to go through the service docs and actually getting the bloody thing to start up has me unsure on ocis-init.service. We want users to be configuring their ADMIN_PASSWORD declaratively and put it in their config using something like sops-nix/agenix. Running an imperative operation that creates a config, which can easily get lost/moved/deleted in sea of other files (e.g. impermanence) is undesired, especially for a service that is intended to not lose users' files, that'd be ironic :)

Running the ocis init command (which is what the ocis-init.service does) is required regardless of if we provide an option to set the admin password. It generates a bunch of stuff in /var/lib/ocis/config (and other subdirs) needed for the system to start properly (see the getting started docs: https://owncloud.dev/ocis/getting-started/).

Pretty sure ocis init is not required. What is required is the
values of environment variables. We know that because the module test as
it is right now runs without ever invoking ocis init :)

We don't have to run this command, but then user intervention is required before they have a working ocis instance. If we don't run the command, then they would have to run it themselves.
There's plenty of examples in nixos/modules/* of similiar type services (just grep for "-init.service" or "init-.*.service"), so I think this is a well established convention.

Yes, but I'd rather the user be made aware of these than have them
hidden away. The list of envvars in module test are the bare minimum it
takes for the services to start. How about, instead of taking the
visibility of everything away, we set the envvars to null, and either
warn or better, error out if the service is enabled without also setting
these envvars?
Let me try to explain this better in next section:

I do understand your point about imperatively creating a config, but:

All the options that the user can specify with cfg.settings override whatever ocis init creates in the config file.. so one can still declaratively manage the config with nixos (win!)

Re sea-of-files/impermanence this is a good point, but the config is created inside the state dir, which has to be persisted anyways (other wise all the files go poof on the next reboot). And the created config is in the state dir, so there's no extra runtime path that you have to backup or worry about (like if it wrote something in /etc)

I think it is a much nicer user experience (and also in-line with other nixos modules) that with a config as simple as
services.ocis = {
    enable = true;
    settings = {
      OCIS_INSECURE = "true";
    };
};

... you get a working ocis instance.

Hmm.. This does look nice, but I'm not convinced. As an admin, I want to
be aware of security implications, have good secure defaults AND get to
decide my own risk factor.
Coming to earlier point, if we error out on null variables:

we tell user immediately, at the nixos-rebuild what they are
missing and what needs to be done. No need to go digging application
docs.

It promotes good defaults, by not setting insecure values without
explicit user intervention. We can also have the error docstring point
towards the envvars being included in environmentFile instead of
settings.

Preserves user agency in picking bad/insecure defaults. If I, as a
user want the passwords to be world readable nix store because I protect
it other ways, or that I know all code running on my machine is fully
vetted or that I just want to watch my system burn, the system should NOT
be making that decision for me.

Provide granularity. As extension of (3.), the user gets to decide
what secrets they want to clutch close to their chests and what they
don't care about for whatever reason.

In nutshell, secure by default + full user agency.

Nearly everything about nixos modules is hiding imperative actions and instead presenting a nice beautiful declarative interface, so IMO this is doing exactly that.

Disagree. I see nixos modules as 'handling' imperative actions, not
'hiding' them. I still tell the system what I want, system takes care of
'how'. Sounds pedantic, but please entertain me anyway.
For example, my concern with your earlier code snippet is that it tells
me things are insecure, but doesn't tell me why, or how much, or how to
make it secure. The default yaml created by ocis init for
fullstack config is big, and the OCIS_INSECURE option doesn't tell
user the breadth of choices that are being made for them.

As for the cfg.adminPasswordFile option itself: that option precisely allows the user to use sops/agenix, etc to declaratively specify their admin password (in fact i use sops-nix in my local testing).

I'm guessing this is part of your suggested changes (sorry, haven't been
able to check), but we already have environmentFile which serves the same
purpose. Please correct me if wrong.

Apologies if this came out rant-y, certainly wasn't intentional.
Payas Relekar @.***> writes:

Casey Link @.***> writes:

There's plenty of examples in nixos/modules/* of similiar type services
(just grep for "-init.service" or "init-.*.service"), so I think this is a
well established convention.

If you don't mind entertaining me for bit longer, I'm not convinced it
is a good convention, or that we don't have a better alternative for our
situation.

Yes, but I'd rather the user be made aware of these than have them
hidden away. The list of envvars in module test are the bare minimum it
takes for the services to start. How about, instead of taking the
visibility of everything away, we set the envvars to null, and either
warn or better, error out if the service is enabled without also setting
these envvars?

See services.garage where the user is forced to pick a package,
we can do something similar for envvars.

All the options that the user can specify with cfg.settings override
whatever ocis init creates in the config file.. so one can still
declaratively manage the config with nixos (win!)

Yes, but the user does not know what they need to override unless they
dig into documentation of every single service.

```
services.ocis = {
    enable = true;
    settings = {
      OCIS_INSECURE = "true";
    };
};

```

... you get a working ocis >

I gave this more thought. A no-frill config that brings everything up is
indeed nice, but I still want to be aware of the full picture and get agency via
NixOS module doc+options, and I don't want to /have to/ dig through
service docs to get started.
How about this?

We have envvars set to null and error out if they are not set

We provide a non-standard nixos module options:

services.ocis.auto-generate-secrets : generate passowrds and jwt_token etc
services.ocis.insecure : set TLS and *_INSECURE vars to "true"

The semantics of these options can be changed, including whether to have
separate options or combine them.
The idea is,

User knows what they are getting into. Module option docstring can
explain which command it runs, what output it generates and where to
find it.

User has to explicitly opt into choosing this, and the module can be
configured to make it exclusive with serviecs.ocis.settings. Again,
this choice is up for further discussion, but I think that promotes
good balance between secure defaults and user agency.

Just a scratch, perhaps we can explore this more?

Sorry for the comment barrage, but I just remembered another question.

Casey Link @.***> writes:

We don't have to run this command, but then user intervention is required
before they have a working ocis instance. If we don't run the command, then
they would have to run it themselves.
There's plenty of examples in nixos/modules/* of similiar type services
(just grep for "-init.service" or "init-.*.service"), so I think this is a
well established convention.

One more thing to remember is init-service, being inherently
imperative, does not play nice with machine migration. It assumes data
(including config generated by init-service) being migrated/copied over
before config.
If the data is migrated after service is already started, then we are on
the hook to ensure service supports (and keep supporting) hot-reload of
config and the copied over stuff has right permissions, something most
backup tools already do, and good admins already practice. But this is
again another thing the user has to keep in mind before migrating.
I'm not a super-power-user, but I have performed multiple device
migrations in past years that I've been using NixOS, and the imperative
init-service does not map cleanly to my mental model of how NixOS
config works, where I just copy over config and private key for secret
decryption (I use agenix :)). Everything I ever have to know is in *.nix
files. I know for sure that even if I lose all the data to say
crypto-ransomware (extreme example, please bare with me), my logins and
config keeps working. If something like that does happen, I have bigger
problems, but still one less thing to worry about :)
Not sure this actually supports the argument, but just another thorn in
the haystack.

Sorry for the comment barrage, but I just remembered another question.

Haha no problem. I'll try to address everything and group related things together.
Let's dive in..

Pretty sure ocis init is not required. What is required is the values of environment variables. We know that because the module test as it is right now runs without ever invoking ocis init :)

Here is a simple test case to show that the default configuration provided by the module is not sufficient:

# run from your nixpkgs directory
nix-build -A ocis-bin
mkdir test/
cd test/

export PROXY_HTTP_ADDR="<IP_ADDRESS>:9200"
export OCIS_URL="https://localhost:9200"
export OCIS_CONFIG_DIR="${PWD}/config"
export OCIS_BASE_DATA_PATH=${PWD}

../result/bin/ocis server web

Result:
The jwt_secret has not been set properly in your config for ocis. Make sure your
/home/ramblurr/src/nixpkgs/test/config config contains the proper values (e.g.
by running ocis init or setting it manually in the config/corresponding
environment variable).

When I saw this I understood why were adding all those extra services.ocis.settings in the test and the example.
Running ocis init of course creates the config/ocis.yaml with many of those pre-generated.
So when I say "ocis init is required", I meant that in the context of a basic
getting-started situation where you specify the minimum amount of required
variables to get a working instance.
I think we are on the same page now about this.

... but I still want to be aware of the full picture and get agency via NixOS module doc+options, and I don't want to /have to/ dig through service docs to get started.

I 100% agree. I think?
I expect a NixOS module to allow me to configure every aspect of the software (I
think you agree with that), but I wouldn't expect reading the NixOS options+docs
to give me everything I need to know about being an admin of the service. At
some point I think it is appropriate to punt and expect the admin to go read the
real documentation for the service.
At the same time I think it is a nice to have if the nixos module lets me get
up and running quickly without forcing me to go become an expert on the service.
It should provide a balance.
In summary my view:

the module should help us get started without having to learn the insides and out of how to run the service
the module MUST let you tweak every knob you need to, especially once you've become an expert in the serivce.

One more thing to remember is init-service, being inherently imperative, does not play nice with machine migration. It assumes data (including config generated by init-service) being migrated/copied over before config.

(snipped rest of that quote)
I think I understand what you're saying here. Let me re-phrase it to be sure:
You're saying that

the config values generated by ocis init in
config/ocis.yaml (which consist primarily of secret and passwords) should (or
even must) be declaratively defined because if you lose those secrets you
cannot access your data (which I don't think is the case) or ocis will not
correctly service you files.

Also, with respect to the "data being migrated/copied over before config",
you're saying that if the user deploys the nixos module, starts it, and then
copies over /var/lib/ocis from a backup, the running ocis daemon will get confused.

Re 1: I tested this by running ocis init then serve, verified I had a
working OCIS. Then I shut it down and removed ocis.yaml and generated a new
one with the init command again.
The result was that you could not login and there were several types of errors
printed by the server. So I think it is safe to say that, yes, you should treat
those config vals as IMPORTANT - DO BACKUP, which, like you said, a good admin
would do anyways.
Re 2: I don't think it ever makes sense to expect a service to be deployed, then
hot-swap everything underneath it and expect it to just work without at least
some sort of systemctl restart
I think it is appropriate to have ocis init generate the config (if the user
explicitly wants, you've convinced me on that), and especially because it lives
right next to the data itself, it will be included in backups and generating and
managing all those secrets by hand is not necessary if there is a tool that does
it for you.
Anyways this is a bit in the weeds.. back to your suggestion:

How about this?
..snip..

Yes, I like this approach.
I guess I prefer to treat all those config values that init generates as
data and not config. Because in most situations you don't need to change them,
and they can be automatically generated (versus actual config like hostname,
port, etc)
Of course that data is config, in the sense that you might have to change it
sometime (to rotate secrets in case of a leak data is config for example), so
those options should be exposed via the module.
And one negative aspect of my init service (as it stands now) is that while it
won't create a new config yaml if it exists, it will create it even if you
supply all those values as env vars, and in theory the env vars should take
precendence. But in any case it is not clean to have a generated yaml lying
around that isn't actually used. That's confusing.
So yes, let's move forward with your suggestion.

Default those settings to null, but assert they are != null
.. UNLESS something like services.ocis.generateInitialSecrets = true;
Separate from 1 and 2 is services.ocis.insecure = true/false; to manage those variables that let you get running quickly without a cert (which is useful for people just getting started)

The insecure flag can always be turned off once the user sets up their certs..
or could never be turned off if they are using a reverse proxy for TLS
termination.
Documentation here is important like you said.
Migrating from services.ocis.generateInitialSecrets = true; to false isn't
straightforward, the user will have to go find the config file and copy paste
all those values into the right env setting in their environmentFile.  The
mapping between the yaml name and the env var name isn't obvious without reading
the docs.

Just want to add, great response, thanks!
Combining both replies:

Yes, I like this approach.
I guess I prefer to treat all those config values that init generates as
data and not config. Because in most situations you don't need to change them,
and they can be automatically generated (versus actual config like hostname,
port, etc)

I see now where you're coming from. The point of contention is that ocis
uses envvars to store both config AND data. But that is for different
mail :p

So yes, let's move forward with your suggestion.

Default those settings to null, but assert they are != null
.. UNLESS something like services.ocis.generateInitialSecrets = true;
Separate from 1 and 2 is services.ocis.insecure = true/false; to manage
those variables that let you get running quickly without a cert (which is useful
for people just getting started)

Looks good!

The insecure flag can always be turned off once the user sets up their certs..
or could never be turned off if they are using a reverse proxy for TLS
termination.
Documentation here is important like you said.

Yeah, this whole thing needs elaborate docstrings everywhere, something
to note, and we do not want the module to go in stable release without.

Migrating from services.ocis.generateInitialSecrets = true; to false isn't
straightforward, the user will have to go find the config file and copy paste
all those values into the right env setting in their environmentFile.  The
mapping between the yaml name and the env var name isn't obvious without reading
the docs.

I'm still trying to think how this can be presented to the user.
Docstrings is one thing, but we want real feedback on what state is
being changed when it is being changed.
e.g. docstring can tell user /before/ adding to config what value they
override. But it gives bad (no) feedback when in 6 months when user
comes back to config for changing something and of course, config
doesn't have docstrings. So now user again has to go to module doc, read
all the options they have enabled (including generateInitialSecrets),
infer the yaml file location, read that, and add another variable to
override it. Lots of words to say I see 2 issues:

envvar names and YAML values do NOT always map cleanly and
transparently. e.g. OCIS_JWT_SECRET applies to all services as the
documentation says, but OCIS_PASSWORD doesn't.

when the user returns to make a change, the generateInitialSecrets
option could have already been disabled or even removed. Now the user
has a state they depend on, but not cleanly reflected in config. Since
we are (and can) only asserting limited number of bare minimum envvars,
this creates an information asymmetry in actual state vs what the config
describes.

Considering second point in particular, I think it would be rather
prudent if we scrap envvars entirely, and instead use the settings
option to generate YAML instead. This solves both problems immediately:

What is in config maps cleanly to yaml. This makes it dead easy to
compare the Nix code to YAML in service documentation. Also allows
de-duplication of common values.

If the module had generateInitialSecrets = true at any point in
past, the user is clearly using it. If they now try to override
particular values via settings there is a conflict, and immediate
feedback to user on what file will be replaced, at which point user can
see what the state of config + data actually is.

(2.) is bit problematic, because there is no gradual override of values,
but all-or-nothing. I think that is okay, because now the user can make
the decision about wanting to replace single value in YAML directly, or
putting entire YAML in config, or deploy it via sops/age. Less
convenient, more explicit. Would like to know what you think on this.

Not to further complicate things.. but I just went and looked at my own prod
instances of ocis (I have several, not running on nixos, something I hope to
change :D).

Had you lead with this, I'd have probably bowed out long ago :p Thanks for
being cool :)

In order to get ocis to work properly with my IDP (like keycloak) I had to
supply a
config/proxy.yaml
file to set some settings that are not available to set as environment
variables.

Sigh, why do oC folks make these questionable decisions? Nevermind, back
to topic..

In our current version of the module there is no easy way to drop config a file
into /var/lib/ocis/config.
Some options here:

We move OCIS_CONFIG_DIR to /etc/ocis

technically I guess this is already possible by overriding OCIS_CONFIG_DIR in my settings
this lets the admin (or the module) use environment.etc to populate extra config files.

We add something like services.ocis.configFiles (type = types.listOf types.path;) that copies them for you.

How would the module copy them? It would be some sort of nasty symlink or runtime install ... script. Not a fan of this option

What if we need to specify a config file that contains secrets? OCIS
currently doesn't let us specify the actual path of proxy.yaml only the OCIS_CONFIG_DIR.

I quite like 2 actually. We can have a service option to specify origin path for proxy.yaml and
Nix can symlink it at runtime. The option docstring can have same
warning about being world readable unless encrypted yadda yadda. I think
that is good enough.
--

I think it would be rather prudent if we scrap envvars entirely, and instead use the settings option to generate YAML instead.

So.. initially I thought this was a good idea. But by the time I finished writing the reply, and in particularly, working out some examples...I think it results in insanely verbose configs that are a pain to work with.
(here starts the initial reply) Yes, I think this is a good idea. Importantly though since the ocis.yaml config file contains secrets it cannot be a file that is stored in the nix store. But nixos already has a couple ways to manage this. Here's some ideas for how to handle it:

User supplies entire config yaml using something like services.ocis.configFile

This bypasses all settings we would set in the module. The admin is 100% responsible for ensuring it has the correct values.
The file can by a sops/agenix file that is symlinked into place, or if the admin wants, just a plain text file they plop somewhere.

We expose services.ocis.config which takes a nixlang datastructure that is serialized to yaml using lib.generators.toYAML

We do not try to enumerate every possible valid option in this datastructure, rather we just serialize it as is.
We can use the _secret convention combined with replace-secret to allow embedding of secrets

One problem with eschewing env vars is that there are 15 separate secrets that are required to bootstrap an ocis instance, but these secrets need to be placed in the config.yaml file multiple times: https://gist.github.com/Ramblurr/9698ae25913a2370c2188cc1d70d8529
I think this problem is well illustrated with the following examples.
Here are three example usages of the nixos module as we're talking about it now:
Basic, getting started
services.ocis = {
  enable = true;
  generateInitialSecrets = true;
  insecure = true;
  config = {
    idm = {
      service_user_passwords = {
        admin_password._secret = "/run/secrets/ocis-admin-pass";
      };
    };
  };
};

Advanced, admin supplies all config
services.ocis = {
  enable = true;
  configFile = "/run/secrets/ocis.yaml";
};

Intermediate, supplying config in yaml
  services.ocis = {
    enable = true;
    config = {
      log = { # putting this here just to show what non-secrets look like
        pretty = true;
        color = true;
        level = "info";
      };

      token_manager = {
        jwt_secret._secret._secret = config.sops.secrets.ocis.jwt_secret.path;
      };
      machine_auth_api_key._secret._secret = config.sops.secrets.ocis.machine_auth_api_key.path;
      system_user_api_key._secret._secret = config.sops.secrets.ocis.system_user_api_key.path;
      transfer_secret._secret._secret = config.sops.secrets.ocis.transfer_secret.path;
      system_user_id._secret._secret = config.sops.secrets.ocis.system_user_id.path;
      admin_user_id._secret._secret = config.sops.secrets.ocis.admin_user_id.path;
      graph = {
        application = {
          id._secret = config.sops.secrets.ocis_graph_application_id.path;
        };
        identity = {
          ldap = {
            bind_password._secret = config.sops.secrets.ocis_graph_identity_ldap_bind_password.path;
          };
        };

        service_account = {
          service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
          service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
        };
        idp = {
          ldap = {
            bind_password._secret = config.sops.secrets.ocis_graph_idp_ldap_bind_password.path;
          };
        };
        idm = {
          service_user_passwords = {
            admin_password._secret._secret =
              config.sops.secrets.ocis_graph_idm_service_user_admin_password.path;
            idm_password._secret = config.sops.secrets.ocis_graph_idm_service_user_idm_password.path;
            reva_password._secret = config.sops.secrets.ocis_graph_idm_service_user_reva_password.path;
            idp_password._secret = config.sops.secrets.ocis_graph_idm_service_user_idp_password.path;
          };
        };

        proxy = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };

        frontend = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };

        auth_basic = {
          auth_providers = {
            ldap = {
              bind_password._secret = config.sops.secrets.ocis_ldap_bind_password.path;
            };
          };
        };

        users = {
          drivers = {
            ldap = {
              bind_password._secret = config.sops.secrets.ocis_ldap_bind_password.path;
            };
          };
        };

        groups = {
          drivers = {
            ldap = {
              bind_password._secret = config.sops.secrets.ocis_ldap_bind_password.path;
            };
          };
        };

        ocm = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };
        thumbnails = {
          thumbnail = {
            transfer_secret._secret = config.sops.secrets.ocis.thumbnails_transfer_secret.path;
          };
        };
        search = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };

        settings = {
          service_account_ids = [ config.sops.secrets.ocis_service_account_id.path ];
        };
        storage_users = {
          mount_id._secret = config.sops.secrets.ocis.storage_users_mount_id.path;
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };

        notifications = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };
        gateway = {
          storage_registry = {
            storage_users_mount_id =
              config.sops.secrets.ocis.gateway_storage_registry_storage_users_mount_id.path;
          };
        };

        userlog = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };

        auth_service = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };

        clientlog = {
          service_account = {
            service_account_id._secret = config.sops.secrets.ocis_service_account_id.path;
            service_account_secret._secret = config.sops.secrets.ocis_service_account_secret.path;
          };
        };
      };
    };
  };

:nauseated_face: :vomiting_face:
Why would anyone ever go through that exercise of converting from yaml->nix ? I just did it once for the sake of this example and never want to do it again.
Especially since 99% of people will be starting with values generated from ocis init (whether manually ran or via a generator we provide), the process of going from yaml ---(manually)--> nix to just then go again nix ---> yaml is unnecessary imo.
Give a choice of the three examples most sane people will choose the first and second one. Which means all the code required (and the effort to produce and maintain it) to support the third one (nix->yaml w/ secret substitution) will be in vain.

(2.) is bit problematic, because there is no gradual override of values, but all-or-nothing.

I think my example shows it is a problem?
Even the ocis docs seem to admit that the config yaml format is super verbose, which is why many env vars end up setting multiple yaml options (OCIS_URL for example).
I am now leaning to go back to what you had originally :laughing: :

Just work with env vars, this avoids the yaml explosion
Do not provide an automatic services.ocis.generateInitialSecrets option, this avoids the problem that led us down the road yaml explosion
...plus something to handle the proxy.yaml case.

I could write a simple script that runs ocis init and converts the output into an env var format the user could add to their config as an environmentFile, that would be relatively simple and still allow us to have provide an easier getting started path:
Example docs:
Getting started with the nixos OCIS module:

Generate your initial secrets
 ocis-nix-init > my-ocis-env

Encrypt it with the method of your choice (sops, agenix, etc)

Configure the module:
 services.ocis = {
     enable = true;
     environmentFile = config.sops.secrets.ocis-env.path;
 };

What do you think?

We add something like services.ocis.configFiles (type = types.listOf types.path;) that copies them for you.

I quite like 2 actually. We can have a service option to specify origin path for proxy.yaml and Nix can symlink it at runtime. The option docstring can have same warning about being world readable unless encrypted yadda yadda. I think that is good enough.

Yes I suppose the symlink munging can easily be done with systemd.tmpfiles.rules or a bash ExecStartPre= script.

Documentation for other NixOS modules tends to simply mention "this should be a path outside the Nix store" rather than pointing users to a specific tool. I think this is important to avoid confusion for new users: if you have a single machine, there is nothing wrong with simply installing the file and making a backup copy by hand.

You're right, that YAML soup is awful to look at and nightmare to work with.
Casey Link @.***> writes:

I am now leaning to go back to what you had originally :laughing: :

Just work with env vars, this avoids the yaml explosion
Do not provide an automatic services.ocis.generateInitialSecrets option, this avoids the problem that led us down the road yaml explosion
...plus something to handle the proxy.yaml case.

I could write a simple script that runs ocis init and converts the output into an env var format the user could add to their config as an environmentFile, that would be relatively simple and still allow us to have provide an easier getting started path:

I think this is about time we ask users to think for themselves ;)
Instead of providing any kind of conversion script that we get to
maintain, we ask users to generate initial config directly via
ocis-init, and point the module to it. @danth also seems to agree:

Documentation for other NixOS modules tends to simply mention "this should be a
path outside the Nix store" rather than pointing users to a specific tool. I
think this is important to avoid confusion for new users: if you have a single
machine, there is nothing wrong with simply installing the file and making a
backup copy by hand.

So, combining with above, let's have 3 options:

configFile : path to config file, user can generate this via ocis init and either have
it directly in store or encrypt it.

settings : gets applied to systemd unit as envvars.

environmentFile : envvars, but in file that user can put wherever.

My reasoning: configFile gets explicitly generated by user, and they can
decide if and how they want to encrypt it. settings is the most
convenient option to do anything with. environmentFile is the middle
ground between world readable settings and black-box configFile.
Particularly because of the way OCIS and systemd units give precedence
to values, we have in order of increasing precedence, configFile ->
environmentFile -> settings. I think this provides enough flexibility,
security and convenience.
It does require users to do some work, but heavy lifting will be done by
manual ocis init invocation. They have to ensure the config file is
accessible to the service, which can be easily explained by docstring.
WDYT?

I would go with environment rather than settings since it's consistent with the naming of environmentFile, and it makes it obvious that it's referring to environment variables rather than the YAML format.
We should also ensure that the error message produced if configFile is not set or does not exist is as clear as possible about how to proceed.

Okay, I've added a commit with some of the discussed changes, please take a look.
Remaining items:

adopt test to run ocis init first. Little bit of search didn't yield a result so the test is failing.
adopt @Ramblurr 's suggested test of actually loggin into the service
Clean up commits

I also forgot about proxy.yaml, but I think we can add that to configDir docstring. Let me know what you think.

I've updated my "suggestion" branch:
https://github.com/Ramblurr/nixpkgs/commit/26f526d2fba89967c3ec2ad1187efb728d14c50e

Added working nixos module test
Added a ocis.md module documentation
Added the systemd hardening settings

Alright!
@Ramblurr did a bang up job, I adopted your changes pretty much verbatim. Great work! I added you as co-author to module commit, since you already did most of the work there :)
Couldn't quickly find email for @danth , but happy to have it, please let me know if you want.
Also made some tiny changes to docstring and added list of services and their ports to ocis.md.
I think this looks good, feel free to take a look.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/1570


Remote Jupyter Kernel session disposed and cannot be restarted

Applies To

[X] Notebooks (.ipynb files)
[ ] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?
I am working with Jupyter notebooks in VS Code using a remote Jupyter server.
Periodically whenever I try to run a cell, I get the following message:
Cannot execute code, session has been disposed. Please try restarting the Kernel.
But the restart button at the top of the notebook is disabled:

In the same VS Code instance, if I open a new Jupyter notebook in a different tab and try to connect it to the remote kernel, it works just fine. But the original notebook seems "cursed" - it doesn't matter what I do (close it, re-open it, restart the remote kernel, clear the list of remote kernels and re-input it) VS Code things the kernel has been disposed and nothing will make it start a new one.
The only thing that seems to work is closign the VS Code window completely (but not force quitting VS-code) and re-opening it.
VS Code Version
Version: 1.84.2 Commit: 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e Date: 2023-11-09T10:52:57.054Z (3 wks ago) Electron: 25.9.2 ElectronBuildId: 24603566 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: <IP_ADDRESS>-electron.0 OS: Darwin arm64 23.1.0
Jupyter Extension Version
v2023.10.1100000000
Jupyter logs
Unfortunately I got to this box after closing the VS Code window and re-opening it, and it works now

Coding Language and Runtime Version
Python v.311.6
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
Remote

Please could you enable logging as follows:

Open settings & go into Jupyter->Logging
Change the value to verbose
Reload VS Code,
Attempt to repro the issue & then copy the output from the Jupyter output panel.

Periodically whenever I try to run a cell, I get the following message:
Cannot execute code, session has been disposed. Please try restarting the Kernel.

Please note, this is an indication of the fact that the kernel died.
This is most likely caused by some code in your notebook.
If you can only repro this in one notebook, then the problem is likely an issue with the code or some of the packages.
Based on past issues, we've found users tend to have some older versions of packages, or incompatible packages that causes the kernel process to crash/die.
Please do check if this is the case,

Thanks @DonJayamanne . I'm aware that the problem is that my kernel has died. The bug is that when the kernel dies, VSCode seems unable to recreate it (the "restart" button is disabled, as shown in my initial post), and I have to close VS Code completely to fix it.
Unfortunately, it seems pretty difficult to make a Jupyter kernel die, so I can't reproduce it (if you know a sure-fire way to reproduce a kernel crash let me know!)
That said, I'll enable jupyter logging now, so the next time it happens I'll hopefully be able to post the trace here. You can put the ticket into a dormant state in the meantime.
Thanks!!

The bug is that when the kernel dies, VSCode seems unable to recreate it (the "restart" button is disabled, as shown in my initial post),

Ok understood, apologies for misunderstanding the issue
Will check this out

restart the remote kernel, clear the list of remote kernels and re-input it) VS Code things the kernel has been disposed and nothing will make it start a new one.

Please could you enable logging as follows:

Open settings & go into Jupyter->Logging
Change the value to verbose
Reload VS Code,
Attempt to repro the issue & then copy the output from the Jupyter output panel.

@DonJayamanne : I've enabled verbose logging. I've tried to repro the issue but can't because it's hard to intentionally crash a kernel, but I'll keep trying and report back here with logs as soon as it does

I know this issue is a closed and a fix is pending in next release. My kernels are served by Enterprise Gateway and it's configured to automatically cull kernels after a period of inactivity (12 or 24 hours). I found a temporary workaround that doesn't require restarting the IDE. Use the kernel picker to switch to a local python environment then switch back to your Jupyter kernel.


Failed to delete backend

In Amplify Console I  try delete my application and it says "Failed to delete backend"
Here is the app details:
App name
romexis-vue
App ARN
arn:aws:amplify:eu-central-1:910630674321:apps/d1ib7traq3jffj
Source repository
https://bitbucket.org/nyholkupm/romexis-vue/src/master
Created at
30/04/2021, 14:21:37
Production branch URL
https://master.d1ib7traq3jffj.amplifyapp.com
Updated at
30/04/2021, 14:21:37
Framework
Vue - Amplify

@nyholku If you are still facing this issue, could you please try the suggestion here: #1330 (comment)
Basically, try running this command:
aws amplify delete-backend-environment --app-id <YOUR_APP_ID> --environment-name <THE_BACKEND_ENVIRONMENT_NAME>

Closing as duplicate of https://github.com/aws-amplify/amplify-hosting/issues/882. Please track the status of the bug fix using that issue. Thank you!


How disable features?

Hi all, how we can disable some features? I don't want to transpile custom properties and this doens't work
cssnext({
    browsers: ['last 1 version'],
    features: {
      customProperties: false
    }
}),

Looks good. Can you provide full config?

My fault. This works.

I am not sure on how to disable autoprefixer.
module.exports = {
  plugins: [
    require("postcss-cssnext")({
      features: {
        autoprefixer: false, // HERE OR NEXT TO FEATURES
        customProperties: {
          variables: {
            colorPrimary: "#51a9f2"
          }
        }
      }
    })
  ]
};

Oh, it was correct, never mind


Set "ASPNETCORE_ENVIRONMENT": "Production", => site.css not created, file missing error

site.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)
react-dom.development.js:20065 Download the React DevTools for a better development experience: https://fb.me/react-devtools
2(index):1 EventSource's response has a MIME type ("text/html") that is not "text/event-stream". Aborting the connection.
site.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)
(index):1 EventSource's response has a MIME type ("text/html") that is not "text/event-stream". Aborting the connection.

Hello @gunnarsireus,
Thanks for using React Core Boilerplate!
I did a lot of bugfixes in new version. Is it ok now?

See #4


Add builder stage to Dockerfile

Codecov Report

Merging #36 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #36   +/-   ##
=====================================
  Coverage      24%    24%
=====================================
  Files          10     10
  Lines        2208   2208
=====================================
  Hits          530    530
  Misses       1678   1678

Continue to review full report at Codecov.

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

The pip wheel trick is from this article.


Support closed-file diagnostics in VS Code

For https://github.com/microsoft/vscode/issues/13953
Background
Project wide diagnostics are the most requested VS Code JS/TS feature. However, we've been blocked on implementing them by the fact that TS server is single threaded. This means that computing these diagnostics could interrupt normal user operations like completions.
We currently recommend that people use tasks to get around this limitation (since tasks always run as separate process) however few people actually use tasks.
With https://github.com/microsoft/vscode/commit/f0942786b4ee338f02449e2e5751091e028eb898, I've added a new setting that spins up a new TS Server just for diagnostics. This accomplishes much the same thing as using a task.
Problem
In the prototype, I'm using the geterrForProject command. This works ok for smaller projects but triggers a huge number of events for larger projects like the VS Code source. Instead, we need an API that: given a file, returns a list of inverse dependencies (i.e. the files that need to be rechecked after the file changes)
I believe that this API more or less already exists with compileOnSaveAffectedFileList? But that command only works if compileOnSave is enabled. We'd like to enable project wide error reporting even when users have not enabled compileOnSave.
/cc @sheetalkamat For background on compileOnSaveAffectedFileList
/cc @amcasey As you suggested using a separate diagnostics only server

Related question: before calling geterr on a file do I always have to use updateOpen on it? Right now it seems like I have to explicitly open files against TS server in order to get back errors for them.

@sheetalkamat thoughts?

FWIW - @mjbvz met about this and I'm working on prototyping project-wide diagnostics more broadly than this particular ask

#15168 might be a relevant discussion point for this issue too.

Instead, we need an API that: given a file, returns a list of inverse dependencies (i.e. the files that need to be rechecked after the file changes)

Yes, the first thing you want to see is errors from the current file ("what's affected in this file?") and then that file's dependents ("what did this file affect?"); however, when would you query for errors for the dependencies of the open files? (i.e. "what's wrong with whatever this file depends on?")

I just turned on tsserver.experimental.enableProjectDiagnostics and it seems to give me what I expect. Files with Typescript errors show as red in the Explorer. So that's nice.
But it does seem slow, and in general the error checking is just a bit sluggish. I might fix a syntax error but have to wait a second or two before it registers.
It does show the node_modules folder in red and appears to be checking that for errors despite that folder being excluded in tsconfig.json.
Seems like this issue has been open for a while, and it also seems like it would be fairly trivial to fix. So...can we get a fix for this?

tsserver.experimental.enableProjectDiagnostics

Small fix, the right string on the settings.json is "typescript.tsserver.experimental.enableProjectDiagnostics": true

Is there an expected time to completion on this issue? It would be nice to see what breaks in my codebase when changing lint rules, or just refactoring types...


Is it possible to use controller as?

When I use controller as and dynamically populate the input model then reset give error
Unable to get property 'ticked' of undefined or null reference

Hi @saralamuralikrishna ,
Can you try to replicate this on Plunker or JsFiddler?

We have the same issue here.
here is how we populate the control
for(var i=1; i<$rootScope.allCountries.length; i++)
        {
            var countryData =  {
                name: $rootScope.allCountries[i].name,
                ticked: true};

            $scope.inputCountries.push(countryData);
        }

@afnanKH ,
Can please replicate in Plunker or JsFiddler?


Gurobi version 10.0.0 does not work with ortools 9.4.* or ortools 9.5.*

What version of OR-Tools and what language are you using?
Version: main/v9.5/v9.4 etc.
Language: Python
*Which solver are you using (Gurobi)
*What operating system (Linux, Windows, ...) and version?
Both windows and linux
What did you do?
Steps to reproduce the behavior:
Install Gurobi full binary + python package
install ortools from PIP
test example
What did you expect to see
run normally
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0110 12:39:14.192021 12204 environment.cc:744] Found the Gurobi library in 'C:\gurobi952\win64\bin\gurobi95.dll.
Number of variables = 2
Number of constraints = 2
Solution:
Objective value = 23.0
x = 3.0
y = 2.0
Advanced usage:
Problem solved in 5.000000 milliseconds
Problem solved in 0 iterations
Problem solved in 0 branch-and-bound nodes
What did you see instead?
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0110 12:44:39.968797 31088 environment.cc:744] Found the Gurobi library in 'C:\gurobi1000\win64\bin\gurobi100.dll.
F0110 12:44:39.969797 31088 dynamic_library.h:68] Check failed: function_address != nullptr Error: could not find function GRBloadenvsyscb in C:\gurobi1000\win64\bin\gurobi100.dll
*** Check failure stack trace: ***
Make sure you include information that can help us debug (full error message, model Proto).
Anything else we should know about your project / environment

Yes. Known and fixed on main.


drivers: clock_control: Extend API with request/release

This is a draft of proposed clock_control API extension.
It is taking advantage of onoff module for managing shared resource (#21090).
It also clarifies behavior regarding reference counting (see #20806) by defining two methods of controlling clock:

straight forward on(optionally asynchronous)/off for single clock user
shared clock resource requested and released

Mixed usage is not recommended. API's are optional allows only partial implementation.
Signed-off-by: Krzysztof Chruscinski<EMAIL_ADDRESS>

added cancel and reset.
Basically, when onoff service is in, API will cover onoff client API with dev and subsys identifying a service.


Property "status" in ListCustomerArticles:, GetCustomerArticleById: and CreateCustomerArticle:

Why is Property "status" optional in ListCustomerArticles:, GetCustomerArticleById: and CreateCustomerArticle:?
Property "status" is an important property specifying if the Article is Active or Inactive.
Shouldn't it be required?
Property "sellerProductStatus" is also optional.
Shouldn't it also be required?

It will be done if we approve the https://github.com/papinet/papiNet-API/issues/66.

Following the issue https://github.com/papinet/papiNet-API/issues/66, it will be done. So, we can close this issue.


Request: Branch protections and required CI checks

Branch Protections and Required CI checks
This issue requests branch protections and required CI checks to be enabled for the railwayapp/cli repository.
It might be due to the fact that I am not a member of this repository / org but it looks like there are no required CI checks on this repo. I can see that there are CI checks but none of them are required. This may not be available to this organization depending on your plan, but if you are able to add branch protection rules, I would highly suggest doing so.
I would also suggest requiring a member of the organization to approve CI runs from all outside contributors.

These are already enabled

Wonderful! It was probably just due to my permissions that I could not see if they were required


node SDK automatically generated files should not be checked into git

Description
fabric/sdk/node/doc and fabric/sdk/node/lib (and maybe other directories?) contain automatically generated files and should not be checked into git.  The reason this was done initially was because we want these files to be part of each "npm publish" for the "hfc" node module and it was thought that the only way to do this was to NOT have these directories in .gitignore files.  However, after further investigation, it is possible to put these directories in .gitignore files and also create .npmignore files which do NOT contain these directories.  npm will then ignore the .gitignore files and use .npmignore file instead.   See https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package
So I think the following steps will solve this and should be done:

Copy fabric/sdk/node/.gitignore to fabric/sdk/node/.npmignore
Add "doc/" and "lib/" to fabric/sdk/node/.gitignore
Delete the doc and lib directories
Create a fabric/sdk/node/bin/build script which does everything currently done in the fabric/Makefile under the "node-sdk" target, which is:
cp ./protos/.proto ./sdk/node/lib/protos
cp ./membersrvc/protos/.proto ./sdk/node/lib/protos
cd ./sdk/node && sudo apt-get install npm && npm install && sudo npm install -g typescript && sudo npm install typings --global && typings install
cd ./sdk/node && tsc
cd ./sdk/node && ./makedoc.sh
Edit fabric/Makefile to call fabric/sdk/node/bin/build and remove the above from Makefile
Create a fabric/sdk/node/bin/npm-publish script which does the following:
a) calls the 'build' script from step #4
b) performs an npm update according to https://docs.npmjs.com/getting-started/publishing-npm-packages#updating-the-package, which means this script should require the  argument (i.e. patch, minor, or major).  Note that the "npm version <update-type" actually updates the package.json file and must be done from the fabric/sdk/node directory.

We should always invoke the npm-publish script just before creating a pull request.
Describe How to Reproduce
Check github to see these files

I have opened PR #2147 in order to address points 1-3 above. Points 4-5 have already been addressed by the time this issue was opened. And point 6 is being tracked in issue #2066.


add new mysql 8 keywords

mysql v8 added some new keywords.
The full keyword list can be found here: https://dev.mysql.com/doc/mysqld-version-reference/en/keywords-8-0.html

adds new v8 keyword and removs keywords that are no longer "active".
removed one duplicated keyword CURRENT

🎉


No way to properly create a new Accelerator?

Please correct me if I'm wrong, but for me it looks like you can't properly create a new Accelerator and add it to an AcceleratorResource?
I can create a new Accelerator with
Accelerator acc = new Accelerator();
I can then add the command as an integer to it
acc.Command = 20035;
And that's it - I can't do anything else.
This means I can't even assign a key because the Accelerator.Key function is read only.
If I then add the new Key to the AcceleratorResource with
 accres.Accelerators.Add(acc);
My Resource will look like this:
602 ACCELERATORS
BEGIN
 X, 20037, VIRTKEY, NOINVERT, CONTROL
  , 20035,
END
What I need though is:
602 ACCELERATORS
BEGIN
 X, 20037, VIRTKEY, NOINVERT, CONTROL
 L  , 20035, VIRTKEY, NOINVERT, CONTROL
END
My guess is this feature isn't used very frequently, which is the reason for it being kind of incomplete?
Are there any plans to add this in the future?

It does look like something that just wasn't implemented, please feel free to contribute.

Made a pull request with the new methods. :)


[#36] Update portal-widget styling to match voxbone.com/portal

We need to check if this needs to be even more similar to the example given.

@chadwallacehart I made several little changes that to me makes the page look cleaner than before.
Please note that I removed the Iframe and Div tabs. As we weren´t using the iFrame approach I think that those tabs are not necessary anymore. Just to have one div tag may confuse users a little bit.
This is the deployment full url in case you dont have it :
deployment
Please let me know what you think

I like it! Please merge and move to production (if it passes QA)

Merging it & deploying to Staging 👍


Slower than win32 capture screen

I am using Win32's window handles to take screenshots almost 10 times faster than dxcam, does dxcam support window handles?

There is indeed this strange problem. The screenshot of win32 handle can be 250fps
Dxcam only has 110-150fps
All use 640 * 640
nv 3080 12G
Dxcam version:last
I suspect it is caused by image clipping, but I am not very familiar with the code...

@hopepanwei are you sure?  I think 250fps hard to get :|

Check this https://github.com/AI-M-BOT/DXcam/releases/tag/1.0

@hopepanwei are you sure?  I think 250fps hard to get :|

With win32 handle it is easy peasy to each 250+ fps
Check this https://stackoverflow.com/questions/3586046/fastest-way-to-take-a-screenshot-with-python-on-windows

Check this https://github.com/AI-M-BOT/DXcam/releases/tag/1.0

@hopepanwei are you sure?  I think 250fps hard to get :|

With win32 handle it is easy peasy to each 250+ fps Check this https://stackoverflow.com/questions/3586046/fastest-way-to-take-a-screenshot-with-python-on-windows

Could you compile for python 3.11?


[FATAL tini (6)] exec python3 failed: Exec format error

Trying to get this running on Home Assistant Core 0.109.3
log says: "[FATAL tini (6)] exec python3 failed: Exec format error"
Any help?

Also trying to get it running on Home Assistant Core 109.3.
Any documentations or REST commands how to use this addon?

Hello to both of you @wimpie007 @pen96,
I still have to update to 0.109.3, I'll look into that later.
For the documentation, look at the cast_site here: https://github.com/eliseomartelli/ParentsHomeAutomation/blob/master/homeassistant/integrations/rest_command.yaml

oeps, i was mistaken...
'You are currently running version 0.108.3'

Updated to the latest version and I don't have this kind of issue.
Can you please send me the log like this?

Well, there is nothing more in the logs...
https://imgur.com/a/kn5XS0j

That's really strage, are you using portainer?

installing portainer as we speak! what do you want me to do?

@eliseomartelli
I'm running home assistant on a RPI4....
You probable not on a ARM device?

Any news about the ARM problems?

@wimpie007 I don't have an ARM device at hand to generate a docker image for arm devices, I need someone willing to help :)

arm device is not a problem here, but making the docker...

@eliseomartelli I have an ARM device and I managed to build the container and get it working. So I would be willing to help out what I don't understand is how the hassio addon integration with dockerhub works.

@carlba that's awesome!
The homeassistant supervisor reads config.json to see the architectures and pulls the image from docker hub. I think it should be possible to push different images for different architectures on docker hub.
I will look into that later, if you open a PR with the changes needed to get the build working on arm devices I'd be really grateful!


Allow framework plugin architecture

It should be possible to install a framework as a plugin, and then to use that framework with cdev

Addressed in https://github.com/garethmidwood/cdev/pull/53


Use full hostname on vsphere

Fixes #809

Is there some reason we're not using -f for everyone?

Is there some reason we're not using -f for everyone?

Other providers want short version... minority needs -f.


Button: Span or Div should not be allowed

For the button component, on the web, it might not be a good idea to render the text to a div.
I'm playing around with this package and building a simple counter, when clicking the button fast, it starts to highlight the text inside it.
You can see that here (click really quickly):
ie. https://rnr-showcase.vercel.app/button
So I did some searching to see if this is a thing and came up on this SO post:
reference: https://stackoverflow.com/questions/12982269/is-it-semantically-incorrect-to-put-a-div-or-span-inside-of-a-button
If I use asChild, nothing gets rendered in the button:
<Button className="m-2" onPress={handleCounter}>
   <Text asChild>Increase</Text>
 </Button>

Any way to bypass this or fix this?

@shawnmclean Thanks for opening this issue. Here is the fix: https://github.com/mrzachnugent/react-native-reusables/commit/13eb6eb9bd46c4805422588e113e6544ad2cb6a7


Get CodinGamerId doesn't work

I've set my email and password correctly, but running "Get CodinGamerId" fails with this message:

Yes, the API changed very recently on the website. There were some messages on the subject in the discord server. It's getting more and more annoying to connect programmatically to the website. The recommended way from the community is first connecting to the website, then fetch the cookie and save it somewhere to use it with your tools. This is the method I use now to fetch my replays, and I will remove such functionalities from the extension.
If you want to write your own tools, have a look at https://github.com/takos22/codingame. The documentation explains how to login https://github.com/takos22/codingame.
Here is the start of a discussion on the discord server on the subject with another similar solution: https://discord.com/channels/466965651135922206/466965651135922208/902908142982168607

TODO:

[ ] remove get CodinGamer Id from email + password
[ ] remove send bot to CodinGame

I removed the two commands from the latest (2.0.1) version. Closing this issue.


generic driver: since aufs is not supported on btrfs, the default storage driver should be btrfs on such a system

When creating a docker machine using the generic driver and you do not pass the storage driver explicitly, aufs is set in the docker daemon configuration.
For example, on an ubuntu-systemd target system, the docker.service contains:
[Service]
ExecStart=/usr/bin/docker -d -H tcp://<IP_ADDRESS>:2376 -H unix:///var/run/docker.sock --stor
age-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.
pem --tlskey /etc/docker/server-key.pem --label provider=generic

This errors out since aufs on btrfs is a non supported setup:
docker[2969]: time="2015-11-25T16:49:49.636299049+01:00" level=fatal msg="Error starting daemon: error initializing graphdriver: backing file system is unsupported for this graph driver"

So instead of configuring the daemon to use aufs, it would be better to detect the btrfs and use that driver when creating a docker machine without having to explicitly set the storage driver to btrfs on the docker-machine commandline.
Version: master branch, released versions (tested with 0.5.0 and 0.5.1) do not work on systemd-ubuntu 15.10

How to detect that such a machine is using btrfs already?

The way the aufs graphdriver in the docker daemon detects it is running on an incompatible filesystem:
https://github.com/docker/docker/blob/master/daemon/graphdriver/aufs/aufs.go#L92
So the actual filesystem detection: https://github.com/docker/docker/blob/master/daemon/graphdriver/driver_linux.go
I'll see if I have time to create a patch this evening or tomorrow.


follow up from the last sync from google3

follow up from the last sync from google3 (https://github.com/dart-lang/intl_translation/pull/158) - remove two extraneous files

(TBR)


Patch 48bit_index.hpp to prevent gcc13 build errors

Changes in the way GCC 13 handles includes mean this was failing to build. Adding this line resolves the errors - this is the only file that needed altering.

This is fixed in branch develop. Thank you for your patch.


[Improment]Add workload group query detail

Proposed changes
Add workload group query detail to Fe metric.

run buildall

run buildall


Numpy edge table data

This stores (most) table data in large memory-contiguous numpy arrays.
Ragged data such as the individuals.parents column and metadata are hacked into a separate array (and not really tested)

Probably worth merging, as it actually cuts the number of lines down a little


Making the command go to a new line breaks the terminal

Doing \n in your command breaks the terminal
readline.js:1170
throw err;
^
SyntaxError: Invalid or unexpected token
at C:\Users\Hax4dayz\Desktop\JS-Terminal-Simulator-1.0.0\app.js:55:57
at Interface._onLine (readline.js:320:5)
at Interface._line (readline.js:699:8)
at Interface._ttyWrite (readline.js:1025:14)
at ReadStream.onkeypress (readline.js:198:10)
at ReadStream.emit (events.js:311:20)
at emitKeys (internal/readline/utils.js:438:14)
at emitKeys.next ()
at ReadStream.onData (readline.js:1160:36)
at ReadStream.emit (events.js:311:20)
This is the error code

Dead project


Failed to establish a new connection

Hi, I am trying to use the wrapper to fetch my balances, when I put my metamask address and private key I have an error I this specific line of code: uniswap_wrapper = (address, private_key, version=2) , I have the following error message:
ConnectionError: HTTPConnectionPool(host='web3', port=80): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f3786cf4910>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

Read the README more carefully, you've probably set PROVIDER incorrectly.


Update Settings “general”

Automatically generated by Netlify CMS

👷 Deploy Preview for endearing-sfogliatella-6c7dea processing.

Name
Link

🔨 Latest commit
1c9d28d08f86ebdb75d970b06bfd2e81946dd423

🔍 Latest deploy log
https://app.netlify.com/sites/endearing-sfogliatella-6c7dea/deploys/63a04d5fc3e6070009442b65


Add support for limiting Workflows to Collections

Motivation
As of now, the workflows may be limited to specific contents types (Workflow scope). We are currently working on support for limiting workflows to specific collections. This new feature will be added to the API, and with it, the JS SDK should be extended as well.
Proposed solution
Extend WorkflowScope model with collections:
    export interface IWorkflowScopeContract {
        content_types: SharedContracts.IReferenceObjectContract[];
        collections: SharedContracts.IReferenceObjectContract[];
    }

I am not aware of any other required changes.
Additional context
Release date: 1. 3. 2023 (planned)

Closing the issue. This issue was meant to be created in the management SDK repo.


More info on how to download artifacts from different builds

Modified the docs to specify that we need a build id if we are trying to download artifacts uploaded in different builds

Need to make some changes. Closing the PR


mouseenter event not working with stage objects

mouse enter event works with stage perfectly but  not  with the object  attached  to stage..
my code is ..
sprite.addEventListener("mouseenter", function() {  sprite.gotoAndPlay("run");   });

The "mouseenter" event is just a Stage event, which indicates when the user first brings their mouse into the HTML canvas.
http://www.createjs.com/docs/easeljs/classes/Stage.html#event_mouseenter
For display objects, use either the "rollover" or "mouseover" events.
http://www.createjs.com/docs/easeljs/classes/DisplayObject.html#event_rollover


Snyk CLI Download fails in VS 2019

I've installed Snyk CLI from command prompt with commnad npm install snyk -g. Installed Snyk extension from VS Extensions manager. But Snyk doesn't authenticate the VS. When I open the VS I get a message SNYK CLI download failed. PFA the screenshots.

Connecting VS with Snyk never happens.

Hello @kishan-lmk,
Thank you for submitting! Could you share more details with us? For example, could you send your log file to<EMAIL_ADDRESS>Please, specify in your email an ID or a link to this issue.
You could find extension log using this info.
Best regards,
Alex

Also could you, please, try to run CLI auth
snyk auth
via Command prompt. Docs link

Hi, since GitHub issues are not officially monitored by Snyk support, we will be disabling "Issues" tab on this repository very soon.
Please raise the current issue directly by contacting Snyk Support on the web or emailing us at<EMAIL_ADDRESS>


Wrong version of google-gax is being installed

Expected behavior
Installing gcloud should bring in google-gax 0.12.x as a dependency.
Observed behavior
google-gax 0.13.0 installed, which later can cause a version conflict with google-gax-{logging,pubsub...}-* that still depend on 0.12.x
jgeiger@jgeiger:~/repos/test-gcloud-python$ virtualenv venv
New python executable in /usr/local/google/home/jgeiger/repos/test-gcloud-python/venv/bin/python
Installing setuptools, pip, wheel...done.
jgeiger@jgeiger:~/repos/test-gcloud-python$ . venv/bin/activate
(venv) jgeiger@jgeiger:~/repos/test-gcloud-python$ pip install gcloud
Collecting gcloud
Collecting grpc-google-logging-v2>=0.8.0 (from gcloud)
Collecting httplib2>=0.9.1 (from gcloud)
Collecting gax-google-pubsub-v1>=0.8.0 (from gcloud)
Collecting six (from gcloud)
  Using cached six-1.10.0-py2.py3-none-any.whl
Collecting grpc-google-pubsub-v1>=0.8.0 (from gcloud)
Collecting google-gax>=0.12.3 (from gcloud)
  Downloading google-gax-0.13.0.tar.gz
Collecting grpcio>=1.0rc1 (from gcloud)
  Using cached grpcio-1.0.0-cp27-cp27m-manylinux1_x86_64.whl
Collecting oauth2client>=2.0.1 (from gcloud)
Collecting googleapis-common-protos (from gcloud)
Collecting gax-google-logging-v2>=0.8.0 (from gcloud)
Collecting protobuf!=3.0.0.b2.post1,>=3.0.0b2 (from gcloud)
  Using cached protobuf-3.0.0-py2.py3-none-any.whl
Collecting future>=0.15.2 (from google-gax>=0.12.3->gcloud)
Collecting ply==3.8 (from google-gax>=0.12.3->gcloud)
Collecting futures>=2.2.0 (from grpcio>=1.0rc1->gcloud)
  Using cached futures-3.0.5-py2-none-any.whl
Collecting enum34>=1.0.4 (from grpcio>=1.0rc1->gcloud)
  Using cached enum34-1.1.6-py2-none-any.whl
Collecting rsa>=3.1.4 (from oauth2client>=2.0.1->gcloud)
  Using cached rsa-3.4.2-py2.py3-none-any.whl
Collecting pyasn1-modules>=0.0.5 (from oauth2client>=2.0.1->gcloud)
  Using cached pyasn1_modules-0.0.8-py2.py3-none-any.whl
Collecting pyasn1>=0.1.7 (from oauth2client>=2.0.1->gcloud)
  Using cached pyasn1-0.1.9-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): setuptools in ./venv/lib/python2.7/site-packages (from protobuf!=3.0.0.b2.post1,>=3.0.0b2->gcloud)
Building wheels for collected packages: google-gax
  Running setup.py bdist_wheel for google-gax ... done
  Stored in directory: /usr/local/google/home/jgeiger/.cache/pip/wheels/8c/3a/c5/26f7525c0c4f9f56990c3b3eaadabf8b91d1d1e327475e07f0
Successfully built google-gax
Installing collected packages: pyasn1, rsa, httplib2, six, pyasn1-modules, oauth2client, protobuf, googleapis-common-protos, futures, enum34, grpcio, grpc-google-logging-v2, future, ply, google-gax, grpc-google-pubsub-v1, gax-google-pubsub-v1, gax-google-logging-v2, gcloud
Successfully installed enum34-1.1.6 future-0.15.2 futures-3.0.5 gax-google-logging-v2-0.8.1 gax-google-pubsub-v1-0.8.1 gcloud-0.18.1 google-gax-0.13.0 googleapis-common-protos-1.3.3 grpc-google-logging-v2-0.8.1 grpc-google-pubsub-v1-0.8.1 grpcio-1.0.0 httplib2-0.9.2 oauth2client-3.0.0 ply-3.8 protobuf-3.0.0 pyasn1-0.1.9 pyasn1-modules-0.0.8 rsa-3.4.2 six-1.10.0

I'm not sure why this is happening, since setup.py bounds google-gax as google-gax >= 0.12.3, < 0.13dev
/cc @bjwatson @tseaver

gcloud is dead, long live gcloud.
The relevant source is tagged at version 0.18.1. In particular:
GRPC_EXTRAS = [
    'grpcio >= 1.0rc1',
    'google-gax >= 0.12.3',
    'gax-google-pubsub-v1 >= 0.8.0',
    'grpc-google-pubsub-v1 >= 0.8.0',
    'gax-google-logging-v2 >= 0.8.0',
    'grpc-google-logging-v2 >= 0.8.0',
]

Would it be difficult to release 0.18.2 with the upper bound reintroduced?

Nope. Something like this:
$ git checkout 0.18.1
$ emacs setup.py tox.ini  # Make the edits
$ git add setup.py tox.ini
$ git commit -m 'Tightening up the allowed versions for dependencies.'
$ git tag 0.18.2
$ git push upstream 0.18.2

Ditto for the gax and grpc dependencies. This is what I see for this branch:
diff --git a/setup.py b/setup.py
index bd1bacf..66687fb 100644
--- a/setup.py
+++ b/setup.py
@@ -21,11 +21,11 @@ REQUIREMENTS = [

 GRPC_EXTRAS = [
     'grpcio >= 1.0rc1',
-    'google-gax >= 0.12.3, < 0.13dev',
-    'gax-google-pubsub-v1 >= 0.7.12, < 0.8dev',
-    'grpc-google-pubsub-v1 >= 0.7.12, < 0.8dev',
-    'gax-google-logging-v2 >= 0.7.12, < 0.8dev',
-    'grpc-google-logging-v2 >= 0.7.12, < 0.8dev',
+    'google-gax >= 0.12.3',
+    'gax-google-pubsub-v1 >= 0.8.0',
+    'grpc-google-pubsub-v1 >= 0.8.0',
+    'gax-google-logging-v2 >= 0.8.0',
+    'grpc-google-logging-v2 >= 0.8.0',
 ]

 if sys.version_info[:2] == (2, 7) and 'READTHEDOCS' not in os.environ:
@@ -33,7 +33,7 @@ if sys.version_info[:2] == (2, 7) and 'READTHEDOCS' not in os.environ:

 setup(
     name='gcloud',
-    version='0.18.0',
+    version='0.18.1',
     description='API Client library for Google Cloud',
     author='Google Cloud Platform',
<EMAIL_ADDRESS>
Why were these version bounds removed?

Let's check out https://github.com/GoogleCloudPlatform/google-cloud-python/commits/master/setup.py and find out

That wasn't as helpful. Looks like 0.18.1 was creating as a one-off branch:
https://github.com/GoogleCloudPlatform/google-cloud-python/commits/0.18.1/setup.py
Bounds removed in:
https://github.com/GoogleCloudPlatform/google-cloud-python/commit/3c91644be58c58e951e77082265e6873339665e2#diff-2eeaed663bd0d25b7e608891384b7298

I see. So it looks like a bad merge, rather than anything intentional.

Indeed.

@bjwatson @geigerj Do we still want a 0.18.2 or is 0.19.0 sufficient? (Once it builds.)

@dhermes As long as there are no users pinned to 0.18.x complaining about this, I think 0.19.0 is sufficient.

OK thanks. Will re-open if we hear otherwise.

Agreed.


HTML  tag does not let pasted text be inside it

Issue Type: Bug
So I am trying to paste text into a <p> tag, once I hit CTRL+V  the code gets pasted above the <p> tag.
VS Code version: Code 1.69.2 (3b889b090b5ad5793f524b5d1d39fda662b96a2a, 2022-07-18T16:12:52.460Z)
OS version: Windows_NT x64 10.0.19044
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-3437U CPU @ 1.90GHz (4 x 2395)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: unavailable_offvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
3.87GB (0.93GB free)

Process Argv
--crash-reporter-id 5307afa4-26ed-404d-9f63-6d54fa8ef956

Screen Reader
no

VM
0%

I can't reproduce

open https://vscode.dev
create a HTML file with a <p> tag.
Copy some text, place the curser after the p and paste

Can you provide similar steps?

Hi thanks for reaching back, the bug has disappeared after restarting VSCode and now I can paste anything inside a ```` tag with no issues.``

Fixed


[BUG]page.pause() not work. popup a blank window

System info

Playwright Version: [v1.40]
Operating System: [Ubuntu 22.04, macOS 12.63]
Browser: [Chromium]
Other info:

Source code

[ ] I provided exact source code that allows reproducing the issue locally.

Link to the GitHub repository with the repro
[https://github.com/your_profile/playwright_issue_title]
or
Test file (self-contained)
from undetected_playwright.async_api import async_playwright, Page

playwright_browser = await async_playwright().start()
browser_context = await playwright_browser["chromium"].launch_persistent_context(
          _path,
          executable_path="Chromium.app/Contents/MacOS/Chromium",
          ...)
 page = browser_context.pages[0]
 ...
 await page.pause()
 ...

Steps

[Run the test]
[...]

This will pause the page and popup the inspector window.
[Describe expected behavior]
The inspector window is blank
[Describe actual behavior]

I confirm this bug. Was about creating an issue then I saw this.

You can try rebrowser-patches, it breaks .pause(), too. But! It allows temporarily disabling the patch via env variable, so you can disable it while debug your stuff, and then turn back again on the fly.

Same issue. Playwright Inspector is blank, and can't record when i "page.pause()".

@espeka44 do you use process.env.REBROWSER_PATCHES_RUNTIME_FIX_MODE = '0' when you want to run it for debugging?

@nwebson Yes, tried to.
Nothing change

@espeka44 please consider creating a new issue in https://github.com/rebrowser/rebrowser-patches/issues and sharing your code, then I can take a deeper look.

Solved with Update to Patchright.
@nwebson youre not allowed to advertise your services or your projects under this repository.


Modlogs dont show pics

When i post a picture to test it, the I deleted it, and it didnt show in modlogs

currently broke for no apparent reason. code looks all correct. will be working on soon

kk

Images are gone from discord cdn after delete, nothing we can do.


Display Gene Summary Source information

I believe this information is being slurped into the back-end. But it is not yet being displayed next to the gene summary.

As of genome/civic-server@dca5ca44be9ac8b8d75da0aece6032685f2d8e1e the source information is coming back on single gene api requests from the backend.

Done. Closing.


Get Selected Item

Hello.
How do I get the selected element after the click event?
I have the $ itemScope variable, however I can not get the attributes of the element that was selected from the context menu.
Thank you.

It's the 5th parameter passed to the onclick handler. See https://github.com/Templarian/ui.bootstrap.contextMenu#callback-parameters

Hello Friend.
I've already figured it out.
The contents of the context menu are obtained through AJAX calls.
However, I can not delay rendering, and whenever I select an item, the menu contents refer to the last selected variable. That is, in order for me to get the correct content for the current item, I must double-click that item.
How could you get around this problem?
Thank you.

Hi @RogerMito, in version v1.1 (I'll release this soon), you can now use a Promise as your menuOptions. So you can just do something like:
$scope.generateOptions = function() {
  // something that returns a promise
}

Then in your HTML something like:
<div context-menu="generateOptions()" />

You can opt to point your build to the latest commit to test this out.


Datamap containing a missing line critical error

Recent testing of datamaps export master command raised the following error
CRITICAL - Datamap contains a missing line. Please fix datamap before proceeding.

was able to resolve this issue by deleting rows (~10) from the bottom of the datamap. Therefore likely issue with datamaps calculating last row in dm.cvs. Will send dm.cvs file causing error to you for testing. cmd is datamaps export master [PATH to master] and dm.cvs file in datamaps\input file. Any dummy master can be used.

...have asked on Teams to be emailed a copy of the offending CSV file (to personal email please). Thank you!

done.

The offending file contains thousands of empty rows. I will need to include a check for this is in the suite of checks that take place on a datamap prior to processing.

Fixed in v1.1.5.


Manually insert endpoints while using certificates

I'm currently testing out DTLS with a Leshan and a mbedos client. Although there is no way to add the certificates through the Web interface it should be possible to use certificates, as mentioned in
https://github.com/eclipse/leshan/wiki/Supported-features
We did get it working, but not without inserting the endpoint of the connecting client into the security store.
\leshan\leshan-server-demo\src\main\java\org\eclipse\leshan\server\demo\LeshanServerDemo.java#L274
securityStore.add(SecurityInfo.newX509CertInfo("cf-client"));

But as mentioned in
http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20151214-C/OMA-TS-LightweightM2M-V1_0-20151214-C.pdf#page=52

Upon registration, the LWM2M Server MUST check that this CN field matches the Endpoint Name parameter of the registration message during
authentication and MUST respond “4.00 Bad Request” to the LWM2M Client if these fields do not match.
...
This security mode does not require a pre-existing trust relationship (if all entities used X.509 certificate security mode) between the LWM2M Client and LWM2M Server, nor between a LWM2M Bootstrap Server and a LWM2M Client. However, in the case of indirect trust, all entities need a trust relationship with the CA(s) that issued the certificates used in LWM2M Servers and Clients.

there should be no need to insert like this.
Is it behaving like it should be?
FYI: @markus-becker-tridonic-com

We think this make sense to configure if a client is allowed to connect
in X509 or not. If you want to authorize all X509 client without config,
you can implement your own authorizer :
https://github.com/eclipse/leshan/blob/master/leshan-server-core/src/main/java/org/eclipse/leshan/server/security/Authorizer.java
Le 17/03/2017 à 11:54, daniel-cesarini-tridonic-com a écrit :

I'm currently testing out DTLS with a Leshan and a mbedos client.
Although there is no way to add the certificates through the Web
interface it should be possible to use certificates, as mentioned in
|https://github.com/eclipse/leshan/wiki/Supported-features|
We did get it working, but not without inserting the endpoint of the
connecting client into the security store.
|\leshan\leshan-server-demo\src\main\java\org\eclipse\leshan\server\demo\LeshanServerDemo.java#L274|
|securityStore.add(SecurityInfo.newX509CertInfo("cf-client")); |
But as mentioned in
|http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20151214-C/OMA-TS-LightweightM2M-V1_0-20151214-C.pdf#page=52|
Upon registration, the LWM2M Server MUST check that this CN field
matches the Endpoint Name parameter of the registration message during
authentication and MUST respond “4.00 Bad Request” to the LWM2M
Client if these fields do not match.
...
This security mode does not require a pre-existing trust
relationship (if all entities used X.509 certificate security
mode) between the LWM2M Client and LWM2M Server, nor between a
LWM2M Bootstrap Server and a LWM2M Client. However, in the case of
indirect trust, all entities need a trust relationship with the
CA(s) that issued the certificates used in LWM2M Servers and Clients.

there should be no need to insert like this.
Is it behaving like it should be?
FYI: @markus-becket-tridonic-com
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/leshan/issues/291, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzSZhGKvRcZPCGjQNMPrikj2ZBSTVG3ks5rmmZ3gaJpZM4MgcbY.


ign -> gz FindXXX migration : gz-cmake

See: https://github.com/gazebo-tooling/release-tools/issues/698
NOTE: THIS MUST BE REBASE MERGED!! Files were moved!
Description
All FindXXX.cmake files have been hard migrated to Gz.
Some downstream packages still use them via the gz_find_package() call, so an intercepting redirection of any Ign prefixed find calls to Gz has been implemented (with warning.)

Hard-tocks

<Package_name>_FIND_VERSION_MINOR CMake variables are being used (but populated automatically from the find_package() call, which might be the Gz or Ign version
Hard-tocked these since the file names changed (and the only way they'll be found is if the redirected find_package() call uses the Gz prefixed package name, which will set the Gz prefixed _FIND_VERSION_MINOR var)
Likewise with XXX_FIND_COMPONENTS

These are internal to the best of my knowledge, so the user shouldn't be using them

Tick-tocks

Downstream libs are using XXX_FOUND variables, I will ticktock those
Explicitly being set() with an Ign prefix, just in case they'll be used downstream

Notes

gz_import_target is being called to generate targets.

The call itself is made of several components:
  gz_import_target(IgnOGRE2
    TARGET_NAME IgnOGRE2::IgnOGRE2
    LIB_VAR OGRE2_LIBRARIES
    INCLUDE_VAR OGRE2_INCLUDE_DIRS)

That is,
  gz_import_target(<package_name>
    TARGET_NAME <TARGET>::<TARGET>
    LIB_VAR OGRE2_LIBRARIES
    INCLUDE_VAR OGRE2_INCLUDE_DIRS)

The package name is hard-tocked, and library aliases are installed for the imported target name.
In order to add alias targets, however, I needed to set the imported add_library() call to GLOBAL visibility.

https://github.com/gazebosim/gz-cmake/pull/273/commits/c409c94fc5f1bbf64f56b73329104e927fb438bd#diff-42bab6079b4ba6149374a4f37a702aabec4cd82b534287747b8014a4a1a39eb8R110
I don't know what implications this will have on performance, but it works. To be safe we should remove the GLOBAL keyword once we don't need the tick-tock.

testing sdformat against this branch in macOS and windows CI using the ci_matching_branch/ trick in https://github.com/gazebosim/sdformat/pull/1072

Gonna squash all the non moving commits :eyes:


Add a native Flat encoder for UPLC

Before this is merged it should be checked once if the cardano-node correctly handles this cbor encoding and does not refuses it if the byte string is too long etc


Navbar: transparent line flickers as you scroll

macOS BigSur 11.3
Version 93.0.4577.63 (Official Build), (arm64)
Hello,
I noticed this problem: when you scroll down or up, there is a transparent bar at the top of the window above the navigation links; It flickers as you scroll.

Example: https://jsfiddle.net/yuridarwin/kndp534y/5/
https://user-images.githubusercontent.com/4470015/132101140-0bc88840-c53c-43f9-a554-e58bc258dc6a.mov

This works smoothly on my end in every browser. Perhaps there's some browser zooming or something else interfering with the scroll? I've seen both have an impact on such things in the past.

This works smoothly on my end in every browser. Perhaps there's some browser zooming or something else interfering with the scroll? I've seen both have an impact on such things in the past.

I have a 5k monitor, and I'm always watching the browser in a relatively small window,  I'm constantly changing the size of the browser in dev. I drag the browser window to another monitor, and it's fine. Fantastic.