text:
Fix test failures for WFLY-12019 to add a undertow handler for created location

Issue: https://issues.redhat.com/browse/WFLY-12019
This PR tires to fix the test failures in CI that using profiles: ts.standalone.microprofile, ts.layers, ts.bootable, which do not have /subsystem=undertow/configuraiton=handler/file=welcome-content in the server configuration, that is why it failed when creating the location resource for a host.
The solution is trying to create a /subsystem=undertow/configuraiton=handler/file=welcome and remove it after test.

Thanks, @gaol. I merged this into my branch locally, and then rebased to squash this into your previous commit. I've pushed that.

authors: bstansberry gaol

repo: bstansberry/wildfly


text:
Unable to send lightning payment

Same as #124 but that issue was closed. I was aware of the fee and tried sending a lower amount, I tried sending 50 sats which should have enough room for the fee but the 'Ok' button is still disabled.

Can you share or create an invoice which is causing this?

I figured out what the issue is after further testing:
If you scan an invoice for an amount over your spendable amount and then lower the sat amount to an amount that will work, the 'Ok' button still will be disabled even though you are now sending an acceptable amount. It is still using the disable button because the original invoice is over your limit.
If that makes sense?

It is still using the disable button because the original invoice is over your limit.

Yes, it does. This is an expected behavior since a payment of amount which is lower than requested would be rejected by receiver anyway (according to LN protocol convention).
What will work here is SPLIT button which allows two or more wallets to pay to the same invoice in parts.

Ok sounds good, I didn't know this was expected behavior. Thanks for letting me know, will close now.

source: gharchive/issue

repo: btcontract/wallet

license_type: permissive

license_source: bigquery


text:
Let code wrap in tables-in-notes.

Replacement for https://github.com/tc39/ecma262/pull/1844. Resolves https://github.com/tc39/ecma262/issues/1843.
To repeat my earlier argument here for good measure:

[This] should only apply when we've actually run out of width to work with, and has the nice benefit of being responsive if your window is a bit too narrow.

We don't actually need to restrict this to tables-in-notes but it currently suffices to do so.

I don't see why we should restrict it to notes. It may save us from having to address this again in the future, and it doesn't hurt the rendering currently, right?

@michaelficarra I agree—@ljharb, would you be okay with this?

On premise it seems fine; it'd be good to see if there's any actual rendering differences.

Looking through all of the tables currently in ECMA-262, the only one that's not in a note that's affected by this is Table 42, and just when responding to a restricted viewport width:

This feels pretty positive to me.

source: gharchive/pull-request

authors: ljharb michaelficarra rkirsling

repo: bterlson/ecmarkup

license: MIT

license_source: github-api


text:
Operation not allowed error, Permission Denied

I'm trying to install this on my mac but i keep getting operation not allowed, even when i use run it with sudo. maybe i'm doing something wrong.

I had the same problem and solved it by going into the temp directory created by the shell script and moving it manually using the mv command
sudo mv git-rbs /usr/local/bin/
But the git r command doesn't work only git-rbs command works

authors: dawkaka iamkarsoft

repo: bubunyo/git-rbs


text:
ObjectId supports data mode

In view of the current root-state container mode, there are two formats, Map and Set, but the value is object_id, and the corresponding object needs to be stored in the local NOC. However, in many cases, the value may be just some simple information that is not long. Therefore, having to map objects will make the operation cumbersome and reduce performance, so consider introducing object_id itself to encode custom information
Currently ObjectId is an array of 32bytes in length, which defines three types:
pub const OBJECT_ID_STANDARD: u8 = 0b_00000001;
pub const OBJECT_ID_CORE: u8 = 0b_00000010;
pub const OBJECT_ID_DEC_APP: u8 = 0b_00000011;
The type occupies the highest two bits of the first byte, and a type with all zeros is left, which can be used as a related type of custom data. The design is as follows:
The highest bit of the first byte of ObjectId is 00, the remaining 6 bits are reserved, and the remaining 31 bytes are used to store any custom data

The highest byte of the ObjectId, the first two bits are 0 to indicate the Data mode, and the remaining 6 bits indicate the length of the data, which supports a maximum of 31 bytes

The 31 bytes except the highest byte of ObjectId are used to store custom data

ObjectCategory adds Data type, you can use object_id.category() to judge whether it is Data mode

Use ObjectIdDataBuilder to construct an ObjectId in Data mode

ObjectId in Data mode is generally used as the value of objectmap. For data less than or equal to 31 bytes, you can avoid relying on an additional object

The rust sample code is as follows
let data = "hello!!! first id";
let id = ObjectIdDataBuilder::new().data(data).build().unwrap();
assert!(id.is_data());
assert!(!id.is_standard_object());
assert!(!id.is_core_object());
assert!(!id.is_dec_app_object());

println!("len={}, {}", id.data_len(), id.to_string());

let data2 = id. data();
assert_eq!(data2.len(), data.as_bytes().len());
assert_eq!(data2, data.as_bytes());
assert_eq!(id.data_as_utf8_string_unchecked(), data);

let id = ObjectIdDataBuilder::build_empty();
assert!(id.is_data());
println!("len={}, {}", id.data_len(), id.to_string());
assert_eq!(id. data_len(), 0);
assert_eq!(id.data().len(), 0);

Complete at b5f344171182943c5c0121323276a81cd9c405f6

repo: buckyos/CYFS


text:
🛑 Videoglancer is down

In 1fd9abb, Videoglancer (https://videoglancer.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Videoglancer is back up in 388f4ad.

repo: budlebee/upptime-kundera


text:
Yahya/features/mock classifier helm chart

This PR addresses creating a reusable CD pipeline which deploys apps to AKS

Thanks @keijoraamat and @decodingahmed for your comments, they were really good and helpful points

repo: buerokratt/Infrastructure


text:
PGV Python Approach

We are considering a new approach for Python that’s a bit different from existing language support as it wouldn’t do meaningful compile-time generation and instead generate the validation function just-in-time (JIT).
What is the approach?
Hand-code a generate_validate function (proto.Message->(proto.Message->bool)) that would do JIT generation at runtime of the validate function for each proto.Message class.
The generated pb2.py files have Descriptors that provide access to the options and annotations on a proto message. In generate_validate we’d walk a Descriptor and get the validation rules for every field. Based on the validation rules, we generate a validation function at runtime and return that to the user.
For performance, we could cache the validate function for each message class. We could also allow pre-priming the cache to avoid cold starts.
A proof of concept of generate_validate:
# proto_message is an instance of a proto message
def _generate_validate(proto_message):
    func = "def validate_fn(p): "
    for field in proto_message.DESCRIPTOR.fields:
        if hasValidation(field): # hasValidation() will check if field is annotated with validation rules
            for option_descriptor, option_value in field.GetOptions().ListFields():
                if option_descriptor.full_name == "validate.rules":
                    if option_value.string != None:
                        func += string_template(option_value.string, field.name)
           	    else if option_value.int32 != None:
                        func += int_template(option_value.int32, field.name)
                    else if ........
    func += "\n  return True"
    exec(func); return validate_fn

This would be used through a validate function that the user can write themselves, or we could write a minimal python package containing this.
#!/usr/bin/python
from validate import generate_validate

validation_funcs = {} #Caching done to avoid generating the function each time
def validate(proto_message):
    if proto_message.DESCRIPTOR.full_name not in validation_funcs:
        validator = _generate_validate(proto_message):
        validation_funcs[proto_message.DESCRIPTOR.full_name] = validator
    return validation_funcs[proto_message.DESCRIPTOR.full_name](proto_message)

Although this approach doesn’t do compile time code generation, we plan to output the file containing generate_validate as part of PGV. This keeps the Python implementation together in the same repo as other languages, but more importantly allows for the same option verification performed now (e.g. int can’t have string rules, etc).
Benefits
This avoids a user needing to find and import each specific foo_validate.py file where the validate() is located which is difficult at runtime without a mess of extra code. Unlike Go, there isn’t a way to hook the validate method into the instance itself without extra imports.
This allows the validation code to be totally generic. As long as the user has imported the standard generated code (foo_pb2.py) before calling validate (as that registers the descriptor in the symbol db), generate_validate will work.
Potential problems
It would involve performance hits due to generating the validation code JIT. However, we minimize the pitfalls through caching, and allowing the cache to be primed to avoid cold starts.

I have a couple issues with this approach:

It makes it extremely difficult to debug the generated code since it only exists in memory, not in readable source code. You could take the generated code above and print it or something for debugging, but that's not the same as having source code you can step through in a debugger.
It introduces more magic into the system. Right now the generated code is extremely straightforward, and while some things are spread across files, it's pretty easy to understand what's going on. With generated code, all that goes out the window.
It introduces a runtime dependency on PGV. With the existing system, the generated code is self-contained, so if you #include/import the generated files you don't have to pull in validate.proto, nor any of the generating code.

Hey @akonradi. Thanks for your input. You're right that this approach has tradeoffs, but we believe it's the right way to go considering the lack of a good alternative for finding a validate function at runtime, which is a major blocker to using PGV in a generic library. To respond more closely to your issues:

Debugging is likely more of a concern for the PGV developer (i.e. us) than an end user. But still, you do have a valid concern. But perhaps it can be mitigated by providing a way to get the string source code for a given class' validate fun. Then a developer could literally step through it in a debugger if they so choose.
I would argue that a single function which does the generation by building up a string is not too magical. Combined with an ability to print the source code as described above, this should make it clear to understand.
There would be no runtime dependency on PGV. Perhaps you've misunderstood our approach. All the necessary code would be entirely self-contained and trivially generated by PGV. There would be no need to pull in validate.proto or anything else.

Sorry, meant to reply and then got lost for two weeks.
I see, so the problem is that there's no way to do static registration in Python like in C++ without loading the modules containing the validate functions ahead of time. I believe Java has similar restrictions and the way the generated code works around it there is by using reflection to load the appropriate Validator class (with caching) when requested. Would it be possible to take a similar approach here, doing a programmatic import of the validation code instead of generating it dynamically?
I'm also a bit confused by how this works with the Bazel-based build. The norm there is to have a separate PGV build rule for each .proto file. Would that just check that the validation annotations are sane and then exit? Would the generate_validate function be provided by the PGV runtime library, independent of the per-.proto output?
Lastly, this seems like it might be a good use case for proto insertion points, provided we can add PGV to all the protoc invocations (in Bazel by changing the proto_library rules).

Hey @akonradi. Thank you for the follow up and your good suggestions. See below for our thoughts:

We mulled over this for a long time and could not come up with a solution we could live with. Since there is no relationship between the python code and the validation code, the best we could do to locate the validation module would be: take the Proto class, get its module path, pop off the filename, and import dir+<filename>_validator.py (i.e. supposedly where the validation code for that proto would live).

Even then that presents other challenges such as: which of the classes or functions in that file is the right one? Two solutions there: either name the classes/functions descriptively and do name matching - i.e. to validate Foo, do
import importlib
validation_class = "Foo" + "Validator"
importlib.import_module(dir+<filename>_validator.py, validation_class)

OR we could try to have the generated code in dir+<filename>_validator.py import the Proto class and hook the validation method into it. But that presents a similar "module discovery" problem.

Exactly, it would check the validation annotations are sane, output the validate.py file - which is independent of the input, but for consistency and to allow for a future dependency we'd like this file to be output by PGV - and then exit.

We thought quite a bit about insertion points. We believe the fundamental change to the API of PGV would be too large of a departure. PGV is additive to the native code, and requiring that it be run in tandem with the native code generation isn't something we were willing to change. (@rodaine can also speak more to this).

@akonradi, given the gotchas python presents here that Dmitriy and Aditya have laid out (for the first interpreted language compared to the rest of the pack), I think the JIT strategy makes sense as an initial endeavor; we can iterate on it to see if a long-term imperative strategy can grow from it.
As mentioned by @dkunitsk, insertion points would be a break from the existing behavior and where previously it was not enforced to run simultaneously with the base code gen plugin, it would be necessary. Towards your Bazel point, we should assume, as a default, consumers of PGV do not use Bazel.

Agreed, there's really not a great way to make the Java approach (where validators can be loaded by class name) or the C++ approach (where validators are registered statically) work for Python.
Agreed on not using insertion points, I think that would end up being more of a headache than we want. I'm still wary of how this will work with Bazel where we invoke PGV once per .proto file, and given that Envoy is one of the main users of PGV, I don't think that's a good assumption. I worry that we're going to end up with some weird asymmetries between using PGV to generate Python and C++/Java code.

Before I found this library, I was actually thinking of doing something similar to this project by using a combination of python-betterproto and pydantic. It looks something like this (this is a working but incomplete example):
@dataclass
class Bar(betterproto.Message):
    boo: str = betterproto.string_field(1)

    @validator('boo')
    def validate_boo(cls, v: str) -> str:
        """A very bad regex email matcher."""
        pattern = r"\w+@\w+\.\w{2,5}"
        if re.fullmatch(pattern, v):
            return v
        else:
            raise ValueError

This seems to achieve what PGV is doing, but using pure idiomatic Python. Does anyone have any insights on this approach vs PGV, or how the two might be reconciled (ex: compile the PGV protobufs to this type of python validation)?

One of the goals with PGV is to have the validation specifications be language-neutral, so any approach would need to take protos as input and produce Python code.

Right, so couldn't code like the above be generated based on the protos? It's not clear to me how the PGV part of the protos is parsed. So the input to the above example would be:
import "validate/validate.proto";

message Bar {

  string email = 1 [(validate.rules).string.pattern =  "\w+@\w+\.\w{2,5}"];

Absolutely. The PGV part is parsed by looking at the descriptor for the message being passed in, using jinja2 templates to generate some Python code, and then executing that. See here, for example.
For the Go and C++ code, we've been reluctant to add additional run-time dependencies, including additional libraries, since that makes PGV code harder to use for consumers. I don't know what the stance is for Python code.

That looks pretty similar to how python-betterproto itself generates the compiled .py files (see here).
It should be possible to pre-write the Python validation functions and have a jinja2 template that ties them to the python-betterproto compiled .py files.
So for example (just throwing everything together, this would be separate files):
# Imports just for clarity
from functools import partial

import betterproto
from pydantic.dataclasses import dataclasses

# Some .py file that contains a bunch of Python functions that perform the validation logic
def string_pattern_val(cls, v: str, pattern: str) -> str:
    if not re.fullmatch(pattern, v):
        raise ValueError(...)
    return v

# The Pydantic dataclass/message that was generated by python-betterproto
@dataclass
class Bar(betterproto.Message):
    boo: str = betterproto.string_field(1)

# Some magic hook inserted by the jinja2 template
Bar.boo_validator = validator(partial(string_pattern_val, pattern="parsed from .proto"), 'boo')

@akonradi any further thoughts on this approach?
I've been working with python-betterproto and it certainly is possible to bake in support for parsing custom options. But I'm not sure if adding python-betterproto and pydantic dependency for using PGV with Python is okay.
In terms of steps, it would look something like:

Get custom option parsing in betterproto.
Build out Pydantic validators in PGV.
Re-work PGV Python plugin to use betterproto/pydantic and attach validators to their respective fields.

@rodaine @kothariaditya can you chime in?

Realizing that the same end goal (i.e. compile .py files) could probably be accomplished by just extending protoc-gen-star to build Python files that use python-betterproto + pydantic directly (instead of relying on python-betterproto to build them). Since protoc-gen-star is already used for Go/Java that kind of makes more sense I think.

@akonradi @rodaine @kothariaditya any updates on this? I'm happy to work on this if there is interest.

An open source tool I wrote that is compatible with pgv rules can generate pydantic model code through protobuf plug-ins   https://github.com/so1n/protobuf_to_pydantic

authors: adriangb akonradi dkunitsk kothariaditya rodaine so1n

repo: bufbuild/protoc-gen-validate


text:
Fix typo in README

Fixed unint32 to uint32

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant sean-ahn


text:
Support of blacklisted keys for feature reports

Changes
During reporter creation specify list of blacklisted_keys like:
humbug_reporter = HumbugReporter(
    ...
    blacklisted_keys=["token", "created_at"]
)

After it all @humbug_reporter.record_call automatically remove blacklisted keys from arguments.
Also, if blacklisted keys required in report, it could be set manually to ignore blacklist with humbug_reporter.feature_report(..., blacklist_apply=False)
How to test these changes?
Added test cases and tested locally with API.
Related issues

Hey @zomglings Not sure if this is already in the PR, but it would be nice to make the key comparison case-insensitive, and also make it so any key contains the "token" substring is excluded.

For example, this is what @istranic 's blacklist_fn would look like:
def activeloop_parameter_blacklist_fn(parameters: Dict[str, Any]) -> Dict[str, Any]:
    return {k:v for k, v in paramters.items() if "token" in k.lower()}

@kompotkot : Suggest some changes: https://github.com/bugout-dev/humbug/pull/96

authors: istranic kompotkot zomglings

repo: bugout-dev/humbug


text:
TypeScript Error

Bugsnag version: 7.22.2
import Bugsnag from '@bugsnag/js';
Bugsnag.start({
apiKey: 'YOUR_API_KEY'
});
Error: Property 'start' does not exist on type 'typeof import("node_modules/@bugsnag/js/types")'.
Any thoughts?

did you find the fix?

Hi @isimisi,
Unfortunately we are unable to reproduce this issue. If you’re experiencing the same issue, please could you send us the contents of your package.json file for our further investigation? Feel free to write in to us at support@bugsnag.com if you don’t want to share your package.json publicly here.

authors: dcc82 hannah-smartbear isimisi

repo: bugsnag/bugsnag-js

license: mit


text:
Bugsnag Shows js stack trace and php error codes but no php stacktrace.

Expected behavior
Bugsnag should show the php stack trace for error 500.
Observed behavior

Error · Request failed with status code 500
webpack-internal:///85061:16:15 createError
webpack-internal:///36026:17:12 settle
webpack-internal:///55448:66:7 XMLHttpRequest.onloadend*

Reports error code only and shows vue.js stack trace
Here are the bugsnag and logging configs:
config/logging.php
'default' => env('LOG_CHANNEL', 'stack')
...
'channels' => [
    'stack' => [
      'driver' => 'stack',
      'channels' => ['single', 'bugsnag'],
      'ignore_exceptions' => false,
    ],
    'single' => [
      'driver' => 'single',
      'path' => storage_path('logs/laravel.log'),
      'level' => env('LOG_LEVEL', 'debug'),
    ],

...
    'bugsnag' => [
      'driver' => 'bugsnag',
    ],

config/app.php
       /*
         * Package Service Providers...
         */
        Intervention\Image\ImageServiceProvider::class,
        Bugsnag\BugsnagLaravel\BugsnagServiceProvider::class,

        /*
         * Application Service Providers...
         */
        App\Providers\AppServiceProvider::class,
        App\Providers\AuthServiceProvider::class,
        App\Providers\BroadcastServiceProvider::class,
        App\Providers\EventServiceProvider::class,
        App\Providers\RouteServiceProvider::class,

        App\Providers\BugsnagServiceProvider::class,
    ],

config/bugsnag.php
'release_stage' => env('BUGSNAG_RELEASE_STAGE'),
'notify_release_stages' => empty(env('BUGSNAG_NOTIFY_RELEASE_STAGES')) ? null : explode(',', str_replace(' ', '', env('BUGSNAG_NOTIFY_RELEASE_STAGES'))),

.env
APP_ENV=production
APP_DEBUG=false
APP_LOG_LEVEL=debug
...
BUGSNAG_API_KEY= key
BUGSNAG_QUERY_BINDINGS=true

Hi @ndethi,
Please could you tell us a bit more about your project setup? When you say PHP stacktrace, what exactly are you expecting to see?
Please could you send a link to the error in question along with answers to the questions above at support@bugsnag.com to help us investigate this further?

Going to close this out as we have not heard from you in a while. We do need some additional information in order to investigate this further. Happy to reopen as necessary.

authors: hannah-smartbear johnkiely1 ndethi

repo: bugsnag/bugsnag-laravel


text:
Where to add username exception

In the tutorial on laracast, Jeffrey Way put it in the global.php file. I do not have that file in laravel 5.1. How do I implement the extra config? Do I have to create the global.php file?

What Laravel version are you using please?

In Laravel 5.1, you can do this in the boot function of your app service provider.


text:
Every commit should produce releasable crates

We want to have a continuous delivery model for our packages:

Rust Crates
Hex Packages
Docker Images etc.

Every commit that lands at the HEAD of develop should get picked up by an Github Workflow that creates packaged artifact and stores it in ockam-network/artifacts

Acceptance tests should be run on these packaged artifacts.

When its time to publish a package, it should be published from the artifacts repository.

The first package class we want to do this for is Rust Crates.
cargo package creates a packaged .crate artifact without publishing it
https://doc.rust-lang.org/cargo/commands/cargo-package.html
This can be store in the artifacts git repository.
We may want to sign these .crate files until there is a more mature sign/verify for the rust ecosystem
cargo publish should be invoked in the artifacts repository
Some other feature that may be helpful.
Dependency Overrides https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#overriding-dependencies
Path Overrides https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#paths-overrides
may be useful.

This is now in place.

repo: build-trust/ockam


text:
VS 2017 CMAKE Build Issues

Hi I try to get CMAKE gui to create build. But encounter library not found.

Build the source will encounter this error below.

Two questions:

Did you set up OpenSSL in the right place (or at all)?
Can you paste the full text of the VS 2017 compile errors, as right now I don't see what file+line the error concerns

Also try with my newest commits to the stable-ish branch

@vutle, if NASTY_OPENSSL_WORKAROUND is ON, then (as described in Wiki article), should openssl's root dir should be in .. relatively to Irrlicht's root dir. Since this is Windows and you never know how things are, currently cmake script assumes that openssl dir looks like this:
irrlicht_root/../openssl/
--- lib/
------ libeay32.lib
--- include/
------ openssl header files...

The other way is to uncheck this NASTY_OPENSSL_WORKAROUND option and manually provide paths to eay lib to SSL_EAY_DEBUG, SSL_EAY_RELEASE, LIB_EAY_DEBUG and LIB_EAY_RELEASE cmake vars and path to include dir to OPENSSL_INCLUDE_DIR.
As for errors you experience: apparently MSVC is a little buggy and doesn't inherit default constructor. Already fixed, so you can build from my fork, branch fix or wait wait until @devshgraphicsprogramming merge my PR and build from his stable-ish branch.

Once I verify it builds on my windows laptop I close the issue

@Crisspl I have a massive error with my cmake-gui, it generates win32 visual studio targets not x86!
Why is it trying to make a 32bit build target instead of 64bit?

I think, you have to choose other compiler/IDE option in cmake-gui if i remember correctly (there are 2 distinct options for x86 and x86_64). I had same issue once and it was the problem. Apprently i forgot to place it into the wiki, sorry

authors: Crisspl devshgraphicsprogramming vutle

repo: buildaworldnet/IrrlichtBAW


text:
What version of (Rd)SAP is implemented?

Hi, specifically which version of RdSAP does this implement? Is it the latest version  9.94? Or an earlier version of SAP2012?
Also, would you be able to do a release to pypi from your master branch for the changes made in 2023?

Thank you for your questions.

Hi, specifically which version of RdSAP does this implement? Is it the latest version  9.94? Or an earlier version of SAP2012?
At present this is an implematation of SAP2012 version 9.92. There is some work in the repository on also implementing RdSAP, which would then be able to take a smaller set of inputs and use built-in inferences to create the full set of inputs needed for the SAP2012 calculation. This is based on RdSAP version 9.94 but the implemention of this RdSAP version has not been completed.

Also, would you be able to do a release to pypi from your master branch for the changes made in 2023?
I think that these changes were around the work on RdSAP which was not completed. So I'm not planning to create a new release. Please do download directly from GitHub if needed and do let me know if I have this wrong.

I am now working on an implementation of SAP10 - the next version of SAP after SAP2012. SAP10 is now being used for new dwellings and will be replacing SAP2012 for existing dwellings and EPCs later this year. If you would like more information on this, please contact me via my email s.k.firth@lboro.ac.uk.

Thanks for your response!

I think that these changes were around the work on RdSAP which was not completed. So I'm not planning to create a new release. Please do download directly from GitHub if needed and do let me know if I have this wrong.

Yes that appears to be the case. The RdSAP inputs are what we were most interested in, so for now I think we'll continue our work without a SAP integration.
If our needs change would you be open to pull requests to implement the RdSAP mappings?

authors: devanubis stevenkfirth


text:
Does Privatezilla read at startup the current Registry settings and toggle the checkboxes?

Does Privatezilla read at startup the current Registry settings and toggle the checkboxes accordingly?
It other words: Do the Privatezilla checkbox states (checked/unchecked) always represent the current state of the internal Win10 options?

It doesn't seem like it. It seems confusing to the user/annoying if you click apply, it would? disable options that have no checkbox, meaning you would need to check to see if your options are correct every time you run the program.
I don't know if de-selecting actually disables the option or just ignores setting it.

repo: builtbybel/privatezilla


text:
Add New Filter or Where Condition in  Job Status = Open

Currently there is one Condition for Job search i.e Open Jobs.
I want to add another condition Job Status = Open,
I want to display the job list where   Job Status = Open,
Please Guide me .
Not other Status
Current behavior
Not Checking BullHorn  Job Status,

Expected behavior
Need to Check BullHorn  Job Status where Job Status = Open

Steps to replicate behavior

Screenshots

Current
Expected

Hello,
By default the portal looks at the Open/Closed field rather than the job status field as there could be possibly multiple statuses applicable when a job is open and accepting candidates.   We recently added a feature where you are able to access more than the standard set of fields to filter on or add fields to your job.  To enable additional fields you will need to modify your portal to add the fields into the search query, and you or an authorized support contact will need to contact Bullhorn Support to add the field as well.
Please let me know if you have any questions.

authors: charlesabarnes developergoutam

repo: bullhorn/career-portal


text:
Update Bootstrap.zep

解决PHP7.3.4兼容性问题：define()函数第三个参数不可为true

please pr to branch 1.1.0, not branch master

authors: guweigang vgocoder

repo: bullsoft/phalconplus


text:
Is there a way to get native html event when user click a node?

@bumbeishvili  Is there a way to get native html event when a user click a node?

Yes, there is a global d3.event object available that time
Note - it will be removed when I convert this graph to d3.v6, instead the user will receive it as a first argument, in node Click Hander function

@bumbeishvili Thanks.
Can't wait for the upgrade to d3.v6 released

authors: aizaiz bumbeishvili


text:
Mismatch in Gemfile.lock remote property leads to bundle install failure

This bug is observed since 1.14.5.
During development, our Gemfile targets rubygems.org. During deployment, our Gemfile may target a local gem caching server (using gemstash) for reliability.
In our scenario, GEM_SERVER_URL is not defined during development time, so it falls back to rubygems.org. Since developers generate the Gemfile.lock file, naturally, it will use rubygems.org as the remote property. During deployment, we define GEM_SERVER_URL to a local server before performing bundle install --deployment.
Since 1.14.5, the bundler will not allow bundle install to proceed unless the remote property matches between the Gemfile and Gemfile.lock. When we target a local gem server and perform bundle install --deployment, it outputs the following message:
You are trying to install in deployment mode after changing your Gemfile. Run `bundle install` elsewhere and add the updated Gemfile.lock to version control.

This new behavior is introduced in 1.14.5. As workaround, we have now rollback to 1.14.4.
If this behavior is by design, how would we work around it?

You can set the config option mirror.SOURCE_URL MIRROR_UR in your deployment env to use the MIRROR_URL when fetching gems from the SOURCE_URL (this case being rubygems.org`).  See bundler config for more information.

I can add that if the Gemfile had a source with credentials (the "authority" part of its URI) and the lock file didn't, the same new trouble situation would apply. Before 1.14.5, this (admittedly weird) setup caused no trouble.

Thank you all, I will give the mirror.SOURCE_URL option a try.

ping @askldjd, did the Bundler config option work?

@colby-swandale Sorry, running a bit behind schedule. I will get you an answer by this week.

Adding mirror configuration does not work if the mirror is not available in the development environment:
Fetching source index from <internal IP>

Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from <internal IP>
Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from <internal IP>
Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from <internal IP>
Could not fetch specs from
<internal IP>
vhaisavovka0x@VACOLTVOVKA:caseflow-efolder>bundle config
Settings are listed in order of priority. The top value will be used.
mirror.http://rubygems.org/
Set for the current user (/Users/vhaisavovka0x/.bundle/config): "<internal IP>"

Either that or bundle install just fails completely. Also, running bundle install --deployment fails if the mirror is configured because remote property in Gemfile.lock is different between the environments (error show in the original ticket).

I'm closing this for now. If you're still experiencing your original issue don't be afraid to re-open this ticket.

Final note:
@kierachell and I were not able get mirror config working. We worked around this issue by doing a find/replace in the gemfile during deployment time.
Here's the snippet of our ansible code that does this.
- name: config gem server
  replace:
    dest: "{{ app_src }}/Gemfile.lock"
    regexp: "remote: https://rubygems.org/"
    replace: "remote: {{ gem_server[deploy_env] | default('https://rubygems.org/') }}"

authors: askldjd colby-swandale kierachell olleolleolle

repo: bundler/bundler


text:
bundler issue

trying to do bundle command but

Bundler could not find compatible versions for gem "bundler":
In Gemfile:
bundler (~> 1.15)
Current Bundler version:
bundler (2.0.1)
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running gem install bundler?
Could not find gem 'bundler (~> 1.15)' in any of the relevant sources:
the local ruby installation

even though I uninstall bundler it still remained with bundler(2.0.1).
I think my anaconda also has bundler things but not sure.
How to force to use bundler 1.15? or to fix above issue

@SangwonJakeEum
bundler (~> 1.15) in the Gemfile means >= 1.15 and < 1.2, while you have bundler - 2.0.1 installed.
Have you tried -
gem install bundler -v 1.15 and then forcing the bundler version with - bundle _1.15_ <command> ?

authors: SangwonJakeEum ankitkataria


text:
Implements amd

amd + some beauty (lines 38-41 are the same 43-46)

Thanks @artemkaint
Did you do any testing for older browsers? if it works ok?

IE9 http://joxi.ru/8An0zayHjBoNmO
IE8 http://joxi.ru/gmveY1GULpdara
This is standart code for amd loading

@artemkaint
indeed but is always good testing ;)
Thanks, asap I will merge :+1:

any updates on this?

authors: alexprg artemkaint ochervak

repo: burocratik/outdated-browser


text:
Add new list item : Double list element after pressing ENTER

I have an issue with the 'Add new list item' feature which I've never had before.
I don't know why but every time I press ENTER in a list with asterisks a second asterisk spawns (cf. picture below)

Could you try reloading Atom? I've noticed this before, and it might be related to #72.

After a full restart of Atom the feature  works well again !
I think you're right about the issue #72

I updated, this morning, from the last update released (so I expect 0.16.1) to v0.16.2 because I was up to date in my Atom packages yesterday !

Okay, thank you!

authors: AntoineLT burodepeper

repo: burodepeper/language-markdown


text:
set log and pid folder + multiple mount points

Added variable in all to set log and pid folder + multiple mount points support

Let me know your thoughts

repo: bushnoh/ansible-hadoop-asap


text:
Feature request: Embedded cutelog

It would be nice to have a separate entry that used an existing QT MainWindow that would make cutelog easily added to other QT based programs.
Possibly add a way to pass through a custom program name as well, so it could display in the title bar  "ProgramName Logs (powered by cutelog)" or similar.

So far I can launch it:
    def start_cutelog(self):
        from cutelog.main_window import MainWindow
        import sys
        if sys.platform == 'win32':
            import ctypes
            appid = 'busimus.cutelog'
            ctypes.windll.shell32.SetCurrentProcessExplicitAppUserModelID(appid)

        self.mw = MainWindow(logging.getLogger('my_log'), self)
        self.mw_close_event = self.mw.closeEvent
        self.mw.closeEvent = lambda x: print('nope')
        self.mw.hide()

    def show_logs(self):
        self.mw.show()

    def closeEvent(self, event):
        self.mw_close_event(event)
        super().closeEvent(event)

    def quit(self):
        pass # required as closeEvent() in cutelog calls parent_app.quit

Opens and closes fine.
But has an issue with resource paths (installed via pip)
Once a log message is sent:
  File "...venv/lib/python3.8/site-packages/cutelog/logger_tab.py", line 512, in setupUi
    self.ui = loadUi(CONFIG.get_ui_qfile('logger.ui'), baseinstance=self)
  File "..../venv/lib/python3.8/site-packages/cutelog/config.py", line 160, in get_ui_qfile
    raise FileNotFoundError('ui file not found: ":/ui/{}"'.format(name))
FileNotFoundError: ui file not found: ":/ui/logger.ui"

repo: busimus/cutelog


text:
Update lags.py

Refactored for polars engine.
Followed the pattern established in the version of summarize_by_time.  There should be no conflicts, ran checks first and now that we have polars accounted for we should be good as there were no conflicts on my end.

No conflicts. Should be good to go!

repo: business-science/pytimetk


text:
🛑 Nitesh Forest Hills and Flush Meadows is down

In fbb689a, Nitesh Forest Hills and Flush Meadows (https://cloud.tymly.in/status/1023) was down:

HTTP code: 521
Response time: 232 ms

Resolved: Nitesh Forest Hills and Flush Meadows is back up in ded1a57.

repo: bvenkysubbu/tymlymonitor


text:
🛑 Sowparnika Swastika 2 is down

In de0428e, Sowparnika Swastika 2 (https://cloud.tymly.in/status/1099) was down:

HTTP code: 521
Response time: 223 ms

Resolved: Sowparnika Swastika 2 is back up in 3e8d8bc.


text:
🛑 Adarsh Vihar is down

In 52fa54f, Adarsh Vihar (https://cloud.tymly.in/status/1041) was down:

HTTP code: 521
Response time: 20238 ms

Resolved: Adarsh Vihar is back up in 4543b84.


text:
🛑 Sterling Villa Grande is down

In 988a5cc, Sterling Villa Grande (https://cloud.tymly.in/status/1068) was down:

HTTP code: 521
Response time: 220 ms

Resolved: Sterling Villa Grande is back up in 8346720.


text:
🛑 White Breeze 1 is down

In 5d330cc, White Breeze 1 (https://cloud.tymly.in/status/1096) was down:

HTTP code: 521
Response time: 232 ms

Resolved: White Breeze 1 is back up in c92f897.


text:
🛑 Dasta Concerto Entrance is down

In 7d13d3d, Dasta Concerto Entrance (https://cloud.tymly.in/status/1137) was down:

HTTP code: 521
Response time: 20238 ms

Resolved: Dasta Concerto Entrance is back up in 56424cb.


text:
🛑 SBB Touchstone A2 Block is down

In de16545, SBB Touchstone A2 Block (https://cloud.tymly.in/status/1187) was down:

HTTP code: 521
Response time: 20251 ms

Resolved: SBB Touchstone A2 Block is back up in 07ca4fe.


text:
🛑 SMD Altezz Clubhouse is down

In 0eb4d2a, SMD Altezz Clubhouse (https://cloud.tymly.in/status/1178) was down:

HTTP code: 521
Response time: 20230 ms

Resolved: SMD Altezz Clubhouse is back up in 0ac1189.


text:
🛑 PSR Aster 1 is down

In 886690c, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 20219 ms

Resolved: PSR Aster 1 is back up in fbef174.


text:
🛑 Nitesh Flushing Meadows Block D is down

In 635de16, Nitesh Flushing Meadows Block D (https://cloud.tymly.in/status/1049) was down:

HTTP code: 521
Response time: 20220 ms

Resolved: Nitesh Flushing Meadows Block D is back up in 9ae0798.


text:
🛑 SMD Altezz Block A Basement is down

In 304f671, SMD Altezz Block A Basement (https://cloud.tymly.in/status/1205) was down:

HTTP code: 521
Response time: 20245 ms

Resolved: SMD Altezz Block A Basement is back up in f0c4359.


text:
🛑 SMD Altezz Block B is down

In c403e9c, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 20256 ms

Resolved: SMD Altezz Block B is back up in 6e1068a.


text:
🛑 VBHC Serene Town D Block is down

In efc682c, VBHC Serene Town D Block (https://cloud.tymly.in/status/1131) was down:

HTTP code: 521
Response time: 238 ms

Resolved: VBHC Serene Town D Block is back up in 97140b0.


text:
🛑 Sowparnika Ananda is down

In c37742b, Sowparnika Ananda (https://cloud.tymly.in/status/1036) was down:

HTTP code: 521
Response time: 20238 ms

Resolved: Sowparnika Ananda is back up in e913b3c.


text:
🛑 SMR Vinay Cascade A Block is down

In 92362a1, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 20237 ms

Resolved: SMR Vinay Cascade A Block is back up in 0883193.


text:
🛑 VBHC Serene Town B Block is down

In ce6bd86, VBHC Serene Town B Block (https://cloud.tymly.in/status/1130) was down:

HTTP code: 521
Response time: 229 ms

Resolved: VBHC Serene Town B Block is back up in 0c23ffb.


text:
🛑 Trifecta Esplanade F Block is down

In d36131b, Trifecta Esplanade F Block (https://cloud.tymly.in/status/1159) was down:

HTTP code: 521
Response time: 2014 ms

Resolved: Trifecta Esplanade F Block is back up in 26cae2b.


text:
🛑 Trifecta Esplanade B Block is down

In 5cb3175, Trifecta Esplanade B Block (https://cloud.tymly.in/status/1154) was down:

HTTP code: 521
Response time: 238 ms

Resolved: Trifecta Esplanade B Block is back up in 6e1fc44.


text:
🛑 SMR Vinay Cascade A Block is down

In e3b63d6, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 20227 ms

Resolved: SMR Vinay Cascade A Block is back up in 5dd63de.


text:
🛑 Gayathri Goodlife is down

In a4f3709, Gayathri Goodlife (https://cloud.tymly.in/status/1009) was down:

HTTP code: 521
Response time: 21359 ms

Resolved: Gayathri Goodlife is back up in 8797cc7.


text:
🛑 PSR Aster 1 is down

In 42d005a, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 20234 ms

Resolved: PSR Aster 1 is back up in baa612a.


text:
🛑 Whitestone Landmark is down

In b16625e, Whitestone Landmark (https://cloud.tymly.in/status/1095) was down:

HTTP code: 502
Response time: 221 ms

Resolved: Whitestone Landmark is back up in 72e928b.


text:
Account Creation date

I need to get the date a user created their account. but I couldn't find an object that provides this, it would be nice to have User.CreatedAt as in discord.js

found on discussions, please ignore

repo: bwmarrin/discordgo


text:
bug: nil pointer dereference while the bot was idling

Hi there. I'm using discordgo v0.28.1 and while my bot was just idling (there was no slash command or message handling happening), it suddenly shut down with a panic:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x6b8db7]

goroutine 26 [running]:
github.com/bwmarrin/discordgo.(*Member).DisplayName(...)
        github.com/bwmarrin/discordgo@v0.28.1/structs.go:1591
lab.lostb.one/che/dimi/internal/pkg/dimi.logMessage(0xc000004a88, 0xc000066090)
        lab.lostb.one/che/dimi/internal/pkg/dimi/handlers.go:126 +0x1f7
lab.lostb.one/che/dimi/internal/pkg/dimi.messageHandler(0xc000004a88, 0xc000066090)
        lab.lostb.one/che/dimi/internal/pkg/dimi/handlers.go:250 +0x74
github.com/bwmarrin/discordgo.messageCreateEventHandler.Handle(0x44445d?, 0x8?, {0x72e0a0?, 0xc000066090?})
        github.com/bwmarrin/discordgo@v0.28.1/eventhandlers.go:774 +0x33
created by github.com/bwmarrin/discordgo.(*Session).handle in goroutine 37
        github.com/bwmarrin/discordgo@v0.28.1/event.go:171 +0x149

Since this is the return statement of *Member.DisplayName(), I assume that m.User.GlobalName was not set.
Does the code need to check for nil for m.User? I don't know, just my first guess.
On second thought, it might be my code. I've added more extensive logging and will continue to monitor this and report back with new findings.

Okay, I figured it out. I have a logging function for messages and a message from another bot caused this crash. Apparently this bot (or bots in general) doesn't have m.Member.User set, so the call to m.Member.DisplayName() panicked.
I've added another check if m.Member.User is nil to handle this case, which fixed the problem.
Sorry for the noise, I'm closing this issue!


text:
Ikea Tradfri Bulbs paired to Sonoff Zigbee Bridge not supported in Homebridge

What issue do you have? Please be as thorough and explicit as possible.
Ikea Tradfri bulb paired to Sonoff Zigbee bridge. Works perfectly through Ewelink App. Not supported error in Homebridge. Log shows:
[eWeLink] [Portrait RHS] is not supported, do create a GitHub issue with the following info:
[3258] {"bindInfos":{"gaction":["f2ac1e8c-a416-4174-ae29-d8b22d9ac39a_ewelink-google-home-v1"]},"subDevId":"a81fb5feff65112c","parentid":"10013d960d","switch":"on","brightness":55.90551181,"colorMode":"cct","cctBrightness":56,"colorTemp":28,"rgbBrightness":100,"hue":35,"saturation":78}.
Details of your setup.

Do you use Homebridge (with config-ui?) or HOOBS?
config-ui on Apple Mac

Which version of Homebridge/HOOBS do you have?
Current

Which version of this plugin (homebridge-ewelink) do you have? Has the issue started since upgrading from a previous version?
10.0.0

Which eWeLink devices do you have that are causing issues? Please include product models if applicable.
Ikea Tradfri bulb paired to Sonoff Zigbee Bridge

Do you use your main eWeLink credentials or do you use a secondary eWeLink account for Homebridge?
Main

Please paste any relevant logs below.

[eWeLink] [Portrait RHS] is not supported, do create a GitHub issue with the following info:
[3258] {"bindInfos":{"gaction":["f2ac1e8c-a416-4174-ae29-d8b22d9ac39a_ewelink-google-home-v1"]},"subDevId":"a81fb5feff65112c","parentid":"10013d960d","switch":"on","brightness":55.90551181,"colorMode":"cct","cctBrightness":56,"colorTemp":28,"rgbBrightness":100,"hue":35,"saturation":78}.

Hi,
Closing this just as been a little overwhelmed with issues recently.
If this is still an issue or a feature you would like implemented then please do re-open this ticket!
Thanks for your understanding!


text:
Integrate Tempurpedic bed base

This is likely an edge case, but I would love to see the tempurpedic bed base included here.
Some work has been done to make this an alexa skill at https://github.com/docwho2/java-alexa-tempurpedic-skill
I'm willing to help, but I'm not a programmer.

Will take a look and see what it takes. IT will be after some other requests though

Only one person interested in this.....

authors: bwssytems tymanthius

repo: bwssytems/ha-bridge


text:
Feat/prop types

Types of Changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[ ] Bug fix (non-breaking change which fixes an issue, please reference the issue id)
[ ] New feature (non-breaking change which adds functionality, make sure to open an associated issue first)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] All new and existing tests passed

Description
[Place a meaningful description here.]

:tada: This PR is included in version 4.1.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: bylapidist/components


text:
Error while launching Empire with CrackMapExec

Steps Performed -- Created Empire Rest API call on a custom port and updated .~/cme.conf accordingly
Command string used -- crackmapexec smb 10.0.0.1 -d domain -u admin -p password --server-port=445 -M empire_exec -o LISTENER=http1
CME verbose output (using the --verbose flag)
Traceback (most recent call last):
File "/usr/local/bin/crackmapexec", line 11, in
load_entry_point('crackmapexec==4.0.0.dev0', 'console_scripts', 'crackmapexec')()
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/crackmapexec.py", line 151, in main
module = loader.init_module(props['path'])
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/loaders/module_loader.py", line 96, in init_module
module.options(context, module_options)
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/modules/empire_exec.py", line 50, in options
self.empire_launcher = r.json()['multi/launcher']['Output']
KeyError: 'multi/launcher'
OS -- Kali Linux 2016 R2 (32-Bit)
Detailed issue explanation -- Received above error while launching empire_exec module from CME
Help appreciated. Thanks in advance.

@str4n63r what empire version are you using?

@byt3bl33d3r Latest pull from Github

Having the same issue:
sudo crackmapexec smb IPs.txt -u User -H 12345678902bbbe760ea1f1234567890 -M empire_exec -o LISTENER=CME
Result:
Traceback (most recent call last):
  File "/usr/bin/crackmapexec", line 11, in <module>
    load_entry_point('crackmapexec==3.1.5', 'console_scripts', 'crackmapexec')()
  File "/usr/lib/python2.7/dist-packages/cme/crackmapexec.py", line 219, in main
    module, context, server = loader.init_module(modules[m]['path'])
  File "/usr/lib/python2.7/dist-packages/cme/moduleloader.py", line 82, in init_module
    module.options(context, module_options)
  File "/usr/lib/python2.7/dist-packages/cme/modules/empire_exec.py", line 46, in options
    self.empire_launcher = r.json()['launcher']['Output']
KeyError: 'launcher'

CME is from current Kali-rolling and Empire is from Github today.

same issue with out the Empire part,
root@kali:/opt/CrackMapExec# cme
Traceback (most recent call last):
File "/usr/local/bin/cme", line 11, in
load_entry_point('crackmapexec==4.0.0.dev0', 'console_scripts', 'cme')()
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/crackmapexec.py", line 33, in main
args = gen_cli_args()
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/cli.py", line 67, in gen_cli_args
protocol_object = p_loader.load_protocol(protocols[protocol]['path'])
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/loaders/protocol_loader.py", line 12, in load_protocol
protocol = imp.load_source('protocol', protocol_path)
File "/usr/local/lib/python2.7/dist-packages/crackmapexec-4.0.0.dev0-py2.7.egg/cme/protocols/smb.py", line 30, in
from pywerview.cli.helpers import *
File "/usr/local/lib/python2.7/dist-packages/gevent-1.2.2-py2.7-linux-x86_64.egg/gevent/builtins.py", line 93, in import
result = _import(*args, **kwargs)
ImportError: No module named pywerview.cli.helpers
CME is from current Kali-rolling

Any update to this?  Using CME 3.1.5 from Kali repo and Empire 2.0.  Using the absolute path (/usr/bin/crackmapexec) doesn't work for me.

Having the same issue:
CME
Version: 3.1.5
Codename: 'Smidge'
Rolling Kali
confirmed current 30NOV17 (apt-get update, apt-get upgrade, apt-get dist-upgrade)

Same Here.
Mac High Sierra 10.13.3
Version 3.1.5
'Smidge'
lan1ak3as-mbp:Applications *$ sudo cme smb [IP] -u [UNAME] -p [PW] -M empire_exec -o LISTENER=empire
Traceback (most recent call last):
File "/usr/local/bin/cme", line 11, in
sys.exit(main())
File "/Users//Library/Python/2.7/lib/python/site-packages/cme/crackmapexec.py", line 219, in main
module, context, server = loader.init_module(modules[m]['path'])
File "/Users//Library/Python/2.7/lib/python/site-packages/cme/moduleloader.py", line 82, in init_module
module.options(context, module_options)
File "/Users//Library/Python/2.7/lib/python/site-packages/cme/modules/empire_exec.py", line 46, in options
self.empire_launcher = r.json()['launcher']['Output']
KeyError: 'launcher'

I'll take a look at this now. This is probably happening cause Empire changed it's API again.

Thank you @byt3bl33d3r for your dedication in keeping up with the API!

Hi, same exact issue as all those above. Still no fix?

Also having this issue. Running it from /usr/bin doesn't work either.

in Kali for KeyError: 'launcher', i had the same issue here is what i did :
1 - open /usr/lib/python2.7/dist-packages/cme/modules/empire_exec.py
2- in ligne 44  replace "launcher" with an empire stager like "windows/dll" for exemple
3- in line 46 : replace "self.empire_launcher = r.json()['launcher']['Output']" ===> self.empire_launcher = r.json()['windows/dll']['Output']
try launching CME now, good luck

in Kali for KeyError: 'launcher', i had the same issue here is what i did :
1 - open /usr/lib/python2.7/dist-packages/cme/modules/empire_exec.py
2- in ligne 44 replace "launcher" with an empire stager like "windows/dll" for exemple
3- in line 46 : replace "self.empire_launcher = r.json()['launcher']['Output']" ===> self.empire_launcher = r.json()['windows/dll']['Output']
try launching CME now, good luck

That worked. Thanks!

Some have tested this with this project ? https://github.com/BC-SECURITY/Empire/
Do we need to apply a fix or a close this issue ?

Someone have tested with this project ? https://github.com/BC-SECURITY/Empire/

Tested it this morning against a fresh-install of Server2016 with the latest powershell-empire from BC-Security. Worked fine for me.

Closing, follow issue (empire and metasploit module ) #357


text:
Fix/Simplify the atomic.wait/nofity implementations

Use the shared memory's shared_mem_lock to lock the whole atomic.wait and
atomic.notify processes, and use it for os_cond_reltimedwait and os_cond_notify,
so as to make the whole processes actual atomic operations:
the original implementation accesses the wait address with shared_mem_lock
and uses wait_node->wait_lock for os_cond_reltimedwait, which is not atomic
operation.
And remove the unnecessary wait_map_lock and wait_lock, since the whole
processes are already locked by shared_mem_lock.

Thank you @wenyongh !
Is this PR about the hanging problem?
Because I just tried it and it still hangs exactly the same, but if I use wasi-libc with your fix it doesn't hang anymore on this branch but it doesn't hang on the main branch either.
Also I opened an issue about it in wasi-libc with my investigation, but since you made PRs I suppose you discovered the same things

Thank you @wenyongh !
Is this PR about the hanging problem? Because I just tried it and it still hangs exactly the same, but if I use wasi-libc with your fix it doesn't hang anymore on this branch but it doesn't hang on the main branch either.

The root cause of the hang is that the opcodes generated of a_store is not atomic for interpreter mode, as you mentioned, I submitted a PR to fix it in wasi-libc.
The PR fixes a potential issue of WAMR atomic.wait implementation, which is not atomic in fact: a) we use shared_memory_wait to get *address to check whether need to wait, and then b) use wait_lock to perform os_cond_reltimedwait. If another thread changes *address between a) and b), then the original thread will still run into wait which might be indefinite and hang. After changing, we use shared_memory_lock to lock the whole process (both a) and b) to make it atmoic.

Also I opened an issue about it in wasi-libc with my investigation, but since you made PRs I suppose you discovered the same things

The data races seems to be normal behavior, the a_swap operation in wasi-libc is like:
https://github.com/WebAssembly/wasi-libc/blob/main/libc-top-half/musl/src/internal/atomic.h#L106-L115
	int old;
	do old = *p;
	while (a_cas(p, old, v) != old);
	return old;

Here old = *p is not atomic, and a_cas(p, old, v) is atomic, if two threads operate on the same address p, data races may be reported by sanitizer.

If another thread changes *address between a) and b), then the original thread will still run into wait which might be indefinite and hang.

Gotcha, make sense. I will ran tests with TSAN and multiple times as I did to find hanging situations

Here old = *p is not atomic, and a_cas(p, old, v) is atomic, if two threads operate on the same address p, data races may be reported by sanitizer.

Hm, isn't it needed to be fixed then? What's the benefit to keep it that way?

Multiple runs and running under TSAN passed 👍

repo: bytecodealliance/wasm-micro-runtime


text:
Excessive memory usage compiling small module with memfd

Some local fuzzing found today that this module:
(module
  (memory 65536)
  (data (i32.const 0) "a")
  (data (i32.const 1_000_000_000) "b")
)

produces a nearly 1GB large artifact, almost entirely consisting of the heap image. Additionally compile-time memory usage is 1GB or so large because we create the in-memory image at compile time.
I think that during static memory initialization we'll want to be more clever about creating the heap image. For example the paged memory initialization is sparse in the sense of it only keeps track of initialized pages, and for this form of initialization we probably also want to do something sparse like that and determine at the end based on nonzero-ranges whether the image is one-memfd-mmap compatible.

Interesting, so there is an explicit limit of 1GiB exactly on memfd image size: here; the fuzzer figured out how to turn the knob all the way up I guess.
We could definitely reduce that limit, especially since we support an "image and leftovers" initialization technique now -- a CoW image for "most" of the heap down in a reasonable range (16MiB? 128MiB?) and explicit eager instantiation for whatever bytes are way up high.
We could also think about segmented/sparse approaches where we have multiple pieces, each of which has to be mmap'd, but I'm much more hesitant to go there as it makes the mapping path significantly more complex and adds mmap syscalls and increases the size of the in-kernel address space tree, making pagefaults marginally more expensive.
I'm leaning toward just lowering the limit given the above, but: thoughts?

I feel like the most robust and simple fix for now might be to, when switching to a static init, do paged init first and if that succeeds only transform to a static initialization scheme if the initialized pages fit within a smaller range than 1GB.
Ideally though the limit on the memfd image should be somewhat proportional to the size of the data segements in the original module. We naturally shouldn't blow up 2 bytes (above) to 1GB but at the same time if you provide a 1GB data section we should presumably still allow that because memfd is still going to be a ton faster than eagerly copying a gigabyte of data.
I definitely think we should avoid adding complication to the current initialization scheme. For example I don't think we should support multiple mmaps nor one mmap plus extra initialization. I don't think we have any modules in the wild which actually need that so all we need to do is get the one-image technique working well but also accounting for esoteric edge cases that avoid stressing the system.
So given all that, I would propose:

Delegate to try_paged_init from try_static_init. Only proceed if paged initialization took hold.
Discard all entirely-zero pages
Calculate the min/max and if it's less than 2x (?) the size of the original data segments then write all those pages to an in-memory vector as an initialization image.

I think that would solve the above module (we'd create two pages and then realize their limits are way too big: 1GB vs 2 bytes). It would also handle LLVM-produced Rust modules where the heap starts with a megabyte of zeros for the stack, we'd never actually create those zeros and we'd only create the one heap image. Additionally we'd handle modules that already have very large data segments by avoiding making them too much larger but still speeding up their initialization. I believe this would enable us to remove the size limit as well because paged initialization doesn't currently have a size limit and the memory usage is all proportional to the number of data sections in the original wasm module.

We only trim zeros at the end, however. The entire image is built in-memory and then before finalizing and serializing to disk (or memfd) it's trimmed. This means that today we have a 1MB overhead for Rust-based modules which have a leading 1MB stack.
I agree about performance cliffs, but no matter how you slice it it's always a performance cliff. If we set the limit to 128MB then as soon as someone has a 129MB heap image their instantiation becomes much slower. I think our goal is to try to make sure the cliff is hit as rarely as possible, and using the initial heap size as a gauge instead of a static constant I think will be less surprising in the long run.

We only trim zeros at the end, however

Ah, yes, sorry, you're right here; I had forgotten that we start the mmap from the first nonzero page, but we don't shift the data down to remove the front matter that's never mapped.
So I think my main concern was with very small modules, such that crossing below a 1/2-full threshold results in a sudden degradation. E.g., I have a 128K memory image; I previously had 65K of static data; I remove a few constant arrays, now I'm at 63K, and suddenly my instantiations are a lot slower.
Perhaps we could take some hybrid approach? Images in a "small" category (1MiB or less?) always get to use memfd; that takes care of the above. Then beyond a certain size, we start caring about density, and check for some ratio of nonzero to total pages, as you suggest. Does that seem reasonable?

Seems reasonable to me, I've pushed that as https://github.com/bytecodealliance/wasmtime/pull/3819

authors: alexcrichton cfallin

repo: bytecodealliance/wasmtime


text:
cranelift/x64: Stop cloning Imm8Reg wrappers

A minor cleanup setting up for a larger PR later.

would have also taken "make more things Copy" as a valid path to avoid the clones

I actually want the borrows for later. :grin:


text:
Still not very clear about electron + bytenode

Hi Sir, I had tried your example for Electron. By using 'npm start', the electron window pop out correctly with 'Hello World'. Then I tried to package it by using Electron-packager with the correct electron version (9.4.4), the exe did pop out an electron window but without "Hello World". Did I miss out something?

Try this:
https://github.com/spaceagetv/electron-bytenode-example
more background:
https://www.jjeff.com/blog/2021/4/27/creating-javascript-binaries-for-electron

Same here! I'm tryna build my app via electron-builder and compile the files. I have read about "same binary" stuff and "same version" but is it node or electron or both? I'M HELLA CONFUSED. Please give me an example with electron-builder and bytenode, not electron-forge as I have no experience with that. (I read Jeff's blog as well but I don't know how that is even supposed to work, all I have is an electron app with the builder).
I will try check Electron v17.4.0's node version in case it's different from my dev env version before complaining or sending any updates to this, but I think the formula is node version of dev = node version of client app (bundled w/electron)
As I said, I will try that and if it doesn't work I'll hit you up.

First of all, I have zero experience with both eletcron-forge and electron-builder.
However, with regards to:

I have read about "same binary" stuff and "same version" but is it node or electron or both? I'M HELLA CONFUSED.

This is a simple question. If your .jsc files will be run by electron, then the same electron binary that generates those .jsc file must be used in production. If your .jsc files with be run by node (as if your architecture includes an express server that runs in the background), then the same node that was used to compile your files must be used in production.
In most electron apps you will not use node at all. All your .js and .jsc files will be run inside electron. That is why bytenode cli uses electron internally to compile your code with the flag -e or --electron. Bytenode will use the locally installed version of electron. So, if electron-builder can bundle your app using the same locally installed version of electron, I believe it's easy to figure out how to setup your build routine. (again, I have no experience with all electron stuff! Sorry!).

Hmm, I'm not sure what binary electron-builder uses. But one thing I'm sure of is that I tried to run the compile with npx electron deploy (deploy.js having bytenode.compileFile() in it) and I still get the Incompatible or invalid cached data error after build

If you can make a simple reproducible example (in another issue), I will look into it. But it has to be a complete example that can be run using a simple npm install && npm start.

Alright

I will ask in the electron discord in case anyone knows the solution

Use electron-forge instead of builder

authors: OsamaAbbas jjeff soulkirito z3db0y

repo: bytenode/bytenode


text:
🛑 Tandoor is down

In b44975f, Tandoor ($URL_TANDOOR) was down:

HTTP code: 530
Response time: 37 ms

Resolved: Tandoor is back up in ed63dda.


text:
🛑 www.zisk.eu is down

In b0ca15f, www.zisk.eu (https://www.zisk.eu/sk/Home.alej) was down:

HTTP code: 403
Response time: 898 ms

Resolved: www.zisk.eu is back up in 475fa7e.


text:
better defaults for nested ordered lists (distinguish sublist numerals from parent list numerals)

When describing an ordered sequence of steps (e.g., in pseudocode in a draft), it's nice to present them as an ordered list (e.g. 1,2,3,4) rather than unordered (just bullets).  However, if there are sub-steps in such a presentation, the natural way to present them is with a nested ordered list.  But the nested list restarts with same numbering scheme as the outer list, which is pretty confusing.
For example, this text:
1. bar <- Retrieve config
1. foo <- baz(bar)
1. for qux in foo:
    1. Do thing A(qux)
    1. Do thing B(qux)
1. cleanup

renders as:
   1.  bar <- Retrieve config
   2.  foo <- baz(bar)
   3.  for qux in foo:
       1.  Do thing A(qux)
       2.  Do thing B(qux)
   4.  cleanup

Here are two better ways that it could render:
   1.  bar <- Retrieve config
   2.  foo <- baz(bar)
   3.  for qux in foo:
       3.1.  Do thing A(qux)
       3.2.  Do thing B(qux)
   4.  cleanup

or
   1.  bar <- Retrieve config
   2.  foo <- baz(bar)
   3.  for qux in foo:
       a.  Do thing A(qux)
       b.  Do thing B(qux)
   4.  cleanup

The format of an ordered list can be specified by the type= attribute, please see RFC 7991: The "xml2rfc" Version 3 Vocabulary.
I think what you are asking is a way for the outer list to be parametrized to supply a type= attribute for any inner list, so it does not have to be repeated for each inner list.  It would be easy to add something like type="a" (your second "better way").  Doing something for your first "better way" would require kramdown-rfc to generate the label on the outer list at each point an inner list is encountered (here: something like type="3.%d.", where the 3. is computed from the structure of the outer list, and values of type=, group=, and start=).  Second-guessing xml2rfc to this extent is a bit beyond kramdown-rfc's remit.  But I can certainly think about helping the second "better way" with pseudo-attributes of the form sub-type, sub-sub-type etc. that get inherited as type and sub-type to the next inner list.

@cabo if there is a way to do that from kramdown-rfc, that would be great.  You mention it as a way to parameterize the outer list itself, which would definitely be useful.  Even more useful (and simple, for my purposes) would be a document-wide setting that applies to all nested, ordered lists.
What i would like ideally is something in the YAML metadata block like:
nested-ordered-types: 1 a i A I

which would make the top-level ordered list type='1',  and the next-level ordered list type='a'.

Will the code need to consider intervening unordered lists?  Or can we start at 1 again if that happens?
1. one
2. two
   - two-left
      a. two-left-a
      b. two-left-b
   - two-right

nested-ordered-types: 1 a i A I

Those types can contain spaces, so a space-separated list won't work too well.  Probably needs to be

nested-ordered-types: ["1", a, i, A, I]

Will the code need to consider intervening unordered lists? Or can we start at 1 again if that happens?

I don't have much of an opinion here -- that seems pretty weird to me, if i'm doing nested ordered lists it's probably because i want to be able to refer to a particular sub-sub-*-item by its coordinates (e.g., "clause 3(b)iii", the way people talk about US legislation) , and i don't see how an intervening unordered list would fit in here.
I'd be fine with any of the following three choices:

an intervening unordered list is simply ignored.  So with ["1",a,i] and an ordered,unordered,ordered nesting, the first ordered would be "1", and the second ordered would be "a"
an intervening unordered list silently consumes a level of the hierarchy.  So with the same example, the first ordered would be "1" and the second ordered would be "i".
an intervening unordered list resets the rankings.  So with the same example, the first ordered would be "1" and the second ordered would also be "1".

OK, implementation-wise your number 1 (see what I did here :-) seems easiest.
It is also probably easiest to roll through the array, i.e., putting the shifted off current value back in at the end for the nested items.
Default then can simply be ["1"].

Is there a reason why we're not trying to follow what would happen from CommonMark? CommonMark puts out HTML, but we can follow how it does levels and nesting instead of inventing our own way.

On 19. Apr 2024, at 19:33, Paul Hoffman @.***> wrote:

Is there a reason why we're not trying to follow what would happen from CommonMark?

Yes.
Kramdown-rfc is based on kramdown, which is a dialect that was formed before common mark made decisions, often incompatible with existing markdown dialects.
In the hierarchy of objectives for kramdown-rfc, stability is very high, because I-Ds are often “dusty decks” that should continue to work after periods of time that are natural in the IETF, e.g., half a decade.
Where these considerations do not get in the way (and adding a YAML control certainly doesn’t), we can innovate.

CommonMark puts out HTML, but we can follow how it does levels and nesting instead of inventing our own way.

As far as I know, commonmark doesn’t do anything useful in the area of labeling nested ordered lists, or actually even in the way of supporting different numbering styles for single-level lists.
RFCXMLv3 has type=, so we are covered by using an IAL.
What is proposed here is to add some automation that would generate this attribute.
(Commonmark does do one thing that doesn’t have to do with nesting, which is extracting start numbers — that would be a great feature to have, but unfortunately it won’t be part of kramdown 1.
Well, we do have the start= attribute in RFCXMLv3 as well, and that can be addressed with an IAL, as can be group= for continuing numbering across interruptions.
Commonmark also has a broken 2 concept of tight vs. loose lists.
RFCXMLv3 has spacing=, which again can be accessed via an IAL.)
Grüße, Carsten

I have written the code, but
https://github.com/ietf-tools/xml2rfc/issues/1122
Will push this anyway after some more testing.

Now in 1.7.9:
1.7.9 Add option nested_ol_types
Set globally in {::options nested_ol_types="1, i, a" /} (markdown, not YAML header)
or for a single <ol in an IAL {: nested_ol_types="1 (%i) A"}
The value needs to be an array of <ol type= values, expressed as one of:

A YAML array
A string that will be split on commas (with optional blank space following)
A string that will be split on blank space

When testing this, an HTML rendering issue might cause some confusion:
https://github.com/ietf-tools/xml2rfc/issues/1122

1.7.10 now also takes nested_ol_types from YAML kramdown_options
As in
kramdown_options:
  nested_ol_types: 1, i, a

(overridden by ::options and by pseudo-attribute on <ol)

1.7.11 now also takes an option ol_start_at_first_marker
As in
kramdown_options:
  ol_start_at_first_marker: true

Default: false (for kramdown-rfc backward compatibility)
If true, an ordered list (<ol) will use the number in its first
marker (1 for 1. etc.) as the default value of the start= attribute.
(This increases commonmark compatibility, see https://github.com/cabo/kramdown-rfc/issues/227#issuecomment-2067148163)

I think the recent changes should address both the original observation and the discussion, so please close this if this works for you.
https://github.com/ietf-tools/xml2rfc/issues/1122 remains though, for now.

This works great.  Thank you, @cabo! Much appreciated.

authors: cabo dkg paulehoffman

repo: cabo/kramdown-rfc


text:
🛑 CBTB Coffee House Shop is down

In 07bf8ab, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1142 ms

Resolved: CBTB Coffee House Shop is back up in f127209.

repo: cachetech/service-status


text:
🛑 CBTB Coffee House Shop is down

In e5cfaa5, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1392 ms

Resolved: CBTB Coffee House Shop is back up in 12efe77.


text:
🛑 CBTB Coffee House Shop is down

In 20368f6, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 898 ms

Resolved: CBTB Coffee House Shop is back up in 4678790.


text:
🛑 CBTB Coffee House Shop is down

In c3d59e7, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 886 ms

Resolved: CBTB Coffee House Shop is back up in f19fb86 after 26 minutes.


text:
🛑 CBTB Coffee House Shop is down

In 82e7fbf, CBTB Coffee House Shop (https://shop.cbtb.coffee/) was down:

HTTP code: 403
Response time: 1133 ms

Resolved: CBTB Coffee House Shop is back up in 05abe7f after 28 minutes.


text:
load-exports missing after init with flake-parts

Describe the bug
I get .devenv/load-exports: No such file or directory upon entering a devenv environment.
Nix 2.22.3 on NixOS 24.05
To reproduce
In a blank git repo:
$ nix flake init --template github:cachix/devenv#flake-parts
wrote: /home/mauricio/prg/elevate/strawberry-sqlalchemy-issue/flake.nix
wrote: /home/mauricio/prg/elevate/strawberry-sqlalchemy-issue/.envrc
wrote: /home/mauricio/prg/elevate/strawberry-sqlalchemy-issue/.gitignore

.devenv should be added to .gitignore

      |   echo .devenv >> .gitignore

$ echo .devenv >> .gitignore
$ nix develop --impure
warning: Git tree '/home/mauricio/prg/elevate/strawberry-sqlalchemy-issue' is dirty
warning: creating lock file '/home/mauricio/prg/elevate/strawberry-sqlalchemy-issue/flake.lock':
• Added input 'devenv':
    'github:cachix/devenv/ebd3f5f20a520bf948b143262c96fc59f412e0b3?narHash=sha256-/jV1XMb9baMuD1mnCaDo2KL/28HHLJ9qhEfJIMr%2Bfb8%3D' (2024-09-25)
• Added input 'devenv/cachix':
    'github:cachix/cachix/03b6cb3f953097bff378fb8b9ea094bd091a4ec7?narHash=sha256-6u2DycIEgrgNYlLxyGqdFVmBNiKIitnQKJ1pbRP5oko%3D' (2024-08-21)
• Added input 'devenv/cachix/devenv':
    'github:cachix/devenv/ff5eb4f2accbcda963af67f1a1159e3f6c7f5f91?narHash=sha256-0JrfahRMJ37Rf1i0iOOn%2B8Z4CLvbcGNwa2ChOAVrp/8%3D' (2024-08-08)
• Added input 'devenv/cachix/devenv/cachix':
    'github:cachix/cachix/02e38da89851ec7fec3356a5c04bc8349cae0e30?narHash=sha256-7FcfMm5A/f02yyzuavJe06zLa9hcMHsagE28ADcmQvk%3D' (2024-04-02)
• Added input 'devenv/cachix/devenv/cachix/devenv':
    'github:cachix/devenv/2ee4450b0f4b95a1b90f2eb5ffea98b90e48c196?narHash=sha256-w%2BdOIW60FKMaHI1q5714CSibk99JfYxm0CzTinYWr%2BQ%3D' (2024-02-23)
• Added input 'devenv/cachix/devenv/cachix/devenv/flake-compat':
    follows 'devenv/cachix/devenv/cachix/flake-compat'
• Added input 'devenv/cachix/devenv/cachix/devenv/nix':
    'github:domenkozar/nix/b24a9318ea3f3600c1e24b4a00691ee912d4de12?narHash=sha256-BGvBhepCufsjcUkXnEEXhEVjwdJAwPglCC2%2BbInc794%3D' (2024-04-12)
• Added input 'devenv/cachix/devenv/cachix/devenv/nix/flake-compat':
    'github:edolstra/flake-compat/35bb57c0c8d8b62bbfd284272c928ceb64ddbde9?narHash=sha256-4gtG9iQuiKITOjNQQeQIpoIB6b16fm%2B504Ch3sNKLd8%3D' (2023-01-17)
• Added input 'devenv/cachix/devenv/cachix/devenv/nix/nixpkgs':
    follows 'devenv/cachix/devenv/cachix/devenv/nixpkgs'
• Added input 'devenv/cachix/devenv/cachix/devenv/nix/nixpkgs-regression':
    'github:NixOS/nixpkgs/215d4d0fd80ca5163643b03a33fde804a29cc1e2?narHash=sha256-uGJ0VXIhWKGXxkeNnq4TvV3CIOkUJ3PAoLZ3HMzNVMw%3D' (2022-01-24)
• Added input 'devenv/cachix/devenv/cachix/devenv/nixpkgs':
    'github:NixOS/nixpkgs/9201b5ff357e781bf014d0330d18555695df7ba8?narHash=sha256-x9Opq06rIiwdwGeK2Ykj69dNc2IvUH1fY55Wm7atwrE%3D' (2023-08-23)
• Added input 'devenv/cachix/devenv/cachix/devenv/poetry2nix':
    'github:nix-community/poetry2nix/d5006be9c2c2417dafb2e2e5034d83fabd207ee3?narHash=sha256-IXfZEkI0Mal5y1jr6IRWMqK8GW2/f28xJenZIPQqkY0%3D' (2023-08-24)
• Added input 'devenv/cachix/devenv/cachix/devenv/poetry2nix/flake-utils':
    'github:numtide/flake-utils/919d646de7be200f3bf08cb76ae1f09402b6f9b4?narHash=sha256-6ixXo3wt24N/melDWjq70UuHQLxGV8jZvooRanIHXw0%3D' (2023-07-11)
• Added input 'devenv/cachix/devenv/cachix/devenv/poetry2nix/flake-utils/systems':
    'github:nix-systems/default/da67096a3b9bf56a91d16901293e51ba5b49a27e?narHash=sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768%3D' (2023-04-09)
• Added input 'devenv/cachix/devenv/cachix/devenv/poetry2nix/nix-github-actions':
    'github:nix-community/nix-github-actions/165b1650b753316aa7f1787f3005a8d2da0f5301?narHash=sha256-4UYkifnPEw1nAzqqPOTL2MvWtm3sNGw1UTYTalkTcGY%3D' (2023-07-09)
• Added input 'devenv/cachix/devenv/cachix/devenv/poetry2nix/nix-github-actions/nixpkgs':
    follows 'devenv/cachix/devenv/cachix/devenv/poetry2nix/nixpkgs'
• Added input 'devenv/cachix/devenv/cachix/devenv/poetry2nix/nixpkgs':
    follows 'devenv/cachix/devenv/cachix/devenv/nixpkgs'
• Added input 'devenv/cachix/devenv/cachix/devenv/pre-commit-hooks':
    follows 'devenv/cachix/devenv/cachix/pre-commit-hooks'
• Added input 'devenv/cachix/devenv/cachix/flake-compat':
    follows 'devenv/cachix/devenv/flake-compat'
• Added input 'devenv/cachix/devenv/cachix/nixpkgs':
    follows 'devenv/cachix/devenv/nixpkgs'
• Added input 'devenv/cachix/devenv/cachix/pre-commit-hooks':
    follows 'devenv/cachix/devenv/pre-commit-hooks'
• Added input 'devenv/cachix/devenv/flake-compat':
    follows 'devenv/cachix/flake-compat'
• Added input 'devenv/cachix/devenv/nix':
    'github:domenkozar/nix/b24a9318ea3f3600c1e24b4a00691ee912d4de12?narHash=sha256-BGvBhepCufsjcUkXnEEXhEVjwdJAwPglCC2%2BbInc794%3D' (2024-04-12)
• Added input 'devenv/cachix/devenv/nix/flake-compat':
    follows 'devenv/cachix/devenv/flake-compat'
• Added input 'devenv/cachix/devenv/nix/nixpkgs':
    follows 'devenv/cachix/devenv/nixpkgs'
• Added input 'devenv/cachix/devenv/nix/nixpkgs-regression':
    'github:NixOS/nixpkgs/215d4d0fd80ca5163643b03a33fde804a29cc1e2?narHash=sha256-uGJ0VXIhWKGXxkeNnq4TvV3CIOkUJ3PAoLZ3HMzNVMw%3D' (2022-01-24)
• Added input 'devenv/cachix/devenv/nixpkgs':
    follows 'devenv/cachix/nixpkgs'
• Added input 'devenv/cachix/devenv/pre-commit-hooks':
    follows 'devenv/cachix/git-hooks'
• Added input 'devenv/cachix/flake-compat':
    follows 'devenv/flake-compat'
• Added input 'devenv/cachix/git-hooks':
    follows 'devenv/pre-commit-hooks'
• Added input 'devenv/cachix/nixpkgs':
    follows 'devenv/nixpkgs'
• Added input 'devenv/flake-compat':
    'github:edolstra/flake-compat/0f9255e01c2351cc7d116c072cb317785dd33b33?narHash=sha256-kvjfFW7WAETZlt09AgDn1MrtKzP7t90Vf7vypd3OL1U%3D' (2023-10-04)
• Added input 'devenv/nix':
    'github:domenkozar/nix/1e61e9f40673f84c3b02573145492d8af581bec5?narHash=sha256-uDwWyizzlQ0HFzrhP6rVp2%2B2NNA%2B/TM5zT32dR8GUlg%3D' (2024-09-10)
• Added input 'devenv/nix/flake-compat':
    follows 'devenv/flake-compat'
• Added input 'devenv/nix/flake-parts':
    'github:hercules-ci/flake-parts/9126214d0a59633752a136528f5f3b9aa8565b7d?narHash=sha256-sB4SWl2lX95bExY2gMFG5HIzvva5AVMJd4Igm%2BGpZNw%3D' (2024-04-01)
• Added input 'devenv/nix/flake-parts/nixpkgs-lib':
    follows 'devenv/nix/nixpkgs'
• Added input 'devenv/nix/libgit2':
    'github:libgit2/libgit2/45fd9ed7ae1a9b74b957ef4f337bc3c8b3df01b5?narHash=sha256-oX4Z3S9WtJlwvj0uH9HlYcWv%2Bx1hqp8mhXl7HsLu2f0%3D' (2023-10-18)
• Added input 'devenv/nix/nixpkgs':
    'github:NixOS/nixpkgs/88269ab3044128b7c2f4c7d68448b2fb50456870?narHash=sha256-%2Bf9c4/ZX5MWDOuB1rKoWj%2BlBNm0z0rs4CK47HBLxy1o%3D' (2024-06-03)
• Added input 'devenv/nix/nixpkgs-23-11':
    'github:NixOS/nixpkgs/a62e6edd6d5e1fa0329b8653c801147986f8d446?narHash=sha256-oamiKNfr2MS6yH64rUn99mIZjc45nGJlj9eGth/3Xuw%3D' (2024-05-31)
• Added input 'devenv/nix/nixpkgs-regression':
    'github:NixOS/nixpkgs/215d4d0fd80ca5163643b03a33fde804a29cc1e2?narHash=sha256-uGJ0VXIhWKGXxkeNnq4TvV3CIOkUJ3PAoLZ3HMzNVMw%3D' (2022-01-24)
• Added input 'devenv/nix/pre-commit-hooks':
    'github:cachix/pre-commit-hooks.nix/40e6053ecb65fcbf12863338a6dcefb3f55f1bf8?narHash=sha256-nMirxrGteNAl9sWiOhoN5tIHyjBbVi5e2tgZUgZlK3Y%3D' (2024-04-12)
• Added input 'devenv/nix/pre-commit-hooks/flake-compat':
    follows 'devenv/nix'
• Added input 'devenv/nix/pre-commit-hooks/flake-utils':
    'github:numtide/flake-utils/5aed5285a952e0b949eb3ba02c12fa4fcfef535f?narHash=sha256-nuEHfE/LcWyuSWnS8t12N1wc105Qtau%2B/OdUAjtQ0rA%3D' (2022-11-02)
• Added input 'devenv/nix/pre-commit-hooks/gitignore':
    follows 'devenv/nix'
• Added input 'devenv/nix/pre-commit-hooks/nixpkgs':
    follows 'devenv/nix/nixpkgs'
• Added input 'devenv/nix/pre-commit-hooks/nixpkgs-stable':
    follows 'devenv/nix/nixpkgs'
• Added input 'devenv/nixpkgs':
    'github:cachix/devenv-nixpkgs/4267e705586473d3e5c8d50299e71503f16a6fb6?narHash=sha256-Q1UQzYcMJH4RscmpTkjlgqQDX5yi1tZL0O345Ri6vXQ%3D' (2024-05-29)
• Added input 'devenv/pre-commit-hooks':
    'github:cachix/pre-commit-hooks.nix/7570de7b9b504cfe92025dd1be797bf546f66528?narHash=sha256-tyMUA6NgJSvvQuzB7A1Sf8%2B0XCHyfSPRx/b00o6K0uo%3D' (2024-09-05)
• Added input 'devenv/pre-commit-hooks/flake-compat':
    follows 'devenv/flake-compat'
• Added input 'devenv/pre-commit-hooks/gitignore':
    'github:hercules-ci/gitignore.nix/637db329424fd7e46cf4185293b9cc8c88c95394?narHash=sha256-HG2cCnktfHsKV0s4XW83gU3F57gaTljL9KNSuG6bnQs%3D' (2024-02-28)
• Added input 'devenv/pre-commit-hooks/gitignore/nixpkgs':
    follows 'devenv/pre-commit-hooks/nixpkgs'
• Added input 'devenv/pre-commit-hooks/nixpkgs':
    follows 'devenv/nixpkgs'
• Added input 'devenv/pre-commit-hooks/nixpkgs-stable':
    'github:NixOS/nixpkgs/194846768975b7ad2c4988bdb82572c00222c0d7?narHash=sha256-NGKVY4PjzwAa4upkGtAMz1npHGoRzWotlSnVlqI40mo%3D' (2024-07-07)
• Added input 'devenv-root':
    'file:///dev/null?narHash=sha256-d6xi4mKdjkX2JFicDIv5niSzpyI0m/Hnm8GGAIU04kY%3D'
• Added input 'flake-parts':
    'github:hercules-ci/flake-parts/bcef6817a8b2aa20a5a6dbb19b43e63c5bf8619a?narHash=sha256-HO4zgY0ekfwO5bX0QH/3kJ/h4KvUDFZg8YpkNwIbg1U%3D' (2024-09-12)
• Added input 'flake-parts/nixpkgs-lib':
    'https://github.com/NixOS/nixpkgs/archive/356624c12086a18f2ea2825fed34523d60ccc4e3.tar.gz?narHash=sha256-Ss8QWLXdr2JCBPcYChJhz4xJm%2Bh/xjl4G0c0XlP6a74%3D' (2024-09-01)
• Added input 'mk-shell-bin':
    'github:rrbutani/nix-mk-shell-bin/ff5d8bd4d68a347be5042e2f16caee391cd75887?narHash=sha256-/uEkr1UkJrh11vD02aqufCxtbF5YnhRTIKlx5kyvf%2BI%3D' (2023-02-21)
• Added input 'nix2container':
    'github:nlewo/nix2container/fa6bb0a1159f55d071ba99331355955ae30b3401?narHash=sha256-njRK9vvZ1JJsP8oV2OgkBrpJhgQezI03S7gzskCcHos%3D' (2024-08-30)
• Added input 'nix2container/flake-utils':
    'github:numtide/flake-utils/b1d9ab70662946ef0850d488da1c9019f3a9752a?narHash=sha256-SZ5L6eA7HJ/nmkzGG7/ISclqe6oZdOZTNoesiInkXPQ%3D' (2024-03-11)
• Added input 'nix2container/flake-utils/systems':
    'github:nix-systems/default/da67096a3b9bf56a91d16901293e51ba5b49a27e?narHash=sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768%3D' (2023-04-09)
• Added input 'nix2container/nixpkgs':
    follows 'nixpkgs'
• Added input 'nixpkgs':
    'github:cachix/devenv-nixpkgs/4267e705586473d3e5c8d50299e71503f16a6fb6?narHash=sha256-Q1UQzYcMJH4RscmpTkjlgqQDX5yi1tZL0O345Ri6vXQ%3D' (2024-05-29)
warning: Git tree '/home/mauricio/prg/elevate/strawberry-sqlalchemy-issue' is dirty
Running tasks     devenv:enterShell

Failed            devenv:enterShell 4ms
1 Failed                            50.74ms

--- devenv:enterShell failed with error: Task exited with status: exit status: 1
--- devenv:enterShell stdout:
--- devenv:enterShell stderr:
0000.05: /nix/store/aand0xnzbwy486cq7wfbm72z39f9akg3-devenv-enterShell: line 2: /home/mauricio/prg/elevate/strawberry-sqlalchemy-issue/.devenv/load-exports: No such file or directory
0000.05: chmod: cannot access '/home/mauricio/prg/elevate/strawberry-sqlalchemy-issue/.devenv/load-exports': No such file or directory
---

Hello, world!
(devenv)
$

Using devenv with nix flake having the same issue. Although I noticed that it only happens when entering the shell for the first time

After some digging it appears that this change might be causing the issue, the .devenv directory is not created but the script tries to write to .devenv/load-exports.

authors: mausch mirza-src

repo: cachix/devenv


text:
basicauth  can not work normally

Hello, I use this configuration for proxy authentication. After entering the correct account and password, it still prompts that the authentication fails, and the authentication function cannot be used. Can you help me solve it?
0.0.0.0:80 {
log access.log
errors error.log  {
  401 /usr/local/www/aaa.html
  404 /usr/local/www/aaa.html
}

forwardproxy {
  basicauth user 123456
  hide_ip
  hide_via
}

}

I suspect this is a client-side issue. What client are you using? Does SwitchyOmega work for you?

repo: caddyserver/forwardproxy


text:
java.lang.NullPointerException: Cannot invoke "net.minecraft.class_2874.comp_651()" because "this.dimensionType" is null

What happened?
Game crashed
Minecraft Version
1.20.1
Modloader (Fabric/Forge)
Fabric
World-Preview Version
1.1.5
Minecraft Logs
https://paste.ubuntu.com/p/bv6WzKtP8C/
Additional Information
No response

I am unable to reproduce this in vanilla + fabric API + World Preview --> This is likely a compatibility issue with another mod. Are you using a public mod pack I can download to reproduce this? Alternatively, could you please try finding out witch mod specifically causes this behavior?
I have created a build that should at least fix the NullPointerException: world_preview.zip. Could you please check build fixes the issue or if there are other issues?

Should be fixed with 1.2.0

authors: ZekerZhayard caeruleusDraconis

repo: caeruleusDraconis/world-preview