nixos: remove environment.noXlibs

Description of changes
This removes the environment.noXlibs option, a common footgun for new/inexperienced users of NixOS who are tempted by the promise of a lighter, more minimal system. Instead, they end up with a system that can surprise them with unexpected rebuilds or even broken builds for reasons that aren't immediately obvious.
This creates a frustrating experience for these users, but it also wastes the time of our volunteers and contributors as they try to determine why the user is experiencing a breakage that others aren't. It's always a frustrating outcome to eventually find it's because of the user enabling this option, either indirectly without knowing (such as a recent case of using an old version of microvm that enabled it) or directly, thinking it was well-supported and couldn't possibly be the cause of their issues.
The option name is a poor description of what it does: it can't completely remove X11 libraries from the system, since many packages include them without flags to disable them (and even if they did, it would be a game of whack-a-mole trying to ensure the overlay included all of them). And it goes beyond removing X11 in some cases, disabling other graphics-related functionality like Wayland, Vulkan, and CUPS. This is a nasty surprise for users who enable this thinking it will help them achieve a pure Wayland desktop. And users who really want to get rid of X11 end up frustrated that a package not included in this overlay still pulls it in. Both of these types of users would probably be better served by more precise overlays targeting the packages they care about.
The functionality this module provides could just as easily be provided out-of-tree, either in its own repo/flake or just copied into individual system configs. Having it in the tree makes users think it's more supported than it is and makes debugging its breakage become the responsibility of NixOS contributors. That's true of anything in nixpkgs, but because of that, we weigh the benefits of the options we provide against those costs. I firmly feel that environment.noXlibs being in nixpkgs does not give benefits to justify its cost.
Some prior issues where this has come up (though I've personally witnessed many more on Matrix that never made it to GitHub issues):

https://github.com/NixOS/nixpkgs/issues/328397
https://github.com/NixOS/nixpkgs/issues/265675

The one thing gained by having it in the tree is that someone looking to remove a package flag it overrides will likely do a search of the codebase and find that it is used by this. But that goal can just as easily be accomplished with a comment in the relevant packages, and doing so will avoid all the other problems this option introduces by its existence.
In terms of considering alternatives, I don't think this is a problem that can be solved by documentation. It's too easy to skip over and not read it. Users will still find the option in other existing configs and cargo-cult it without realising what it actually does. The most practical option to ease the burden imposed by it is to remove it.
cc @SuperSandro2000 @ElvishJerricco @emilazy @K900

Things done

Built on platform(s)

[ ] 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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[x] (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.

Probably want to remove @SuperSandro2000 from https://github.com/NixOS/nixpkgs/blob/602d8ecc45b9e6d01e972827177355f4bed4b642/.github/CODEOWNERS#L340
And I guess we should get his approval since he went through the trouble to take ownership of it. :)

The option name is a poor description of what it does: it can't completely remove X11 libraries from the system, since many packages include them without flags to disable them (and even if they did, it would be a game of whack-a-mole trying to ensure the overlay included all of them). And it goes beyond removing X11 in some cases, disabling other graphics-related functionality like Wayland, Vulkan, and CUPS.

This gave me a very good idea someone else should already had have: we are not tied to that name and we can just change it but instead of using mkRenamedOption we use mkRemovedOption and tell people about the implications and if they still want to use it and then they can make a decision for themselves.
I am going to come to with a new name and purpose a PR with that idea.

The functionality this module provides could just as easily be provided out-of-tree, either in its own repo/flake

The module code itself could very easily live out of tree but that's not even half of the story. It needs to match the pkgs being used and many PRs targeting noXlibs acompany a change in a package which must be merged in the same PR. Doing that out of tree will make this a big chore and probably so hard to maintain that it wouldn't exist for long.
Also would that solve the problem?
Do people always list all their additional flakes that they are using? Would they mention this more likely then the enabled option?
I personally think that foremost less people would use the module because it is more inconvenient to use and would probably be more often broken because of the harder maintenance.

just copied into individual system configs.

That would just duplicate effort, time and not utilize the best part about NixOS: sharing configs

Having it in the tree makes users think it's more supported than it is and makes debugging its breakage become the responsibility of NixOS contributors. That's true of anything in nixpkgs, but because of that, we weigh the benefits of the options we provide against those costs. I firmly feel that environment.noXlibs being in nixpkgs does not give benefits to justify its cost.

There are is another module in NixOS that following this would also need to be removed: the hardened profile
Just enabling it has a good chance to just break the software you are using. Also the hardened kernel it uses is known to be incompatible with many kernel modules especially out of tree.
Also we support many platforms where a wast majority of packages are broken like wasi or freebsd. I don't want to have precedence of removing things people want to keep and are actively maintaining.

In terms of considering alternatives, I don't think this is a problem that can be solved by documentation. It's too easy to skip over and not read it.

That's not an argument. If we go by this we would need to remove features like immutable users, dbus-broker, the new /etc mount or long running experiments like systemd stage 1 initrd, too. Those modules expose options which can break your system and break things in subtle ways especially if people mindlessly enable them without beforehand reading even the options description. How should we help those users?

Users will still find the option in other existing configs and cargo-cult it without realising what it actually does. The most practical option to ease the burden imposed by it is to remove it.

They can also just copy overlays which can cause the same and with your above suggestion to copy them into people personal configs and sharing them, I am afraid to tell you but I imagine this then happening more often then less.

This option is causing quite a bit of avoidable problems, and rarely what people actually want.

Then we need to match up the documentation around it to tell people what it does and what doesn't.

But this reminded me of two modules which should really be removed because they are broken and don't work as expected: onlyoffice and changedetection-io
I am going to create PRs for that if I don't forget.
Also to name another example of an option that causes quite a lot of issues lately: autologin in SDDM and none working things like kwallet.

And I guess we should get his approval since he went through the trouble to take ownership of it. :)

This PR came after a very long discussion on Matrix involving Sandro where the problems of the module and the burden it causes on users, people giving support, and maintainers for the benefit of few were discussed, unfortunately to no productive end :(

This gave me a very good idea someone else should already had have: we are not tied to that name and we can just change it but instead of using mkRenamedOption we use mkRemovedOption and tell people about the implications and if they still want to use it and then they can make a decision for themselves.

A different name and lots of warnings in the description may help, but I don’t think they will get to the root of the problem.
noXlibs reminds me of the removed gnu module: it seems to express a preference that many people might have, but when you actually dig in to what it actually does and what the consequences are, it ends up being a preference that is likely actually shared by very few among those who truly understand it. For things like this that involve many trade‐offs and inevitably end up prioritizing the wishes of the very few people who maintain them, I am not sure there is a good name that can justify keeping them in‐tree. In response to people saying that noXlibs is basically broken on Matrix, and discussion of several recent times it had broken people’s systems, you said “At least for the things I use it for it works”. But if we end up with an accurate name like environment.causeMassRebuildsByRemovingDesktopDependenciesFromSomeThingsSandroUses the absurdity of it being in the tree becomes clear…

The module code itself could very easily live out of tree but that's not even half of the story. It needs to match the pkgs being used and many PRs targeting noXlibs acompany a change in a package which must be merged in the same PR. Doing that out of tree will make this a big chore and probably so hard to maintain that it wouldn't exist for long.

Since those PRs all need review and package maintainers could have issues with or even block them, it seems like to achieve the desired end of the module it is already necessary for you to have local patches to the module and packages while waiting on that to happen. (The alternative – that package maintainers are required to accept fixes and flags for noXlibs, it acting as “leverage to get in new options for packages” as you mentioned on Matrix – just increases the burden it places on other maintainers.)
Having to overlay, patch, or include things in your Nixpkgs fork locally while waiting on PR review is a normal part of advanced NixOS usage, especially if you don’t have commit access. This argument only really works if you are self‐merging these PRs without review. I don’t think being out‐of‐tree would have a significant effect on this; everyone’s configuration depends on Nixpkgs changes to some extent.

Also would that solve the problem? Do people always list all their additional flakes that they are using? Would they mention this more likely then the enabled option?
I personally think that foremost less people would use the module because it is more inconvenient to use and would probably be more often broken because of the harder maintenance.

Fewer people using it is part of the goal here: most people who think they want noXlibs turn out to actually not want it, and the trade‐offs it actually makes in practice are sufficiently niche that it is a massive footgun. It’s also a lot easier to put effective warnings on something that is out‐of‐tree rather than directly discoverable through search.nixos.org. You rejected the idea of eval‐time warnings for noXlibs, understandably, but we have few ways of effectively informing users about in‐tree things that are not blunt instruments, sadly.

That would just duplicate effort, time and not utilize the best part about NixOS: sharing configs

Not everyone’s modules and configurations are in NixOS. That’s unsustainable. Things have to pass a threshold of non‐shooting‐self‐in‐foot usefulness to be in the tree, and those have to be weighed against the burden they place on the rest of the project in terms of maintenance and support. I realize it’s convenient for you to have it in‐tree because you’re a committer, but you can surely understand that this isn’t an adequate rebuttal to arguments about how niche the thing it actually does in practice is, and the burdens that having it in the tree places on others.

There are is another module in NixOS that following this would also need to be removed: the hardened profile
Just enabling it has a good chance to just break the software you are using. Also the hardened kernel it uses is known to be incompatible with many kernel modules especially out of tree.

As one of the listed maintainers of the hardened profile, I think it would be reasonable to remove it in its current state. I have long intended to work on improving it, but it’s currently in a bad state for both compatibility and truly enhancing security. If I was actively participating in providing support for its users that would be one thing, but if it’s causing burden on those providing support, or maintainers of packages and modules, then let’s drop it, at least until I can give it the attention it deserves and ensure that support queries are being triaged effectively.
That said, I think that it’s much more obvious that hardening your system for security will break some things than the idea that disabling graphical support would cause a trillion rebuilds, some of which inevitably fail in confusing ways.

Also we support many platforms where a wast majority of packages are broken like wasi or freebsd. I don't want to have precedence of removing things people want to keep and are actively maintaining.

Maintainership is not ownership and having a single person taking care of a niche module be a veto over a long list of enumerated harms would be toxic to the project’s health. While you might be taking care of the code side of things, nobody is really taking adequate responsibility for the support burden. https://github.com/NixOS/nixpkgs/issues/319102 and https://github.com/NixOS/nixpkgs/pull/319122 remained open for months without resolution.

Anyway, I don’t think the fact that people can break their systems with this option alone is reason to remove it. I think the fact that people can break their systems, that it expresses a set of preferences that most potential users find they don’t actually have when they run into what those preferences actually are, that the number of people who actually want what it expresses on reflection seems to be small (in the discussion we’ve so far been able to find maybe three enthusiastic users including you?), and that it imposes a burden on maintainers combined mean that it is causing more harm than good, as expressed at length by everyone who joined the discussion other than Sandro.
Honestly, though, bigger than my concerns about this specific module is that we, as a project, are simply unable to deal with situations where one person who benefits can block addressing things that are a burden on the rest of the project, in general. I don’t think that’s healthy or will lead to sustainable maintenance for the project. Oh well…

This PR came after a very long discussion on Matrix involving Sandro where the problems of the module and the burden it causes on users, people giving support, and maintainers for the benefit of few were discussed, unfortunately to no productive end :(

Which was started by a ping and afterwards immediately mentioning that a module I maintain and use should be completely removed and then downwards lecturing on me how bad, broken and terrible it is without leaving the idea open to letting me improve any aspect of it. If we want to have a productive discussion, there must be room to improve things. If the discussion is started with a made up mind and outcome, there won't be sparks of new ideas.
I've talked to a handful of people since then and got several good ideas how to improve things and make the module fit better to what it actually does.

noXlibs reminds me of the removed gnu module: it seems to express a preference that many people might have

Which was in #260570
After taking a quick look at the module it is immediately clear that the module was in no good shape. There where lots of open TODOs, it didn't have a proper commit in almost 10 years and you cannot just replace service a (like openssh) with service b (lsh).
I think it is unfair to compare noXlibs to gnu based on that.

Since those PRs all need review and package maintainers could have issues with or even block them

it acting as “leverage to get in new options for packages” as you mentioned on Matrix – just increases the burden it places on other maintainers.

So as a package maintainer I can also block required patches for musl or darwin, I am hearing about that the first time, or where is this going? Those options set by the noXlibs module are usually options which exist upstream and just get properly exposed in the nix package. No custom hacks.
Or do you want to say musl and darwin are also burden for maintainers?
I don't think that is what you are trying to say and I must probably misunderstand things.

it seems like to achieve the desired end of the module it is already necessary for you to have local patches to the module and packages while waiting on a merge.

This is just an assumption with no proof. I in fact have currently zero local overlays regarding noXlibs and I encourage everyone that still has some, to upstream them.
Since I did the last change to noXlibs I started using a few new services without any problems. Also the other nixos vms I maintain and support didn't have a regression since the 23.11 upgrade and we added several more since then.

Having to overlay, patch, or include things in your Nixpkgs fork locally while waiting on PR review is a normal part of advanced NixOS usage, especially if you don’t have commit access.

Same, I manage two https://github.com/superSandro2000/nixpkgs https://github.com/NuschtOS/nuschtpkgs/tree/backports-24.05

the trade‐offs it actually makes in practice are sufficiently niche that it is a massive footgun.

I don't think that's true. Just today I got to know that a friend was using the overlay on purpose and I haven't lobbied for it and always tell people about the drawbacks which soon is also properly reflected in the description.
I admit that the usecase is a bit niche but I am confident that there are more users out there than you think there are but they are just silent.

but we have few ways of effectively informing users about in‐tree things that are not blunt instruments, sadly.

Well, we can hack around it. We can change the option name and then make people update their configs by hand without using mkRenamedOptionModule. We also have assertions and warnings and I just got the idea in a productive discussion with a friend that we should add assertions to the module when eg. a graphical system is used.
You'll find that in code in #341909

Not everyone’s modules and configurations are in NixOS. That’s unsustainable. Things have to pass a threshold of non‐shooting‐self‐in‐foot usefulness to be in the tree, and those have to be weighed against the burden they place on the rest of the project in terms of maintenance and support.

I know and things that don't fit that are also not upstream by me but usually land in https://github.com/NuschtOS/nixos-modules

https://github.com/NixOS/nixpkgs/issues/319102 and https://github.com/NixOS/nixpkgs/pull/319122 remained open for months without resolution.

I already wanted to remove noXlibs from the minimal profile in December 2022 https://github.com/NixOS/nixpkgs/pull/205318 but when I nudged people on matrix about it, they didn't support the idea and then I forgot about it.
But we have now taken care of that and it is no longer set.

Also to clarify some things: I didn't start the module. It was initiated by 7c6f434c 15 years ago and gained overlays in https://github.com/NixOS/nixpkgs/commit/a3e6df6ee2510857a6826759a084b6d79c4f1349 to remove graphical dependencies when using NetworkManager on a server. Some 2 years ago I started to use it and contributed fixes for new services and changes in nixpkgs to it. I only added myself as codeowner in https://github.com/NixOS/nixpkgs/commit/dd1e8069ce861b13cf48ec0f7166b13eba45b139 to get pinged about new PRs since ofborg doesn't work for modules.

I agree with @ElvishJerricco and @K900 here, but I want to respond to a couple specific points:

Which was in #260570
After taking a quick look at the module it is immediately clear that the module was in no good shape. There where lots of open TODOs, it didn't have a proper commit in almost 10 years and you cannot just replace service a (like openssh) with service b (lsh).
I think it is unfair to compare noXlibs to gnu based on that.

I agree that the gnu module was in a worse state than environment.noXlibs, and that the set of preferences it expressed was even more niche. Still, I think the broad comparison I made is reasonable: that when you truly understand what it’s expressing it’s a fairly niche decision to still want to apply it to your system. There’s another, deeper similarity though: they have basically endless, open‐ended scope, and it’s impossible for them to comprehensively satisfy the preference they try to express. There’s always going to be more GNU software that could theoretically replace non‐GNU software; there is always going to be new software and modules that need graphical support stripping out; neither module can hope to ever be complete even for the subset of reasonable setups people might want to use them for in practice, and neither module could hope to avoid breaking things in confusing and hard‐to‐debug ways for end users in their attempt to satisfy those preferences. (The GNU module probably avoided much of this breakage by way of simply being incredibly ineffective at expressing its preference; environment.noXlibs isn’t so lucky.)

So as a package maintainer I can also block required patches for musl or darwin, I am hearing about that the first time, or where is this going? Those options set by the noXlibs module are usually options which exist upstream and just get properly exposed in the nix package. No custom hacks.
Or do you want to say musl and darwin are also burden for maintainers?
I don't think that is what you are trying to say and I must probably misunderstand things.

Of course Darwin and musl support are burdens on package maintainers; frequently quite significant ones. The need to balance the burdens of platform support with the benefits they bring is exactly why we had an RFC to formalize platform support in explicit tiers that delineate what is expected of maintainers for each platform. It explicitly lays out that for less‐supported platforms, fixes to packages for them can sometimes be validly rejected.
So, yes, as a project we’ve decided that Darwin should block the channels. That’s been a very controversial decision in the past, for understandable reasons, and has caused calls from maintainers to reduce the support due to the burden it places on them. Thankfully I think the maintenance situation is improving there and Randy’s upcoming SDK rework will further reduce the burden Darwin places on maintainers, but it’s clearly part of the calculus. We make this trade‐off, not because Darwin doesn’t pose a maintenance and support burden to the project, but because we have a huge number of users on macOS who benefit from the support, and the project also benefits from that support, as it brings in contributors and acts as a new user funnel for NixOS.
Similarly, musl support benefits users in large part because pkgsStatic, which has obvious utility, is based on it due to glibc’s incompatibility with full static linking. It’s more niche than Darwin, though; that’s why it’s a lower tier of platform support and has the attendant fewer expectations on maintainers and contributors. Correspondingly, much of the work to keep musl a viable platform is done by a couple of contributors. I haven’t seen musl pose much of an end‐user support burden, beyond periodically telling people “no, it’s not really viable to run a musl‐only NixOS system purely with in‐tree stuff right now”. (Maybe we should make musl and pkgsStatic a higher priority, in which case it would pose a larger burden and we’d probably need more active maintainers for it.)
So, yeah, those things are burdens. But they’re burdens we take on as a project because they bring large benefits, and that we’ve achieved some level of consensus for. Using @ElvishJerricco’s rubric, I think that if we didn’t have Darwin or musl support and they were proposed for Nixpkgs, there would be strong interest in them and they would have a good shot of making it in. There would naturally be concerns about the burden on the project, and that might influence the expected level of support. But the response I expect environment.noXlibs would receive, i.e. “this can and should just go in your own config if it matters that much to you, it’s too much of a footgun and impossible to maintain effectively in a way that doesn’t break things if it went in‐tree”, wouldn’t make any sense as a reaction for those. (We can also think about the hardened profile this way: as a general idea, I expect people would be open to it, but I suspect that it might not be added in the current state it is today given its known issues, and I am sure that user support and maintenance burden would come up in any thorough discussion of its benefits and drawbacks.)
I don’t think the fact that noXlibs is a maintenance and support burden is reason alone to remove it, but it’s necessary to take into account for any reasonable decision here. In this case, I don’t think I can summarize my personal bottom line on the matter better than I did already:

Anyway, I don’t think the fact that people can break their systems with this option alone is reason to remove it. I think the fact that people can break their systems, that it expresses a set of preferences that most potential users find they don’t actually have when they run into what those preferences actually are, that the number of people who actually want what it expresses on reflection seems to be small (in the discussion we’ve so far been able to find maybe three enthusiastic users including you?), and that it imposes a burden on maintainers combined mean that it is causing more harm than good, as expressed at length by everyone who joined the discussion other than Sandro.

I've updated to remove the CODEOWNERS, so I think this is in mergable state now.
I appreciate everyone's input on this. It seems we've reached something of a consensus here, with several committers agreeing that this should be removed. I don't think it makes sense for anyone to have an absolute veto on a shared commons like Nixpkgs, so @SuperSandro2000 would you be willing to remove your blocking review here so this can be merged?

I actively use this parameter in mine. Should I keep it or rename it?
Also this option in some cases allows me to avoid unnecessary rebuilding of xlibs.

Once this is merged, you can copy the overlays that this option used to apply into your own config. Though I would expect this option to cause you more rebuilds than it would save, since each override is forcing a cache miss.

On my system, the system is often rebuilding and doesn't always use the cache, so this setting doesn't affect that much.
Besides, this parameter is convenient to use for creating a netboot image of system, where a minimum size is required, beyond which the system may stop booting.

Feature removal without deprecation

This is not uncommon, particularly for esoteric options like this.

Assumption aware and enthusiastic users are the only ones impacted by this

Those who are unaware are exactly those who need to not use it. That's the point of removing it. Those who need it should be aware of what it does, and in that case it's reasonable for it to live out of tree.

Users are painted as new/inexperienced

No, those are simply the ones we are worried about.

The problem of bloated closure sizes and the need to reduce them seems to be mostly ignored?

Because this option does not reliably improve this problem. And it's not reasonably possible to fix this, because you can't create an exhaustive overlay encompassing all possible graphical packages.

Just a thought, why not emit a "this is unsupported, don't file bug reports with it enabled" warning on evaluating this and similar options you feel they increase the support burden too much? Maybe one could add something like config.system.build.toplevelSupportedOptionsOnly so it is easy to test if a failure is caused by an unsupported option?

The best way to communicate that an option isn't supported is to not have it in Nixpkgs in the first place. These overlays can just as easily live in individual user's configs, where they can take responsibility for whether they work or not. Or if someone would like to maintain them in a separate repository, then that gives a clear, distinct place to go asking for support. This is not an unusual thing to do for specialized overlays that would be burdensome in Nixpkgs.

So why not demand improvement instead of outright removal? One could deprecate it with a message "If you want to keep this functionality in some form please fix it before xyz deadline!".

I don't believe it is possible for this option to be improved to the point where it would be worth keeping it in Nixpkgs. So waiting around in vain waiting for it to be improved feels like a waste of contributor resources to me.

So avoid one kind of problem by not solving/reducing the problem of bloated closure sizes for who knows how many users? Users you think you know better what they want than themselves?

Nothing is stopping anyone from attempting to do this exact thing, but maintaining it outside of Nixpkgs. We have many community projects that aren't a good fit for inclusion in Nixpkgs, and this could be another one.

Would it be better if the person who blocks doesn't benefit or what are you suggesting?

The issue is not simply personally benefiting from the module. Most maintainers are users of the things they maintain, so they are motivated by being invested in its success. But maintainers need to be willing to recognize what is good for the project as a whole. If something they benefit from is detrimental to users and other contributors, they should be able to set aside their personal investment for the sake of others. Nixpkgs is a commons: a shared good that we all contribute to and benefit from. You don't get to make it worse for others just to serve your own needs.

I pretty much second what @ElvishJerricco and @mjm said, but just to add some more detail and address points they didn’t:

Do you know what percentage of the noXlibs users are new/inexperienced? How many experienced users are affected by the removal of this? So the unexpected removal of this functionality would surprise them less? I at least stumbled over this PR only by chance.

We don’t collect telemetry and don’t do detailed surveys, so it’s not really possible to answer these kinds of questions. However, expert users are precisely the ones capable of maintaining overlays like this in their own configuration, tailored to their specific needs, while as @ElvishJerricco said, it’s new and inexperienced users that disproportionately have bad experiences with it. Being most useful for experts isn’t itself a reason to remove anything, which is why it’s far from the only argument in favour of removing this module that has come up in this thread. I should note, though, that even people who have been using NixOS for years are often surprised by the problems this module causes and only fully understand its implications after running head‐first in to them.

Just a thought, why not emit a "this is unsupported, don't file bug reports with it enabled" warning on evaluating this and similar options you feel they increase the support burden too much? Maybe one could add something like config.system.build.toplevelSupportedOptionsOnly so it is easy to test if a failure is caused by an unsupported option?

Adding warnings was discussed on Matrix, but rejected by Sandro on the grounds that they create noise at evaluation time that can’t easily be suppressed. I think that, like @mjm said, rather than introducing a new tier of options that we discourage and make support conditional on not using, the messaging is a lot clearer if we let these inherently subjective and open‐ended modules be maintained out of tree. The package overlay options that this module is based on already cause a high support burden and are best wielded by experts, but in that case they also offer a high degree of power and flexibility, and it’s far more clear to users exactly what they’re opting in to. In this case, the calculus comes out a lot worse.

So why not demand improvement instead of outright removal? One could deprecate it with a message "If you want to keep this functionality in some form please fix it before xyz deadline!".

It’s not that there’s a single, well‐defined way in which it’s broken; it’s that the task it sets out to achieve is essentially unbounded and impossible to keep maintained, and that in its partial achievement of that task it will inevitably break a wide range of packages in hard‐to‐debug ways. The problem with the option is in concept, not in implementation details.

So avoid one kind of problem by not solving/reducing the problem of bloated closure sizes for who knows how many users? Users you think you know better what they want than themselves?

NixOS can’t hope to satisfy every single potential preference of its users. We have no choice but to make judgement calls about what we package, how we package it, and what options we spend time on maintaining and providing support for. We have a finite number of maintainers with a finite amount of time, and a finite number of people providing support. The hope is that we make the choices that are best for maintainers and users on the whole when all the relevant factors are taken into account. There’s no Linux distribution that doesn’t make assumptions about what is good for its target audience; even Linux From Scratch makes decisions for you.
This is also why we have more open‐ended customization mechanisms like overlays for expert users to adjust the system to their own needs and at their own risk. NixOS is far easier for end users to customize like this than most distributions, which is why this module is less than 100 lines in the first place, and does not need any support from the core of NixOS; anyone who wants exactly this set of package customizations will be able to copy it into their configuration, and anyone who isn’t satisfied by that because there might be new packages that bring in graphical dependencies is already not going to be well‐served by the current module, as discussed before. I agree with @mjm that having this module in an external flake would be a potential alternative that would ensure that the burden of maintaining and supporting it is better distributed, though in practice I suspect that even most users who would continue to use this module even after fully understanding it want slightly different things out of it, so copying and maintaining the relevant subset of it (and extending it to meet their own needs) is likely the better option for most users.
This PR does not remove any of the closure‐size‐reducing feature flags used by this module, and removing them is not my intent nor, I think, the intent of anyone else who has commented here. For packages that suffer especially badly in terms of closure size from optional graphical dependencies, there is no obstacle to them continuing to have these flags to disable them, or for new flags to be added to other packages with similar problems. Users adjusting those flags for the packages where this especially matters to them and and overlaying in a more targeted manner will break fewer things and pose less of a maintenance and support burden. It will also be more clear to users what they’re opting in to, and that they are not setting up a supported configuration of a stock Nixpkgs but instead customizing the package set to their own ends in ways that may cause unexpected problems. Being able to perform arbitrary overlays to the package set is a core strength of NixOS, but we can’t and shouldn’t maintain every single possible overlay people might want in the tree.

Accusing someone of "not answer[ing] with solid reasoning" without arguments and specifics seems kind of personal and subjective to me. Why not keep the discussion technical and on track?

There are inevitably social concerns to any decision like this as well as technical ones (hence e.g. the talk of support burden), but I agree that the discussion should remain substantive. In this case though we’re talking about a blocking review where the main response was just “I’d like to keep it”, which I think was fair to object to precisely because it is not a substantive objection.

How many user are unaware of this and would be enthusiastic if they would know? I only stumbled on this by accident and would be really surprised if this gets removed without a formal deprecation and a chance for someone to step up and address the problems.

What about other unaware committers and users? Is there no policy for this to seek to inform affected and invested users?

It’s true that we don’t have a great way to survey users or signal deprecations in ways that don’t cause spammy alert fatigue and are surfaced to users appropriately (especially through CI builds); see RFC 0127 for work on solving part of this for packages, though sadly modules are another issue. But like I said, it’s not that there is a concrete finite list of problems that need solving but that what the module does inherently creates an unbounded amount of problems. Any fix to that would involve making the module take a completely different approach to the problem, in which case of course contributions to that end would be reviewed and considered on their own merits. Thankfully, this module does not integrate deeply with the rest of NixOS (which is part of why it causes so many problems), and can easily be copied to the configurations of enthusiastic users.
Ultimately, though, as I said earlier, we can’t hope to satisfy every single preference of every single user, nor become certain of the exact impact of every single change, and we have to weigh projected benefits and downsides when making any decision like this. This PR has already received much more attention from committers, other contributors, and users than most decisions of this scale in NixOS do. I am quite confident that in this case, this PR makes the correct trade‐off in terms of our finite resources and better serving the majority of our users. Thankfully, NixOS is extremely customizable, so people don’t have to agree with us about everything to continue happily using it – they just need to be aware of what they’re getting into when they diverge from upstream, and take ownership of keeping their own adjustments working.

This is secondary to the other reasons to remove this module, but further to my point about overlays exposing a great deal of power but making it legible what you’re doing when you opt in to their drawbacks: unless I’ve missed something in my search, the only places in NixOS that set nixpkgs.overlays for you are the installation-device.nix profile, programs.ccache.packageNames, and environment.noXlibs.
The first is because of a hack that was added in a hurry recently to deal with an ISO size issue. Thankfully, it’s just one package, the profile is for a specialized use case rather than something you’d want to enable on a general NixOS system, and as Hydra builds and tests installer images, we have assurances that that overlay is always working in the context it’s designed for. Still, it would be good to get rid of it at some point, perhaps by switching to disallowedRequisites to prevent further leaks relating to that package, as was proposed in the development room on Matrix at the time due to the problems of setting an overlay like that.
programs.ccache.packageNames is an opt‐in mechanism where the user explicitly enumerates the packages they want to be in the overlay, just like nixpkgs.overlays itself. I’m not sure how widely the option is used – the fact that the example references a package that hasn’t built in years and has since been removed makes me wonder – and at the very least the documentation could definitely be better, as ccacheStdenv is impure and has a bunch of awkward trade‐offs, but it only makes sense to use this option for packages you would be compiling manually anyway, and the scope is limited to packages you list yourself. I’ve never seen a support query as a result of using this module. It has non‐trivial logic in it, so it’s less suitable for copying to downstream configurations.
environment.noXlibs is unique in being a NixOS option that overlays Nixpkgs with an opinionated set of packages and package options. We support overlaying the package set, but in basically every other case relating to it we offer mechanism, not policy, and it’s not at all standard for NixOS options to add specific overlays for you, given the significant trade‐offs involved and the impossibility of constructing non‐trivial ones that work correctly in the general case. It belongs in the realm of user configuration and opinionated downstream add‐on profiles, not in the NixOS tree.

Just for the record, I used this option for one of my deployments and would have spoken up if there had been a post about this on Discourse. I'm not an inexperienced user and I'm pretty sure I know what set of preferences this expresses.

@rhendric This was discussed at length between a number of contributors both in this thread and on Matrix. The time to speak was long ago. I think the reasons for the removal of this module are expressed clearly enough, and I think if the module was considered so valuable to some people, one of them should make an out-of-tree version.

I know the time to speak was long ago. I only commented because the news of the change, at that long-ago time, didn't reach me. And at least from the conversation visible here, it doesn't seem like much of an effort was made to seek out people who might have spoken up against it. Would have been nice to have been given a chance to speak up then, is all I'm saying.
I'm currently using Sandro's out-of-tree module. I'm not making a fuss about it.


WFLY-3901 Add support for relative-to attribute to the access log

Windows Build 1394 is now running using a merge of 2b753d1e0c2e42578bcdbea70229c5a5df870d9d

Linux Build 6287 is now running using a merge of 2b753d1e0c2e42578bcdbea70229c5a5df870d9d

Linux with security manager Build 1252 is now running using a merge of 2b753d1e0c2e42578bcdbea70229c5a5df870d9d

Linux with security manager Build 1252 outcome was SUCCESS using a merge of 2b753d1e0c2e42578bcdbea70229c5a5df870d9d
Summary: Tests passed: 823, ignored: 356 Build time: 0:04:54

Linux Build 6287 outcome was SUCCESS using a merge of 2b753d1e0c2e42578bcdbea70229c5a5df870d9d
Summary: Tests passed: 2846, ignored: 412, muted: 1 Build time: 0:47:02

Windows Build 1394 outcome was SUCCESS using a merge of 2b753d1e0c2e42578bcdbea70229c5a5df870d9d
Summary: Tests passed: 2846, ignored: 412, muted: 1 Build time: 0:47:37


Pallet logger

Can you briefly explain about this PR, Pallet logger?
Judging from the changes, they are more about treasury/deposit indexing?

Can you briefly explain about this PR, Pallet logger?
Judging from the changes, they are more about treasury/deposit indexing?

Yeah sorry it needed a description, it was just blocking Mark and I'd already explained what I'd done to him. It's a bit of a long story of dev tools and performance all mixed together!
Firstly, to index balance accurately in a previous PR I had use polkadot API to query at specific blocks (fees were hidden from transfer events, and other extrinsics produce them too). However I believed that this usage of polkadot API was causing a massive reduction in indexing speed, so I tracked down the fees (treasury.Deposit event) and indexed them, removing the polkadot API usage. It turns out that it wasn't polkadot API causing performance issues, it's the sheer quantity of data that need processing. There are issues with scale, and @markdavison and I have already discussed solutions which we'll raise in the meetings. The solution we have in mind should be future proof too.
To the initial motivation of the name of this branch though... we wanted a way to log in JSON everything related to an account (to help with research in order to pin down things like dodgy balances). The typegen side of that work (those awful long necessarily repetitive files in src/handlers/getters) was quite big though, and the more I got into it the more I realise that yes it's handy to have a processor just for dev, but it's not quite what we had in mind. So that's still a WIP, something we'll play around with as we index more pallets.
So this PR only partially addresses the logger task, but properly addresses the balance task. And the 3 big takeaways are:

Scale is now a real problem, for this we do have a solution (which has no effect on the Litentry Graph schema, it's all under the hood changes).
Typegen is tedious, it's still debatable how worth it is it. We're sticking with it for now though.
If we go ahead with our scaling solution we pretty much make the pallet logger redundant. That's why we are happy to leave it as a WIP


Difficulty synchronization is inconsistent

After switching to the randomX algorithm, the difficulty is inconsistent after a certain main block

Reason: When a rollback occurs, the system will not recalculate the seed, resulting in inconsistent seeds for the calculation difficulty of the java version and the C version after the rollback


[sil] Add a template parameter to TypeSubstCloner so that subclasses …

…can inject a SILFunctionBuilder composition class.
This works around a potential circular dependence issue where TypeSubstCloner
needs access to SILOptFunctionBuilder but is in libswiftSIL.
rdar://42301529

@swift-ci smoke test and merge

I think this didn't pick up a commit that I merged right before I kicked it off.

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge


feat(plugin-chart-pivot-table): sort by metric

Implement sorting query results by metric, descending (default) or ascending. If no sort by metric is specified, query results will be sorted by the first adhoc metric, descending (the same behaviour as in Table chart for consistency).
Testing instructions:

Create a pivot table chart
Use a saved metric or adhoc metric in "Sort by" control. I also suggest setting a low row limit (e.g. 10) to see the effect of sort by clearly.

https://user-images.githubusercontent.com/15073128/126995425-95ccfeb6-05be-4139-93e7-883eab3f59ff.mov
CC: @junlincc
closes https://github.com/apache/superset/issues/15883#issuecomment-885968829

There is a helper function to nomalize orderby. you can check this https://github.com/apache-superset/superset-ui/blob/master/packages/superset-ui-core/src/query/normalizeOrderBy.ts


[SR-11760] SwiftPM builds inside Docker do not re-use existing build artifacts

Previous ID
SR-11760

Radar
rdar://problem/73985925

Original Reporter
MrMage (JIRA User)

Type
Bug

Attachment: Download

Environment
Swift 4.2 all the way till Swift 5.2.4.

Additional Detail from JIRA

Votes
19

Component/s
Package Manager

Labels
Bug

Assignee
None

Priority
Medium

md5: 6c4efa086896ce15ed52fa119adc9b54

Issue Description:
See https://forums.swift.org/t/incremental-builds-with-swift-package-manager-and-linux-docker/26538 for a full description. @aciidb0mb3r has asked to file a Jira ticket about this issue.
My suspicion is that SwiftPM for some reason considers build artifacts in lower Docker layers stale and thinks that it needs to rebuild them.

@weissi, it looks like the hack you provided in the original JIRA ticket is gone. Could you please attach that file again?
Also is there any chance this issue will be resolved without making a switch to the BuildKit?

BuildKit with cache mount is still no full solution:
Github Actions spawn a new node with every run. The BuildKit cache folder will be deleted. It is possible to hack/cache that folder and restoring it on the new runner. But then the files have new Inodes.
IMHO there is no way around detecting code changes without Inode checks.

IMHO there is no way around detecting code changes without Inode checks.

Yes, alas, I think this is true at the moment. I couldn't immediately find a way to turn off the inode number comparisons (https://github.com/apple/swift-llbuild/blob/b7b4c5eaa798708d6233ca07908a7cab75620040/products/llbuildSwift/BuildValue.swift#L59). @dmbryson any thoughts?

@tomerd do you think you would consider a --ignore-inode-number-changes or similar option to swift build which just leaves out the inode numbers?

We have rdar://96403757 (SwiftPM - consider setting file-system: device-agnostic in build manifest) which may resolve this? I'm not sure we even need an option, I think passing device-agnostic in the llbuild manifest might be a reasonable thing to do always.

I still have this issue. Is there an approach to build it. Is the option to ignore the inode numbers added? Could somebody with more knowledge then me create some documentation on recommended setup of a swiftpm build for CI? Or does the latter exist already?

@doozMen is this issue reproducible for you with latest 5.10 development snapshots?

@doozMen is this issue reproducible for you with latest 5.10 development snapshots?

Hmm sorry I had a look at your fix in #7189  and that seams like the valid thing to do to solve the issue. But installing a development snapshot to verify this seams like something I do not have the time for right now. I would love to test it with 5.10 do.

The PR linked should address the issue in 5.10 and main development snapshots. Feel free to reopen if that's not the case.

Goodmorning to everybody,
maybe this is not related to the same issue, if so please ignore it.
I have a simple project using Vapor and I configured the cache in gitlab runner in order to preserve the build between different stages. I use swift 5.10 release and it caches correctly the package download, but it recompiles again all the dependencies.
In the discussion that you were doing here, is it something that you already considered or is this new to you?
Thanks

We are also experiencing problems with C dependencies not being properly cached from a previous build when running builds or tests in gitlab-ci for a simple Vapor app.
I set up a simple test project with pipeline here. You can see the output of a job where the build should have been cached entirely here. When producing release builds these build times naturally increase even a bit more as you can see here.
Is there any recommended way to deal with this or anything spm can do about it?

@fred-sch have you tried the cache mentioned above using RUN —mount=type=cache,target=/code/.build swift build -c release  and docker buildx build?
So far, I have not found a configuration that properly reuses cached dependency build results on GitHub CI, even though it works with local docker builds.


Focus states broken on internal header

Focus states aren't correctly displaying on internal headers, this would be an accessibility issue for users with impaired sight because there isn't enough contrast. The logo should be black with a yellow background when focused and the link should have black text with black underline when focused like other logos and links are styled.
To reproduce:
Navigate to the internal header example and focus on the ons logo or sign out link (using a full size screen)

Discuss with @Majsol


Sometimes integrate-boards requires All Orgs scope

Description
Home Point ran into a 401 error when calling integrate-boards. Changing their ADO PAT to have All Orgs scope fixed it.
However, when we tested and documented the scopes, All Orgs was not required. Why do some customers need All Orgs and others don't?

This might be from linked remote work items that span multiple Azure DevOps organizations.


[POI] POI skill give wrong result when KEYWORD entity isn't detected in LUIS.

Project

Description

User requested POI search using wrong keyword(ex. ssssss), then POI skill give wrong searched result.
To Reproduce

in Emulator
/event:{ "Name": "IPA.Location", "Value": "47.614256, -122.328301" }
Find ssssss
then POI skill provide Taylor Shelfish Farms, Homegrown and Elliot Bay Book Company by searched result.
Expected behavior

Have to return "no result"
Screenshots

Additional context

Project
Description
User requested POI search using wrong keyword(ex. ssssss), then POI skill give wrong searched result.
To Reproduce
in Emulator
/event:{ "Name": "IPA.Location", "Value": "47.614256, -122.328301" }
Find ssssss
then POI skill provide Taylor Shelfish Farms, Homegrown and Elliot Bay Book Company by searched result.
Expected behavior
Have to return "no result"
Screenshots

Additional context

Do you know what API was called with this? I am guessing the Whats Nearby scenario. In this case, we are following the logic that the user has said something that matches the POI intent and if no entities are found it looks up POIS nearby.
I think this is an issue with the POI language model as "find X" is too short and that query could easily be used for other skills as well.

Thanks for the reply! Is there any case exist "pointOfInterestList" returns null or empty?
Or it will always return some value?
For example) Find ssssss -> display poiList which names related to ssssss

In this case, it used the "find nearby" API which returns any APIs near the coordinates. The POI's None intent needs to be strengthened to prevent erroneous lookups like this.


Update ibom.css

The color was very light. This change has more contrast.

Sample of the used colors:

Track colors are light intentionally to not distract from silkscreen.
You can put your colors in user.css see customization section in wiki, I made it exactly so that everyone can style the page as they like because colors are subjective.

Yesterday I downloaded the last release (v2.3) in wiki. It is from Dez. 2019. The file ibom.py miss the user.css line and ignore the user.css. Now I work with the ibom.css local.

Yeah, to be able to use customization features you need to get latest from
master branch, it's not released yet.
On Sat, Aug 15, 2020 at 5:50 AM Christian Rank<EMAIL_ADDRESS>wrote:

Yesterday I downloaded the last release (v2.3) in wiki. It is from Dez.
2019. The file ibom.py miss the user.css line and ignore the user.css. Now
I work with the ibom.css local.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/openscopeproject/InteractiveHtmlBom/pull/174#issuecomment-674392902,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA3UNBCQX5ZTKTROMRUUMTDSA2ADBANCNFSM4QAGNKZQ
.


Looking up precedence by case number

Is it possible to look up precedence values or orders by using the case number? My ultimate goal is to check for things like, "Is multiplication higher precedence than addition?"
In Expreduce's interface to this library, it already has a mapping from Heads to case numbers for the parser:
https://github.com/corywalker/expreduce/blob/e867a0330acff2319023f17864f4c801b2daa309/expreduce/interp.go#L178

@corywalker
Not at the moment, but it can be added as some table to the generated parser. Will try to come with some implementation and let's see if it's what you're after.

@corywalker Gentle ping.


Add PEP484 type hints to Nautobot

As ...
Austin - Network Automation Engineer
I want ...
Nautobot to be type hinted and checked as per PEP484.
So that ...
I can write my apps/jobs with type hints, too, and then utilize the existing type hints from the code base.
I know this is done when...

Nautobot has type hints in the code base
Nautobot uses a type checker as part of the CI to ensure type integrity across the codebase

Optional - Feature groups this request pertains to.

[ ] Automation
[ ] Circuits
[ ] DCIM
[ ] IPAM
[ ] Misc (including Data Sources)
[ ] Organization
[ ] Plugins (and other Extensibility)
[ ] Security (Secrets, etc)
[ ] Image Management
[ ] UI/UX
[ ] Documentation
[X] Other (not directly a platform feature)

Database Changes
None
External Dependencies
A type checker. Probably mypy, since django-stubs only supports that and it is the most prevalent anyway, but we should give the others a chance (e.g. pyright but there are others).

I think adding type hints to everything exposed in the Apps API would be the best place to start.

That is also a though I had. Possibly to start even smaller just the Jobs API, allowing people to have those type hinted. Then we could have three levels:

Jobs
Apps
Nautobot as a whole

That is also a though I had. Possibly to start even smaller just the Jobs API, allowing people to have those type hinted. Then we could have three levels:

Jobs
Apps
Nautobot as a whole

Jobs 😎


Update contributors.json

Excited to get started with GITHUB
I'm a newbie
Issue
https://github.com/subeshb1/developer-community-stats/issues/68
Description
Added my profile in CONTRIBUTORS.json
Checklist

[ ] Added contributor object in ascending order in contributors.json
[ ] Github action build passing
[x] No merge conflicts

Closing this in favor of #83


[SPARK-49476][SQL][3.5][FOLLOWUP] Fix base64 proto test

What changes were proposed in this pull request?

Fix a test that is failing from backporting https://github.com/apache/spark/pull/47941
Why are the changes needed?

Fix test
Does this PR introduce any user-facing change?

No
How was this patch tested?

Fixed test
Was this patch authored or co-authored using generative AI tooling?

No

Merged to branch-3.5. Thank you @Kimahriman


RibbonLoadBalancingHttpClient#getRequestSpecificRetryHandler does not create the RequestSpecificRetryHandler with the provided IClientConfig

RibbonLoadBalancingHttpClient#getRequestSpecificRetryHandler pass null to the RequestSpecificRetryHandler and not the provided IClientConfig requestConfig:
@Override
public RequestSpecificRetryHandler getRequestSpecificRetryHandler(RibbonApacheHttpRequest request, IClientConfig requestConfig) {
	return new RequestSpecificRetryHandler(false, false, RetryHandler.DEFAULT, null);
}

Is it the expected behaviour?
Thanks

I wonder why the RibbonLoadBalancingHttpClient#getRequestSpecificRetryHandler method is different from theorg.springframework.cloud.netflix.ribbon.support.AbstractLoadBalancingClient#getRequestSpecificRetryHandler one ?

What version of Spring Cloud are you using?  We no longer use the RetryHandler in Dalston and the latest SR releases of Camden.

Hey, @ryanjbaxter, we're facing same issue, no retries for our ConnectExceptions in ZuulFilter, using Ribbon as LB. We are using Camden.SR6, and implementation is same, looks like it does not allow for any retries by default, and this is a problem.

I'm using Dalston version and I have tried to use RetryableRibbonLoadBalancingHttpClient.

@ishchenko please open a separate issue
@nithril so what is the problem specifically?  You talk about trying to pass IConfig but since we are not using RetryHandler it doesnt really matter.

I rely on ribbon native retry support (mainly because of #1878). Thus because IClientConfig requestConfig is not set, the fields retrySameServer and retryNextServer are not set.

OK I dont see any harm in passing the config.

Have you look at my question?

I wonder why the RibbonLoadBalancingHttpClient#getRequestSpecificRetryHandler method is different from the org.springframework.cloud.netflix.ribbon.support.AbstractLoadBalancingClient#getRequestSpecificRetryHandler one ?

Especially why the okToRetryOnConnectErrors and okToRetryOnAllErrors are set to false and not set according to the IClientConfig requestConfig ?
Thanks

I believe I did this because we wanted all retry operations to use spring retry and not Ribbon.

I understand for RetryableRibbonLoadBalancingHttpClient but does it make sense for RibbonLoadBalancingHttpClient ?

If my memory serves me correctly that code was added because when using Feign there was two levels or retries happening, one through Feign and the other through Ribbon.  This eliminates the Ribbon retry so only Feign is retrying requests.

Thanks for this explanation.  I have create my owns RibbonClient which override getRequestSpecificRetryHandler to enable ribbon native retry.


[Question] How can I make the cloi navigate over the seocho world?

A clear and concise description of what is your question.
I've done to run the cloisim in a docker container and display the lg_seocho.world(and other worlds too), and to run the cloisim_ros in another docker container, but the cloi has never moved.
I manipulated it with teleop_twist_keyboard but still don't know how to apply your project like README demos.
I'm working on Ubuntu 20.04

My poor cloi is standing alone on the freezing lg seocho world.
Please gimme some advice to let cloi run freely!

Sorry for late response.
cloisim_ros is just converter tool between cloisim <-> ros2.
cloisim_ros only helps to create a ros2 topic for control or reading sensor data.
Therefore, you need to bringup navigation engine separately.

Thanks for your reply.
I wanna continue this issue here: https://github.com/lge-ros2/cloisim_ros/issues/55


Standardize Filenames of Top-Level Files in FreeSWITCH-Explained and Introduction

Filename Standardization
Started the process of updating filenames. Discovered and deleted a handful of empty, broken, and/or outdated files.
Updated files

Previous filename
Updated filename

Endpoints_15696294.mdx
Endpoints.mdx

1048601.mdx
Introduction.mdx

Call-Legs_7143972.mdx
Call-Legs.mdx

15139379.mdx
Event-Types.mdx

FreeSWITCH-API_30867723.mdx
FreeSWITCH-API.mdx

Glossary_13173966.mdx
Glossary.mdx

Licensing_13173286.mdx
Licensing.mdx

Life-Cycle-of-a-Call_1048888.mdx
Life-Cycle-of-a-Call.mdx

Verto-Communicator_9633841.mdx
Verto-Communicator.mdx

Understanding-the-Configuration-Files_15696295.mdx
Understanding-the-Configuration-Files.mdx

Deleted files

File
Notes

Debian+10+Buster.mdx
Empty file linking to the Debian Installation page. Not linked by any other pages.

Audio-Formats_15696302.mdx
Empty file

Index_1048632
Broken label heatmap and space index resources from Confluence. List of labels has been added to issue #79.

Introduction-to-Dialplan_15696304.mdx
Empty file

Running-FreeSWITCH_15696307.mdx
Empty file

Begins work on #82


Feature request: scrollspy

In Jupyterlab, the content of most plugins is scrollable (command palette, notebook, welcome page).
It would be nice to have a scrollspy feature in order to enable a top border or a shadow when the content is scrolled.
Cf jupyter.org screenshot below:

Is there something in Phosphor preventing you from doing this now in your own code, or are you just asking for a convenience API?

The jquery code for the jupyter.org is rather simple. I guess
$(window).on("scroll", function() {
    if($(this).scrollTop()>0){
        $(".navbar").addClass("navbar-scroll");
    } else {
        $(".navbar").removeClass("navbar-scroll");
    }
});
```

I wanted to add something like this (without jqeury) to the about plugin an realized it is a more general thing than this specific plugin. Would this be a phosphor-level thing?

Or I guess it is fine to add it for each plugin...

That jquery is nothing special. Here's a non-jq version:
widget.node.addEventListener('scroll', () => {
  widget.addClass('thing', widget.node.scrollTop > 0);
});

I don't think we need a function in Phosphor for that simple line.


Print old/new album size when prompting to replace

Currently when beets is asked to import an album that is already in the library it prints the # of tracks, bitrate, etc of the old and the new album:
Old: 13 items, MP3, 256kbps, 44:32
New: 13 items, MP3, 320kbps, 44:31

It would be nice if beets could also print the total file size along with this information e.g:
Old: 13 items, MP3, 256kbps, 44:32, 101MB
New: 13 items, MP3, 320kbps, 44:31, 128MB

OK!


How to skip publish specific binaries?

I have some internal utility binaries and I don't want to publish them. How can I configure this manner?
Is package.publish = false enough?

https://opensource.axo.dev/cargo-dist/book/reference/config.html#publish


Date: Thu Dec  8 11:23:12 UTC 2022

Subject: [PATCH] uspot - Setting up appropriate terminate cause and removal of invalid terminate cause value
Signed-off-by: Sohail Ahmad<EMAIL_ADDRESS>

@mdsohailahmad please fix the title of this PR. And this cannot go to main. It needs to go to next.


Create light saber controller (and potentially application)

Basic saber controller and application present. Special effects later, as time allows.


Use OpenDAL to access object store

Describe This Problem
OpenDAL is widely adopted in Rust community to access files in many backends, such as S3, OSS, etc...
By integrate with it, we can gain more features from community.
Proposal
Replace AliyunOSS implementation with OpenDAL

https://github.com/CeresDB/ceresdb/blob/main/components/object_store/src/aliyun.rs#L93

Additional Context
No response

FWIW DataFusion has first party support for object_store, which is part of the Apache Arrow project. Just thought I would mention it

@tustvold We already use object_store in our codebase, opendal here is meant to implement object_store trait for aliyun OSS.

I think aliyun OSS might be supported by object_store natively - https://github.com/apache/arrow-rs/issues/2777

That sounds reasonable to me, we will try implement OSS directly in object_store.


Panic when passing a specific gif

I've been playing with the latest version of go-thumbhash. I've found one specific image that makes the library panic. This image is a gif, we can't reproduce this consistenly as this library was able to process other gifs. Does this library supports gifs? It is unclear from the readme which image types are supported.
Minimal repro
$ go run . ~/Downloads/blob.gif
panic: runtime error: index out of range [889171] with length 889168

goroutine 1 [running]:
github.com/galdor/go-thumbhash.EncodeImage({0x10463d5f8, 0x1400007e240})
        /Users/aymericbeaumet/go/pkg/mod/github.com/galdor/go-thumbhash@v1.0.0/thumbhash.go:36 +0x61c
main.main()
        /Users/aymericbeaumet/Workspace/aymericbeaumet/thumbhash-panic/main.go:25 +0x68
exit status 2

package main

import (
	"image"
	_ "image/gif"  // add gif support
	_ "image/jpeg" // add jpeg support
	_ "image/png"  // add png support
	"os"

	"github.com/galdor/go-thumbhash"
)

func main() {
	reader, err := os.Open(os.Args[1])
	if err != nil {
		panic(err)
	}

	var img image.Image
	img, _, err = image.Decode(reader)
	if err != nil {
		panic(err)
	}

	_ = thumbhash.EncodeImage(img) // panics
}

Can you reproduce that with master?

Using the latest master fixed the issue (command below) thank you! Would you recommend using master instead of v1.0.0, if should we bump a minor version?
go get https://github.com/galdor/go-thumbhash@5f40e920ff450b03da9e7a9875a452806fa89fe0


Mobile menu z-index is off

Describe the bug
The mobile menu is covered by elements on the Developers#show page.
To Reproduce
Steps to reproduce the behavior:

Visit any developer page (e.g. https://www.railsdevs.io/developers/1) on mobile
Open the menu
See the avatar and hero covering the mobile menu

Expected behavior
The mobile menu should be on top of everything.
Screenshots

Hi @joemasilotti, I'd like to work on this.

Awesome! Go for it @Blaise-Shyaka.

Closed via #112.


net: malformed payload of UDP packets on Mac

Go version: go1.10.3 darwin/amd64
Does this issue reproduce with the latest release? Yes
OS and architecture: darwin/amd64 (OS High Sierra 10.13.3)
What did you do?
Listened to SIP communciation on UDP.
Code: https://play.golang.org/p/fqTQEMb70Is (naturally, needs to be run locally)
What did you expect to see?
Correct SIP Invite packet arriving every second, or so.
First 16 characters of a correct SIP Invite:
 00000000  49 4e 56 49 54 45 20 73  69 70 3a 31 34 35 36 40  |INVITE sip:1456@|
What did you see instead?
First 4 character of some packets are malformed. Namely, the "INVI" was overwritten with two CRLF.
Initially, about 30% of the packets have the issue but the longer the server executes, the higher part of the whole they constitute. First 16 characters of a malformed packet:
 00000000  0d 0a 0d 0a 54 45 20 73  69 70 3a 31 34 35 36 40  |....TE sip:1456@|

Rests of the packets look good.
Wireshark confirmed, that the anomaly is not on sender's side.
The double CRLF is always present later in the packet at position 239 (hex).
This behavior occurs when using Read/ReadFrom/ReadFromUDP
Example of sent data: https://pastebin.com/bzguwfYY
Doesn't happen when a new buffer is allocated for every call to Read(). (That gives me some empty packets, but does not look like any of the actually send messages has been lost.)

cc @mikioh

You need to deal with the number of bytes received appropriately like the following:
b := make([]byte, 2048)
for {
	n, err := c.Read(b)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Printf("%s", b[:n])

For more questions, please take a look at https://github.com/golang/go/wiki/Questions.

@mikioh example clarification: Shouldn't that print come before the error check?
b := make([]byte, 2048)
for {
	n, err := c.Read(b)
	fmt.Printf("%s", b[:n])
	if err != nil {
		fmt.Println(err)
		return
	}

go doc io.Reader

Callers should always process the n > 0 bytes returned before considering
the error err. Doing so correctly handles I/O errors that happen after
reading some bytes and also both of the allowed EOF behaviors.


You are my hero.
People don't fully UNDERSTAND the value of working vertically, and I didn't either until Tab Trees made it easy.
Some input?

Tab Tree never figured out a way the user could rename the label of the bookmark. It looks like Vertical Tabs can't either? Yet?
Maybe more outline structure like "tab outliner" and "tab tree" where we can stack and store them is coming?
Folders or containers?

THank you so much - I hope this is a first step - I would be more than happy to pay for this!
Anthony Florio

The creator of Vertical Tabs is attempting to implement a layout mode & behavior through an extension which should be part of the browser's core functionality:
Vertical tabs should be a native feature of Chrome because there is no other practical way to display complete page titles on Chrome while working in the same window.  The absence of this feature is a mystery indeed -- it just makes no sense for a browser to conceal page titles from the user.
It is a sad commentary on the depraved state of software engineering when common-sense user interface design principles are regarded by the public as super-human and god-like: ease of use and intuitive functionality should be expected, not surprising.  (Especially from a company like Google with virtually unlimited resources.)  So I would really like to hear the managers of the Chromium project explain these deficiencies:
What is their excuse for not integrating Vertical Tabs and Auto Tab Discard functionality directly into the core application?  Can we convince them to correct this mistake?  Are there any pull requests for this which have been rejected?  If yes, then why?  If the Chromium team will not implement vertical tabs in the browser, can we deploy this feature through Brave?
There is no other browser issue which affects a greater number of users, so why is this being ignored year after year?  It seems like some kind of mass hypnosis or collective insanity, that we must tolerate a difficult user interface in Chrome when there is no technical reason for the problem to exist -- it is simply a case of bad design.  The Vertical Tabs extension is an acceptable patch for a broken system, but in the future a desktop browser without support for vertical tabs will be regarded by the public as useless -- just like the first generation web browsers (which had no integrated support for tabs.)

+1
BTW: Microsoft Edge has the Vertical Tabs built-in already.
https://www.theverge.com/2021/3/4/22313433/microsoft-edge-vertical-tabs-startup-boost-features

Very interesting... 'The Verge' seems to have good coverage of web browser development but the browser news articles are not grouped together - they are all filed under separate company names where I would never see them.  I also noticed that Microsoft has implemented Auto Tab Discard:
Edge will now automatically release system resources for inactive tabs
https://www.theverge.com/2021/1/21/22242622/microsoft-edge-new-themes-icons-sleeping-tabs-feature
We can only pray that this kind of competition will convince Google to implement the same features.


xterm.js addon

Since version 4.0.0, xterm.js no longer includes a terminado addon (https://github.com/xtermjs/xterm.js/issues/2143):

Note that the zmodem and terminado addons we will not provide alternatives for, instead relying on the greater community/domain experts to develop equivalent addons.

I guess this means that for terminado to support xterm.js 4.0.0 upwards, there needs to be a new xtermjs-addon-terminado.

There's some discussion in https://github.com/xtermjs/xterm.js/issues/2440 about this.

Is there a standard protocol for how xterm.js expects to talk to a server? If so, maybe we could adapt terminado to use that rather than the custom protocol it has for historic reasons.


UI reorganized and options

UI files reorganized, added 1.18 panorama (using boxgeo), added some keybinds, added options to settings screen (mouse sensitivity x/y, chat width/height, sound (ui), render distance, fov and gui scale sliders), added food and xp bars and more debug info (dimension, biome, day, light, number of entities) and playerlist will have columns of 10 players each.

big code change but overall it looks ok
anyone want to try it out to make sure everything works?

Tested some basic use and it seems to work pretty well, 👍
There are some regressions on mobile but I don't think that was a big priority. Looks like the test server is also broken.

Let's go

CI failed https://github.com/PrismarineJS/prismarine-web-client/runs/4626600275?check_suite_focus=true
Can you have a look @KalmeMarq ?

sure. I'll see what's going on.

rom, I think we have a problem. because "npm run build" works for me.

In that terminal it mentions that a node_modules was not found. Maybe that's the reason.

@KalmeMarq can you retry the same using the current master branch?
I think you're missing some recent commits in your local setup

I'm using the master branch and with it I did "git fetch upstream", "git merge upstream/master master" and "git rebase upstream/master". It works.

I deleted node_modules and run "npm install" && "npm run build". Now I got the same log as you. I'm using v17.2.0. I don't know if the node version is the issue.

I doubt it's a node version issue
CI is using node 14

I'm going to run "npm run build" again. If it gets the same issue. I'll redo the "npm i" and build. Failing again I'll add the --ignore-engines flag when doing "npm i". If the build works then I think it's the node version. (if this logic makes sense :/)

I think there is an issue with either package.json either webpack config. It should be fixed
The first run of npm install && npm run build from a new environment need to work.
Rerunning thèse commands multiple times is not a solution

package.json wasn't changed nor webpack config

the "url" and "querystring" modules aren't being installed with "npm i"

when I install them manually it finally works. This is now something I don't know any about.

Probably add them in package.json then
This might have been caused by updates in dependencies


[System Request] for support of D% from Call of Cthulhu 7e

CoC is using D% die instead of d100 which contain 1dT(10,20..) and 1d10(1-9).

Right now Dice Stats is seeing those rolls as 2d10, but it should be d100

Would be great to add support for this die

Interesting. Will prob have to make a special parser for CoC then so might take a bit.

Interesting. Will prob have to make a special parser for CoC then so might take a bit.

Please take all the time you need, I'm looking forward to this feature. Meanwhile will do some translations I guess.

Are there any sort of advantage or disadvantage style mechanics that have you roll more of a specific type of die and take the better or worse result?
Trying to come up with a good way to see if the roll is a d100 roll. Looking like ill need to convert the formula but if for some reason its not the form of '1dt +1d10' it would cause problems. Wondering if that roll formula would change for some reason and what it might change too. (Sorry not a CoC player)

Are there any sort of advantage or disadvantage style mechanics that have you roll more of a specific type of die and take the better or worse result?

Yeah, there are several advantages\disadvantages:

Basic Adv\disAdv - just add up to 2 more dt, so i.e. you roll 2dt 1d10 to see the %
you can add % to your skill value (does not impact dice)
I'm not sure how exactly it works but I guess it's similar one above but you add value to the roll itself.

Haven't seen any possibilities to change roll output, will check it later

So looking through the chat message it appears to select a die value before the message is created. There's not an easy way for me to know what of the dice are picked for the final result if they roll multiple dt's. Looks like the system selects the die to use before making the chat card.
Ill need to submit something with the system developer to have an easy way to aquire the actual roll result otherwise the data just looks something like this giving values way over 100.

For now it would be great just to have statistics of of dt and d10 under d% tab and the data of successes (regular, hard extrim, crit) and failures/fumbles.
Due to how d% works in coc I think it would be pretty much it

Ususaly I try to chart the raw roll values from the dice not including modifiers but I can't easily do that for CoC until the system provides some update to how then generate chat messages. (I submitted a bug report but don't expect it to be a high priority)
Because of how they make the message I also cant easily get the degree success but might have a work around.
I have 2 solutions I could implement in the meantime for graphing the result:
1.) I can either graph the raw roll values but if you roll multiple dt it will always take the last dt value rolled
or
2.) I can graph the result from the roll. But if anyone has a flat bonus or any other way to add values on top of the dice roll it will include that to the graphed value. EX: /r 1dt + 1d10 +5 + 1d7 would add the 5 and d7 to the result and graph the outcome rather than just the die roll.  (Any roll over 100 would be ignored)

Second one sounds good, at least to me. Btw can Dice so nice! help with it? Almost all the games are using it, so while we are waiting for the fix maybe you can use it?

So Dice so Nice wont really help. All those modules use the dice values from the roll. I can get the dice values fine. The way they designed the system has it calculate the selected dice and degree success before it makes the message.
They add all the dice values to the message but the formula isn't right.
The system should use a [ ( Xdtkh or Xdtkl ) + 1d10 ] formaula but the message instead has a (1dt + 1dt + 1dt + 1d10) formula so the result and any outcome from the data is always some big number. They make the chat message and fill in that data wrong on the System side before the message is created and I access it.
I made a release that takes the final result with the not handling modifiers solution if you wan't to try it. Release should be 1.20.0 It is only v12 supported as im not dealing with later versions for now.

Yeah you can parse the html if you want and save the data that way. I started a CoC7e system parser and that’s how I’m getting the total rn.
So parsing the html would go there if you want to take a look and are feel adventurous. I’d look at the pf2e system message parser and the generic parser for ideas on how to set it up.
using css classes is always a bit risky just from them changing so often and would rather wait for a system implement to spend time on it. But feel free to give it a shot.
I also have plans to refactor how I’m making tabs to make them system specific instead of available to every system. And have a “system stats (charts) tab & system info (rolls data ex hits misses fails in table form)” so wasn’t trying to go crazy with UI stuff.
I’ll probably make a new issue with the new scope in mind.

Looks like CoC added the new feature and its in the develop branch. Might be able to get this done soon

Awesome! Thank you for letting me know


mobile: Implement setLogger in the C++ API

Implement a setLogger in the C++ EngineBuilder API. This is to allow delegating the Envoy logger into a different logging implementation depending on the platform. This change also aims to make the C++ API more consistent with other language APIs.
Risk Level: low (new function)
Testing: unit test
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: mobile

/assign @abeyad


New plugin name requirements

Hi @dellermann
Per our developer policies,
please ensure that your plugin's name does not include the word "Obsidian".
In addition, the plugin name should not include the word "Plugin", as that is unecessary duplication.
We have already modified the name of your plugin to "Console Markdown" in our records.
To maintain compliance, take the following actions:

Modify the manifest.json file in your plugin repository.
Generate a new release for your plugin to ensure users download the updated manifest.

If you have a idea for a different plugin name, you may also submit a pull request to the obsidianmd/obsidian-releases repository.
Thank you for your cooperation.
— the Obsidian team

My plugin doesn't contain "Obsidian" in its name. Would you please check this request?


Fix invalid read inside mqtt/Client

Fixes, #66
Needed a hot-fix for my application. So submitting this PR.
I have internally tested that this fix will remove the invalid read issue as described above.

Hi @shekharhimanshu ,
Great timing, I just tested the scenario you stated in #66 and confirmed that it does show up in valgrind.
I will get this pull request into our local repository and run it through our internal tests and merge with master after that.
Thanks a lot!
Varun


combineReducers with no reducers passed

Is it possible for combineReducers to produce a valid output instead of an error without any reducers passed to it?
I'm currently working on a new project and I want to get a basic setup without any reducers (as there is currently no data, I'm just hooking in Redux to a mocked-up HTML page) and I thought calling this with no reducers would produce an empty reducer.
Instead I got this error message:
Store does not have a valid reducer. Make sure the argument passed to combineReducers is an object whose values are reducers.

Can we make an exception for when an object is passed that is empty? Maybe there's something I'm missing, and this is a bit of an edge case, but I wanted to get some thoughts before maybe hacking on this.

I was able to add this to my application code to make it work:
const rootReducer = combineReducers({
  blank: function(state, action) {if (state == null) state = [] return state;}
});

While this got things working perfectly, I think it would be a minor improvement to have it work with no errors without having to define a blank reducer.

There is no need to call combineReducers if you are not going to pass in any reducers. It just returns a simple reducer, not a special type of reducer. Any place where you would use combineReducers, you can just use and identity function state => state

const store = createStore(state => state);

In fact even no-op will work because the sanity checks are only done in combineReducers().
const store = createStore(() => {});

Oh I see. That makes sense. Thank you.

for old composeWithDevTools and Thunk users:
const store = createStore(() => composeWithDevTools(applyMiddleware(thunk.withExtraArgument())));

@eddskt not sure why you left this on an issue that's over 8 years old :)
note that we really don't want people using createStore directly today, and instead you should be using RTK's configureStore.
In this case, you could do:
const store = configureStore({
  reducer: {}
})


Integrated terminal in vscode doesn't recognise dotnet

Problem encountered on https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/install
Operating System: windows
You'll find an image, attached to this post, which shows that dotnet is installed, but the integrated terminal in vscode doesn't pick up on it. I also tried using an external terminal for vscode and got the same result.
VS Code couldn't find .NET

Did you start new instance of vscode?
I assume this is more question for vscode terminal feature and how it picks up path settingsbfrom OS.

Ok, got it. Restarting vscode didn't fix it, but restarting my laptop did... Thanks


Access to the site by its index

Now, to get access to a separate site by its index, you need to either make a separate array sorted by site indexes, or use a chart search.
Maybe there are other ways that I can't see?

I create an array where each entry is the index of the site with that site->index. A reverse lookup to "restore order".
	uint32_t* restore_order = new uint32_t[my_diagram.numsites];
	std::memset(restore_order, 0, my_diagram.numsites * sizeof(uint32_t));
	{
		const jcv_site* sites = jcv_diagram_get_sites(&my_diagram);
		for (int i = 0; i < my_diagram.numsites; ++i)
		{
			const jcv_site* site = &sites[i];
			restore_order[site->index] = i;
		}
	}


Update UI

Only visual update. No functional changes so just check that everything works as it normally does. 😄

I've noticed that each component is the whole screen size (they were looking way blurrier than previous ui), that makes the ui components have low res from the get go and its super inefficient for render. Blocking untill we figure it out with artists.

Update on this, having full screen image doesnt make it look blurry just less efficient, the thing is that we need them to have, more resolution. We'll try upscaling them to see if there is a difference

I have another branch with the upscaled images, closing this one thanks for ur work


AttributeError: 'list' object has no attribute 'get'

No config file found for chineseβmalelikeness. You can generate it in the LoRA tab.
No config file found for ClothingAdjuster3. You can generate it in the LoRA tab.
No config file found for sd_xl_offset_example-lora_1.0. You can generate it in the LoRA tab.
No config file found for edgFuturisticXL. You can generate it in the LoRA tab.
No config file found for PrgXL_V1. You can generate it in the LoRA tab.
No config file found for ArienDragonGirlV1-SDXL. You can generate it in the LoRA tab.
*** Error executing callback ui_tabs_callback for J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\scripts\trt.py
Traceback (most recent call last):
File "J:\StableDiffusion\sdwebui\modules\script_callbacks.py", line 166, in ui_tabs_callback
res += c.callback() or []
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 682, in on_ui_tabs
elem_id=f"trt_profiles_markdown", value=get_trt_profiles_markdown()
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 657, in get_trt_profiles_markdown
engine_cards, lora_cards = engine_profile_card()
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 370, in engine_profile_card
s_min, s_opt, s_max = m["config"].profile.get(
AttributeError: 'list' object has no attribute 'get'

Win11，SD1.7.0, PYTHON 3.10.11,rtx4090

cuda11.8+xformers0.0.23.post1+torch2.1.2

https://github.com/NVIDIA/Stable-Diffusion-WebUI-TensorRT/commit/4c2bcafd854f7bc74d3ca9c5c3c90112e9fe6e55
I returned to this earlier version and it ran normally, but the version on January 5, 2024 did not run. The above error occurred, indicating that there is indeed a problem with the updated version.

4c2bcaf I returned to this earlier version and it ran normally, but the version on January 5, 2024 did not run. The above error occurred, indicating that there is indeed a problem with the updated version.

im having the same issues as well, i append the error callback response here:
`*** Error executing callback ui_tabs_callback for Y:\StableDiffusion\stabilityMatrix\Packages\Stable Diffusion WebUI\extensions\Stable-Diffusion-WebUI-TensorRT\scripts\trt.py
Traceback (most recent call last):
File "Y:\StableDiffusion\stabilityMatrix\Packages\Stable Diffusion WebUI\modules\script_callbacks.py", line 166, in ui_tabs_callback
res += c.callback() or []
File "Y:\StableDiffusion\stabilityMatrix\Packages\Stable Diffusion WebUI\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 682, in on_ui_tabs
elem_id=f"trt_profiles_markdown", value=get_trt_profiles_markdown()
File "Y:\StableDiffusion\stabilityMatrix\Packages\Stable Diffusion WebUI\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 657, in get_trt_profiles_markdown
engine_cards, lora_cards = engine_profile_card()
File "Y:\StableDiffusion\stabilityMatrix\Packages\Stable Diffusion WebUI\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 370, in engine_profile_card
s_min, s_opt, s_max = m["config"].profile.get(
AttributeError: 'list' object has no attribute 'get'
---`
i have reinstalled manually using this tutorial as well and same issues happen: https://github.com/NVIDIA/Stable-Diffusion-WebUI-TensorRT/issues/27#issuecomment-1767570566

I have figured it out.
Delete your Unet-onnx and Unet-trt folders... that fixed the issue. i have backed up all the files and i will restore them after running the new set of instructions inside the Tensor RT tab. Will post findings afterwards.

ok, i successfully migrated my backup of the dev branch models into the stable 0.2.0 version.
Changes have been made to the models.json file inside "Unet-trt", it no longer has the lora information inside of it, instead it opts for reading all ".lora" files inside the directory. i assume that the old ".trt" files for the lora engines just got an extension rename into ".lora", so they might just need an extension rename.
So to properly fix this issue, one needs to edit the old models.json file to remove all lora keys/data from it. afterwards it will load fine, but have its lora missing, for that just renaming the extension of all loras from trt to .lora should fix it.

*** Error loading script: trt.py
Traceback (most recent call last):
File "J:\StableDiffusion\sdwebui\modules\scripts.py", line 469, in load_scripts
script_module = script_loading.load_module(scriptfile.path)
File "J:\StableDiffusion\sdwebui\modules\script_loading.py", line 10, in load_module
module_spec.loader.exec_module(module)
File "", line 883, in exec_module
File "", line 241, in call_with_frames_removed
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\scripts\trt.py", line 13, in
import ui_trt
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\ui_trt.py", line 19, in
from model_manager import modelmanager, cc_major, TRT_MODEL_DIR
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\model_manager.py", line 237, in
modelmanager = ModelManager()
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\model_manager.py", line 41, in init
self.all_models = self.read_json()
File "J:\StableDiffusion\sdwebui\extensions\Stable-Diffusion-WebUI-TensorRT\model_manager.py", line 161, in read_json
out = json.load(f)
File "json_init.py", line 293, in load
File "json_init_.py", line 346, in loads
File "json\decoder.py", line 337, in decode
File "json\decoder.py", line 353, in raw_decode
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 195 column 5 (char 6676)

No config file found for MechaGirl_v1. You can generate it in the LoRA tab.
No config file found for ruirui2700. You can generate it in the LoRA tab.
No config file found for chineseβmalelikeness3. You can generate it in the LoRA tab.
No config file found for chineseβmalelikeness. You can generate it in the LoRA tab.
No config file found for ClothingAdjuster3. You can generate it in the LoRA tab.
No config file found for sd_xl_offset_example-lora_1.0. You can generate it in the LoRA tab.
No config file found for edgFuturisticXL. You can generate it in the LoRA tab.
No config file found for PrgXL_V1. You can generate it in the LoRA tab.
No config file found for ArienDragonGirlV1-SDXL. You can generate it in the LoRA tab.

Thanks. After deleting the Lora configuration data in json, you can run the latest 0.2.0 extension, but there is still a  reminder to detect all lora files in the original model folder and convert them into trt.

No config file found for MechaGirl_v1. You can generate it in the LoRA tab.找不到 MechaGirl_v1 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for ruirui2700. You can generate it in the LoRA tab.未找到 ruirui2700 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for chineseβmalelikeness3. You can generate it in the LoRA tab. 找不到 chineseβmalelikeness3 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for chineseβmalelikeness. You can generate it in the LoRA tab. 未找到 chineseβmalelikeness 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for ClothingAdjuster3. You can generate it in the LoRA tab. 找不到 ClothingAdjuster3 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for sd_xl_offset_example-lora_1.0. You can generate it in the LoRA tab. 找不到 sd_xl_offset_example-lora_1.0 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for edgFuturisticXL. You can generate it in the LoRA tab. 找不到 edgFuturisticXL 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for PrgXL_V1. You can generate it in the LoRA tab. 找不到 PrgXL_V1 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for ArienDragonGirlV1-SDXL. You can generate it in the LoRA tab. 未找到 ArienDragonGirlV1-SDXL 的配置文件。您可以在 LoRA 选项卡中生成它。

Thanks. After deleting the Lora configuration data in json, you can run the latest 0.2.0 extension, but there is still a reminder to detect all lora files in the original model folder and convert them into trt.

No config file found for MechaGirl_v1. You can generate it in the LoRA tab.找不到 MechaGirl_v1 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for ruirui2700. You can generate it in the LoRA tab.未找到 ruirui2700 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for chineseβmalelikeness3. You can generate it in the LoRA tab. 找不到 chineseβmalelikeness3 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for chineseβmalelikeness. You can generate it in the LoRA tab. 未找到 chineseβmalelikeness 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for ClothingAdjuster3. You can generate it in the LoRA tab. 找不到 ClothingAdjuster3 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for sd_xl_offset_example-lora_1.0. You can generate it in the LoRA tab. 找不到 sd_xl_offset_example-lora_1.0 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for edgFuturisticXL. You can generate it in the LoRA tab. 找不到 edgFuturisticXL 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for PrgXL_V1. You can generate it in the LoRA tab. 找不到 PrgXL_V1 的配置文件。您可以在 LoRA 选项卡中生成它。 No config file found for ArienDragonGirlV1-SDXL. You can generate it in the LoRA tab. 未找到 ArienDragonGirlV1-SDXL 的配置文件。您可以在 LoRA 选项卡中生成它。

that is because the lora file name has to match with the list it gave you in the traceback log.
Example: MechaGirl_v1 has to be named "MechaGirl_v1.lora", its case-sensitive.


Channel Error

[ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: MissingPluginException(No implementation found for method openwhatsapp on channel com.whatsapp.chat/openwhatsapp)

Hi Baxter92,
The channel com.whatsapp.chat/openwhatsapp is from the example in receive_whatsapp_chat plugin, it is not part of the plugin.
First of all, to add the feature to open whatsapp (calling the channel above), you will need to copy the code in example/android/app/main/java/.../MainActivity.java into your MainActivity.java.
Secondly, you will do add queries for the package com.whatsapp in your android/app/src/main/AndroidManifest.xml. See example.
Best,
Dolev.


Check remove_selected

Description
While working on #3625 I realized that we were missing a proper check to make sure that removing a selection of points correctly removes the attributes at the corresponding index. This PR adds a test for that.
In doing so, I noticed that edge_width does not allow setting an array, despite vispy using an attribute, so I created #3995.
Does a test like this make sense? Am I missing anything?

Type of change

[ ] Bug-fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

Note that this should be updated when merging #3625 .

Self reminder to update this if/when #3625 and #3999 are merged!


Allow bad tags

Closes https://github.com/jch/html-pipeline/issues/321.

This is out now as 2.12.2.