Alpine Linux Edge: musl version can contain underscore, which is not semver-compliant

This package currently assumes that musl uses semver, but it looks like this might not always be the case.
https://gitlab.alpinelinux.org/alpine/aports/-/commit/bd758e828afaa840262f174077c151cd9c5ded04
# apk list musl
musl-1.2.3_git20230411-r0 x86_64 {musl} (MIT) [installed]
# node -p "require('detect-libc').versionSync()"
1.2.3_git20230411

Originally reported at https://github.com/lovell/sharp/issues/3641

Added note about this to docs via https://github.com/lovell/detect-libc/commit/d4fd20757fac8b6f09dc1ebe706f49698475505c


how to finetune in single gpu

cd finetune && deepspeed finetune_deepseekcoder.py     --model_name_or_path $MODEL_PATH     --data_path $DATA_PATH     --output_dir $OUTPUT_PATH     --num_train_epochs 3     --model_max_length 1024     --per_device_train_batch_size 16     --per_device_eval_batch_size 1     --gradient_accumulation_steps 4     --evaluation_strategy "no"     --save_strategy "steps"     --save_steps 100     --save_total_limit 100     --learning_rate 2e-5     --warmup_steps 10     --logging_steps 1     --lr_scheduler_type "cosine"     --gradient_checkpointing True     --report_to "tensorboard"     --deepspeed configs/ds_config_zero3.json     --bf16 True
[2023-12-19 16:10:57,887] [INFO] [real_accelerator.py:161:get_accelerator] Setting ds_accelerator to cuda (auto detect)
/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/torch/cuda/init.py:138: UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 11070). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at ../c10/cuda/CUDAFunctions.cpp:108.)
return torch._C._cuda_getDeviceCount() > 0
[2023-12-19 16:11:06,596] [WARNING] [runner.py:202:fetch_hostfile] Unable to find hostfile, will proceed with training with local resources only.
[2023-12-19 16:11:06,596] [INFO] [runner.py:570:main] cmd = /home/admin/miniconda3/envs/deepseek/bin/python -u -m deepspeed.launcher.launch --world_info=eyJsb2NhbGhvc3QiOiBbMF19 --master_addr=<IP_ADDRESS> --master_port=29500 --enable_each_rank_log=None finetune_deepseekcoder.py --model_name_or_path deepseek-ai/deepseek-coder-6.7b-instruct --data_path ../data/nickroshEvol-Instruct-Code-80k-v1/EvolInstruct-Code-80k.json --output_dir ./outputs --num_train_epochs 3 --model_max_length 1024 --per_device_train_batch_size 16 --per_device_eval_batch_size 1 --gradient_accumulation_steps 4 --evaluation_strategy no --save_strategy steps --save_steps 100 --save_total_limit 100 --learning_rate 2e-5 --warmup_steps 10 --logging_steps 1 --lr_scheduler_type cosine --gradient_checkpointing True --report_to tensorboard --deepspeed configs/ds_config_zero3.json --bf16 True
[2023-12-19 16:11:12,734] [INFO] [real_accelerator.py:161:get_accelerator] Setting ds_accelerator to cuda (auto detect)
/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/torch/cuda/init.py:138: UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 11070). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at ../c10/cuda/CUDAFunctions.cpp:108.)
return torch._C._cuda_getDeviceCount() > 0
[2023-12-19 16:11:16,782] [INFO] [launch.py:145:main] WORLD INFO DICT: {'localhost': [0]}
[2023-12-19 16:11:16,782] [INFO] [launch.py:151:main] nnodes=1, num_local_procs=1, node_rank=0
[2023-12-19 16:11:16,782] [INFO] [launch.py:162:main] global_rank_mapping=defaultdict(<class 'list'>, {'localhost': [0]})
[2023-12-19 16:11:16,782] [INFO] [launch.py:163:main] dist_world_size=1
[2023-12-19 16:11:16,782] [INFO] [launch.py:165:main] Setting CUDA_VISIBLE_DEVICES=0
/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/torch/cuda/init.py:138: UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 11070). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at ../c10/cuda/CUDAFunctions.cpp:108.)
return torch._C._cuda_getDeviceCount() > 0
[2023-12-19 16:11:28,688] [INFO] [real_accelerator.py:161:get_accelerator] Setting ds_accelerator to cuda (auto detect)
[2023-12-19 16:11:30,064] [INFO] [comm.py:637:init_distributed] cdb=None
[2023-12-19 16:11:30,065] [INFO] [comm.py:668:init_distributed] Initializing TorchBackend in DeepSpeed with backend nccl
Traceback (most recent call last):
File "/workspace/workdir/tevs_multi_idc_10g_20220825163730/lyq/DeepSeek-Coder/finetune/finetune_deepseekcoder.py", line 193, in
train()
File "/workspace/workdir/tevs_multi_idc_10g_20220825163730/lyq/DeepSeek-Coder/finetune/finetune_deepseekcoder.py", line 123, in train
model_args, data_args, training_args = parser.parse_args_into_dataclasses()
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/transformers/hf_argparser.py", line 338, in parse_args_into_dataclasses
obj = dtype(**inputs)
File "", line 123, in init
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/transformers/training_args.py", line 1493, in post_init
and (self.device.type != "cuda")
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/transformers/training_args.py", line 1941, in device
return self._setup_devices
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/transformers/utils/generic.py", line 54, in get
cached = self.fget(obj)
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/transformers/training_args.py", line 1867, in _setup_devices
self.distributed_state = PartialState(timeout=timedelta(seconds=self.ddp_timeout))
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/accelerate/state.py", line 183, in init
dist.init_distributed(dist_backend=self.backend, auto_mpi_discovery=False, **kwargs)
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/deepspeed/comm/comm.py", line 670, in init_distributed
cdb = TorchBackend(dist_backend, timeout, init_method, rank, world_size)
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/deepspeed/comm/torch.py", line 120, in init
self.init_process_group(backend, timeout, init_method, rank, world_size)
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/deepspeed/comm/torch.py", line 146, in init_process_group
torch.distributed.init_process_group(backend,
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/torch/distributed/c10d_logger.py", line 74, in wrapper
func_return = func(*args, **kwargs)
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 1148, in init_process_group
default_pg, _ = _new_process_group_helper(
File "/home/admin/miniconda3/envs/deepseek/lib/python3.10/site-packages/torch/distributed/distributed_c10d.py", line 1279, in _new_process_group_helper
backend_class = ProcessGroupNCCL(backend_prefix_store, group_rank, group_size, pg_options)
RuntimeError: ProcessGroupNCCL is only supported with GPUs, no GPUs found!

It seems your environment has no gpu device.


Connect Postgres DB

How to connect the Postgres DB with PEV?

Sorry misunderstood. The input JSON can be get from psql command line only. will close this issue.


[Bug]  Weird behavior with custom rings

This is going to be not very productive bug report, because I don't know how to reliably replicate this starting on new fresh system.
I have set up new world, enabled modules for it, and then I wanted to change token ring. And it kinda worked. But not really. I was able to change ring, but then when I change scene, or  refresh game, ring gets corrupted like in attached screens- it's like it's using map of custom ring, instead of properly adjusting ring size.
Originally I've been trying to use Glided Black Marble Ring, but at first it hasn't noticed that I selected it, so I chosen something else instead- and then it shows two checkboxes next to name- Marble one, and Runes Ring Black- that I've made scrrnshot with.
In next step, I've tried to make custom ring with my own graphics- and behavior is similar (image gets corrupted on scene change/refresh- but no submitted ring is marked as used.
I don't know what caused this, I have no idea what could have originally corrupted this.
For the environment-
game hosted on Forge,
Foundry 12.331
DnD 3.3.1
SETT 0.4.11
List of all active modules:
PackageList.json
To Reproduce
Steps to reproduce the behavior:
Described above- can't fully replicate from scratch on fresh system.
Expected behavior
I just expected that custom Dynamic Ring will work correctly.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

That's soo weird wth XD
It looks like as you said its just grabbing the spritesheet directly and not using the size mapping.
Only thing I can think is that either:

Somehow your download of the module got corrupted (this has happened to me on rare occasions)
Somehow the files transferred weirdly when you went to reload.

Followup questions

Is this still happening even after an attempted reinstall of the module?
What browser + version do you have (this one is grasping at straws a bit)

It seems that module indeed got corrupted in some way- I removed it and installed again, and everything works correctly.
And for the browser, if you want to look at it more, I'm using up to date version of Chrome.
Since it seems like module got currupted, and reinstal fixed everything, I'd say it's very low priority to "can be closed now, not an issue" problem :)

Cool I'll close it and mark it as like "May Come up again", thanks for the bug report!

I lied. I can replicate it again.
After previous response, I've checked one more thing that I didn't think it mattered.
Together with reinstalling module, I also updated DnD to 4.0.2.
And correct behavior was on 4.0.2.
In the meantime I reverted system to 3.3.1, and bug still persists.
Steps I performed, because it can be confusing from the description above.
Yesterday I reported error.
Today I updated DnD to 4.0.2, and reinstalled SETT.
Everything worked.
Then I reverted to 3.3.1
Bug returned.
I reinstalled SETT again, stopped and started server, and launched world again- bug still persists.
Since I realised that some modules I want aren't compatible with 4.X now, I'll be probably staying on 3.3.1 for some time, so I can do some additional checks if something is needed.

I've run the find the Culprit check, and it doesn't seem like it's caused by anything else that's active

All other modules are libraries, and don't do anything on their own

Hmmm that's weird. Maybe DND 4.x.x messes with it. Not too familiar with the system after I jumped ship, but AFAIK they made drastic changes between versions

The thing is, 3.3.1 is causing problems, after change to 4.0.2 it worked okay.

I get a similar bug. It works until you return to setup. Then I get a distorted ring. Almost as if it's picking up the wrong area of the sprite sheet. Only creating a new token ring will fish the issue until you return to setup then the issue starts again.
NB. Splitting the large and huge into two entries in the JSON and resizing the grid start fixes the issue for large tokens.

Oh it might be a 5e specific issue due to how the rings are labelled?

not really familiar with the system anymore, @Stonedtroll could you send a copy of the modified JSON and i can see if i can fix the underlying json data to work with 5e?

Here it is. Please note that not all the sizes are working.
custom-ring-mod.json

Just an update. Your instinct was right. When I match the labels in the custom JSON to what the system provided JSON uses, it works.

Since this issue apparently is replicable, and it seems that we've got solution, would it be possible to get this bug fixed?

I think i need some more details, @Stonedtroll what specific labels are wrong between the two?

I'm afraid my memory is a bit vague on this. I know you have less sizes than the standard. You also named them differently. The ring size entry did not change even when the ring was bigger as well. Those were the three things that I can remember I had changed.

Sorry that I'm responding after such long time, but I kinda hoped that @Stonedtroll knows topic better.
I have downloaded both ring jsons- yours and the one from dnd system.
I can see that there are some differences in the formats, but it's hard to say what is impactful and what's not.
THe attached file is from 4.1.0 version, but I can see that it hasn't changed for 10 months, so it was like that in 3.3.1 that I've been using while originally bringing the issue.
Hopefully these files are going to help you  to at least some degree.
rings-chasarooni;-abomination-vaults-ring.json
token-rings.json

All good, cool this should be enough to work with hopefully. I'll look into fixing it when I can

Looked at both rings @picollo-24 not sure this is an issue on my end but more on how 5e handles the ring data. Currently the only substantial difference besides formatting is "gridTarget" variable for each ring and the "ringThickness" both if which are features of the JSON language as far as I've been told by foundry people.
Maybe worth bring this up as an issue to them? @picollo-24 as I can't replicate it on my end in another system

I checked one more thing ( sorry for being PITA)
I looked at stonedtroll's json, and it looks differently than the one I've provided. Haven't verified it previously, I assumed that these were the same things, but apparently they're not.
If you compare  the custom-ring-mod.json with both I've pasted, there are some differences.
troll's one starts at grid size 4, other start at 3, and they have  separate large and huge size, while yours has large-huge setting clumped together.
Maybe that's the issue?

@picollo-24, this is the json I ended up building and it has worked flawlessly.
Thanks for solving this annoying issue!


Update README.metadata.json files using script

Hi both,
as discussed here is a big PR to update all available README.metadata.json files, using a script to get the information from the file structure and from the README.md itself.
Unfortunately these changes end up in the git diff as the whole file being changed. Don't worry, not actually that much has changed (see below). I believe this is because of a change in encoding?
I think a good solution would be to probably only review 1 file from each category, and trust the script to do the rest properly. The main thing to look out for is probably mistakes in data scraping/ unusual characters or formatting, etc. The content is all straight from the README.md so I wouldn't worry about reviewing it here.
As mentioned below, integrated_windows_authentication is a good candidate for checking the script has done it's job properly, as it has many .java/.fxml files.
Probably also good to look at some files with .gif in the readme (e.g. offline routing)
Also noticed an unusual entry in:
analysis/viewshed-geoelement/README.metadata.json
The 'RelevantAPI' section has: GeometryEngine.distanceGeodetic (used to animate the vehicle). @Rachael-E I'm going to guess this has no place in the README.metadata.json. I'll try and add a regex to search for any text in brackets and get rid of it. (see appropriate commit)
A quick overview:

category: should be unchanged
description: is scraped straight from the second line of the README.md, might change in some instances where we didn't have the two files in sync
ignore: is always false
images: Should essentially be unchanged. It is scraped from the README.md, meaning if the readme shows a gif, the metadata shows a gif (unless the files were out of sync).
keywords: a combination of the 'tags' in the REAMDE.md and the 'RELEVANT API' in the README.md. We've previously missed out on adding the API into this section, but it's definitely required. The tags are alphabetised, followed by the API, also alphabetised.
redirect_from: should be unchanged
relevant_apis: from the 'Relevant API' in the README.md
snippets: all .java and .fxml files from the file structure, with the exception of *Launcher.java files.
An interesting case to look at here is integrated_windows_authentication (several .java and .fxml files)
title: scraped from the README.md

Thanks for the review @Rachael-E ! Nice work on finding some missed details from the readme updates 😄
Care to have another look?

Thanks for the review @Rachael-E ! Nice work on finding some missed details from the readme updates 😄
Care to have another look?

thanks @jf990 for clearing that up!

Thanks @jf990 @Rachael-E @mikewilburn for clarifying the requirements for 'redirect_from'.
All updated now. I'll modify the metadata script as well to make this into an empty string.


Conflict with Prototype.js

When I call the D3 nest() function with an array of objects, it chokes on the inherited crap from Prototype which causes infinite recursion. If I don't include the Prototype.js, everything works fine.
How can I get the nest() function to ignore this stuff?

I'm not sure; I don't use Prototype.

And, if you want help, please send an example of the breakage to the d3-js Google group.


Overlapping of Video Sounds

Each time the video story is opened, so many sounds overlap.
Can this situation be fixed easily?

Hi alicankurt1
Could you please provide example

Ofcourse,
https://youtube.com/shorts/eSdfcd7Xk68?feature=share
When I close the Story and open it again and again, the same problem occurs.

Hi Iskender,
Were you able to detect the problem?

Hi @alicankurt1
sorry for late response mean time i have fixed video overlapping problem and relaesed version 1.1.0 have fun


Remove NUL padding when reading secrets from stdin

Depending on the length of input, it seems the backing byte array in the ByteBuffer that holds the UTF-8 encoded bytes has some zero-filled padding that gets included in the stored secret value:
$ /usr/bin/strongbox secret create --name my_secret --group etl --value-from-stdin
Enter secret value:
$ /usr/bin/strongbox --output=json secret get-latest-active --name=my_secret --group etl | jq '.[0].secretValue'
{
  "encoding": "utf8",
  "type": "opaque",
  "secretValue": "beeboopfoobarblahblahthisisalongstringyeah\u0000\u0000\u0000\u0000"
}

If we make sure to copy only up to the limit from the backing array, as per the proposed change, the outcome is better (as tested with a locally built client):
$ build/bin/strongbox secret add-version --name my_secret --group etl --value-from-stdin
Enter secret value:
$ /usr/bin/strongbox --output=json secret get-latest-active --name=my_secret --group etl | jq '.[0].secretValue'
{
  "encoding": "utf8",
  "type": "opaque",
  "secretValue": "beeboopfoobarblahblahthisisalongstringyeah"
}

I'm not completely satisfied with this yet.. The asBytes() function should probably be pulled out into a utility class or something, so it becomes testable. But it's late, so that'll have to wait until later ;)

Great stuff! Will review & test on Monday :)

Should hopefully be ready to go now; moved the method to a utility-like class, and added some testing :)


TimS/AmandaK

Implemented canceling of Operations and Tasks

This has been merged into dev. I've made some changes to the way the task handles its state.


Added most stars And Forked Repo's

It meets all the requirements. And all the Repositors are participating in Hacktoberfest

Added the Most Forked And Most Stars Repositories. Most popular Repositories for Hacktoberfest


Add support for execute step-type

Add command and arguments for execute
Add step-id
Note that in the future, step-type will be removed, and the agent will only execute commands.

Swagger looks OK


thefappenist.com

I believe this domain is an Adult(-related) domain --> that have to be blocked as..
Domains
Only add the needed one See also #12
thefappening.com
www.thefappening.com

Content sources
(Please see #35)

External sources (reference)

Screenshots
Screenshot required

Logger output
External Info

All Submissions:

[x] Have you checked to ensure there aren't other open Merge Requests (MR) or Issues for the same update/change?
[x] Added a Screenshot for prove of Adult contents

Todo

[ ] Added to Source file?
[ ] Added to the RPZ zone adult.mypdns.cloud (@spirillen)

Dead domain, hijacked by parklogic.com
whois thefappening.com
Domain Name: THEFAPPENING.COM
Registry Domain ID:<PHONE_NUMBER>_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namebright.com
Registrar URL: http://www.NameBright.com
Updated Date: 2020-01-26T00:37:01Z
Creation Date: 2018-11-21T19:29:23Z
Registry Expiry Date: 2020-11-21T19:29:23Z
Registrar: DropCatch.com 805 LLC
Registrar IANA ID: 2564
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Name Server: NS1.PARKLOGIC.COM
Name Server: NS2.PARKLOGIC.COM
Name Server: NS3.PARKLOGIC.COM


eslint.options.env is not respected

When configuring default options for ESLint through VSCode options, the env option is ignored:
// VSCode settings
{
  "eslint.options": {
    "rules": {
      "no-undef": ["error"]
    },
    "env": {
      "browser": true
    }
  }
}

// Any JavaScript file, errors with "'alert' is not defined"
alert('baz')

Notes:

This seems to be the exact same issue as #395.
Everything works as expected when the same options are defined in an .eslintrc file.

A reproduction repository can be found at loilo/repro-vscode-eslint-676.

Actually this is a quirk in npm ESLint itself. In the options for the CLIEngine this is called envs not env. See https://eslint.org/docs/developer-guide/nodejs-api#cliengine

Weird. Thanks for investigating!


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target/pull/715 is merged into live branch.
Auto archive content to https://github.com/VSC-Service-Account/docs-archive-test-target.git

Docs Build status updates of commit 280d520:
:clock10: Pending: waiting for processors (6 builds ahead of you)
:warning: Docs Build is busy, currently there are 6 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 280d520:
:clock10: Pending: waiting for processors (6 builds ahead of you)
:warning: Docs Build is busy, currently there are 6 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 280d520:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch Release_Archive_master_2021-01-26-02-14-39 has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 280d520:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch Release_Archive_master_2021-01-26-02-14-39 has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


mesos: 1.0.1 -> 1.1.0

Motivation for this change
Update Mesos to 1.1.0.
Things done

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

[x] NixOS
[ ] macOS
[x] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

/cc @philip-wernersbach @kamilchm @benley @kevincox @ibrahimsag

I've fixed a few of the problems outlined in https://github.com/NixOS/nixpkgs/pull/19064, but I still need to figure out how to fix the python bindings.

Regarding the python problems:
I think the crash might have been introduced when we moved to protobuf 2.6 (from 2.5) when we moved to Mesos 1.0.1. With the protobuf 2.6 python bindings, we pass --cpp_implementation, which presumably links to the native lib instead of using pure python.
I don't know what the fix is, but I want to try the following:

Run a build of Mesos without the --cpp_implementation flag, just to sanity check things.
Run a build of Mesos with --cpp_implementation, but also pass --compile_static_extension.

--cpp_implementation didn't fix it.
So, I've built 0.28.2 to compare (from 7b1efbf6212b6e111fb999da9b62eeb9d6c15d80), and I've also taken a look at the 1.1.0 deb package. Here's how things look:

0.28.2
$ ldd /nix/store/4zz1kl5mn3x2jm3j2g6i76h2zg8qdyw1-mesos-0.28.2/lib/libmesos.so
	linux-vdso.so.1 (0x00007ffd23ad8000)
	libglog.so.0 => /nix/store/zwqyy940fvdmw3zd25acaglrb3npnhlf-glog-0.3.4/lib/libglog.so.0 (0x00007f5e40fed000)
	libleveldb.so.1 => /nix/store/id76gqyh6x5rn3rqnm675wvn7vbr59a4-leveldb-1.18/lib/libleveldb.so.1 (0x00007f5e40d90000)
	libevent_openssl-2.0.so.5 => /nix/store/0c0ak33ijfbvzi7g6y7zc1hab616hdwb-libevent-2.0.22/lib/libevent_openssl-2.0.so.5 (0x00007f5e40b87000)
	libevent_pthreads-2.0.so.5 => /nix/store/0c0ak33ijfbvzi7g6y7zc1hab616hdwb-libevent-2.0.22/lib/libevent_pthreads-2.0.so.5 (0x00007f5e40984000)
	libevent-2.0.so.5 => /nix/store/0c0ak33ijfbvzi7g6y7zc1hab616hdwb-libevent-2.0.22/lib/libevent-2.0.so.5 (0x00007f5e4073b000)
	libnl-idiag-3.so.200 => /nix/store/zdmn563n7jfwrbm6igy13rzgdkqzq01k-libnl-3.2.28/lib/libnl-idiag-3.so.200 (0x00007f5e40532000)
	libnl-route-3.so.200 => /nix/store/zdmn563n7jfwrbm6igy13rzgdkqzq01k-libnl-3.2.28/lib/libnl-route-3.so.200 (0x00007f5e402c6000)
	libnl-3.so.200 => /nix/store/zdmn563n7jfwrbm6igy13rzgdkqzq01k-libnl-3.2.28/lib/libnl-3.so.200 (0x00007f5e400a5000)
	libsasl2.so.3 => /nix/store/4qxrvwlmadxx1a5p0ng6f2ansn7mxmjr-cyrus-sasl-2.1.26/lib/libsasl2.so.3 (0x00007f5e3fe86000)
	libresolv.so.2 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libresolv.so.2 (0x00007f5e3fc6f000)
	libsvn_delta-1.so.0 => /nix/store/80247vblljjbipyx8i8kh36996jgbjck-subversion-1.9.4/lib/libsvn_delta-1.so.0 (0x00007f5e3fa5c000)
	libsvn_subr-1.so.0 => /nix/store/80247vblljjbipyx8i8kh36996jgbjck-subversion-1.9.4/lib/libsvn_subr-1.so.0 (0x00007f5e3f736000)
	libaprutil-1.so.0 => /nix/store/ar2iwj02cjw8ghx1ssw20p0nbmyhdqh1-apr-util-1.5.4/lib/libaprutil-1.so.0 (0x00007f5e3f50d000)
	libexpat.so.1 => /nix/store/a6hjv9f55ax12z5n0z3krispalv3j2ca-expat-2.2.0/lib/libexpat.so.1 (0x00007f5e3f2e3000)
	libsqlite3.so.0 => /nix/store/i2qcxwbfhrj391vw81y9v7yj55dbim0a-sqlite-3.14.1/lib/libsqlite3.so.0 (0x00007f5e3f009000)
	libapr-1.so.0 => /nix/store/3nfvxxbmz0f451f7sa0mqsmnaa28ya8f-apr-1.5.2/lib/libapr-1.so.0 (0x00007f5e3edd5000)
	libcrypt.so.1 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libcrypt.so.1 (0x00007f5e3eb9a000)
	libpthread.so.0 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libpthread.so.0 (0x00007f5e3e97d000)
	libdl.so.2 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libdl.so.2 (0x00007f5e3e779000)
	libcurl.so.4 => /nix/store/4sflsm2kyizsrzvlppnwvmx2xw6qik2r-curl-7.50.1/lib/libcurl.so.4 (0x00007f5e3e506000)
	libnghttp2.so.14 => /nix/store/3dawp2fn8xxhcy6l0hpzbgkc97azk67p-nghttp2-1.10.0-lib/lib/libnghttp2.so.14 (0x00007f5e3e2df000)
	libssh2.so.1 => /nix/store/y1nvndkrbvj6j8rc7kx1yq8rsj49yiy5-libssh2-1.7.0/lib/libssh2.so.1 (0x00007f5e3e0b1000)
	libssl.so.1.0.0 => /nix/store/c2wywcsblyyiakx86mllygs23j2kkkhh-openssl-1.0.2h/lib/libssl.so.1.0.0 (0x00007f5e3de43000)
	libcrypto.so.1.0.0 => /nix/store/c2wywcsblyyiakx86mllygs23j2kkkhh-openssl-1.0.2h/lib/libcrypto.so.1.0.0 (0x00007f5e3da08000)
	libz.so.1 => /nix/store/yira0ix6cn5jd4h9g0rb70507yvdyksd-zlib-1.2.8/lib/libz.so.1 (0x00007f5e3d7f2000)
	librt.so.1 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/librt.so.1 (0x00007f5e3d5ea000)
	libstdc++.so.6 => /nix/store/cyxaswkikapsyl2ls8plf0nbbkhfaf8i-gcc-5.4.0-lib/lib/../lib64/libstdc++.so.6 (0x00007f5e3d270000)
	libm.so.6 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libm.so.6 (0x00007f5e3cf6b000)
	libc.so.6 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libc.so.6 (0x00007f5e3cbcd000)
	/nix/store/hwbvmr4imiyi5ziq6v2snynr7zf022b5-glibc-2.24/lib64/ld-linux-x86-64.so.2 (0x000055c5bf0f6000)
	libgcc_s.so.1 => /nix/store/cyxaswkikapsyl2ls8plf0nbbkhfaf8i-gcc-5.4.0-lib/lib/../lib64/libgcc_s.so.1 (0x00007f5e3c9b6000)

$ ldd /nix/store/4zz1kl5mn3x2jm3j2g6i76h2zg8qdyw1-mesos-0.28.2/lib/python2.7/site-packages/mesos/native/_mesos.so
	linux-vdso.so.1 (0x00007ffe92fc3000)
	libgcc_s.so.1 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libgcc_s.so.1 (0x00007f09f612c000)
	libleveldb.so.1 => /nix/store/id76gqyh6x5rn3rqnm675wvn7vbr59a4-leveldb-1.18/lib/libleveldb.so.1 (0x00007f09f5ecf000)
	libglog.so.0 => /nix/store/zwqyy940fvdmw3zd25acaglrb3npnhlf-glog-0.3.4/lib/libglog.so.0 (0x00007f09f5c9e000)
	libpython2.7.so.1.0 => /nix/store/mq23lfyirlkp4qw3493vc1n3z9zgkx3x-python-2.7.12/lib/libpython2.7.so.1.0 (0x00007f09f58c0000)
	libevent_openssl-2.0.so.5 => /nix/store/0c0ak33ijfbvzi7g6y7zc1hab616hdwb-libevent-2.0.22/lib/libevent_openssl-2.0.so.5 (0x00007f09f56b9000)
	libcrypto.so.1.0.0 => /nix/store/c2wywcsblyyiakx86mllygs23j2kkkhh-openssl-1.0.2h/lib/libcrypto.so.1.0.0 (0x00007f09f527e000)
	libssl.so.1.0.0 => /nix/store/c2wywcsblyyiakx86mllygs23j2kkkhh-openssl-1.0.2h/lib/libssl.so.1.0.0 (0x00007f09f5010000)
	libevent_pthreads-2.0.so.5 => /nix/store/0c0ak33ijfbvzi7g6y7zc1hab616hdwb-libevent-2.0.22/lib/libevent_pthreads-2.0.so.5(0x00007f09f4e0d000)
	libevent-2.0.so.5 => /nix/store/0c0ak33ijfbvzi7g6y7zc1hab616hdwb-libevent-2.0.22/lib/libevent-2.0.so.5 (0x00007f09f4bc2000)
	libnl-idiag-3.so.200 => /nix/store/zdmn563n7jfwrbm6igy13rzgdkqzq01k-libnl-3.2.28/lib/libnl-idiag-3.so.200 (0x00007f09f49b9000)
	libnl-route-3.so.200 => /nix/store/zdmn563n7jfwrbm6igy13rzgdkqzq01k-libnl-3.2.28/lib/libnl-route-3.so.200 (0x00007f09f474d000)
	libnl-3.so.200 => /nix/store/zdmn563n7jfwrbm6igy13rzgdkqzq01k-libnl-3.2.28/lib/libnl-3.so.200 (0x00007f09f452c000)
	libsasl2.so.3 => /nix/store/4qxrvwlmadxx1a5p0ng6f2ansn7mxmjr-cyrus-sasl-2.1.26/lib/libsasl2.so.3 (0x00007f09f430f000)
	libsvn_delta-1.so.0 => /nix/store/80247vblljjbipyx8i8kh36996jgbjck-subversion-1.9.4/lib/libsvn_delta-1.so.0 (0x00007f09f40fc000)
	libsvn_subr-1.so.0 => /nix/store/80247vblljjbipyx8i8kh36996jgbjck-subversion-1.9.4/lib/libsvn_subr-1.so.0 (0x00007f09f3dd4000)
	libapr-1.so.0 => /nix/store/3nfvxxbmz0f451f7sa0mqsmnaa28ya8f-apr-1.5.2/lib/libapr-1.so.0 (0x00007f09f3ba0000)
	libcurl.so.4 => /nix/store/4sflsm2kyizsrzvlppnwvmx2xw6qik2r-curl-7.50.1/lib/libcurl.so.4 (0x00007f09f392d000)
	libz.so.1 => /nix/store/yira0ix6cn5jd4h9g0rb70507yvdyksd-zlib-1.2.8/lib/libz.so.1 (0x00007f09f3717000)
	librt.so.1 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/librt.so.1 (0x00007f09f350f000)
	libstdc++.so.6 => /nix/store/cyxaswkikapsyl2ls8plf0nbbkhfaf8i-gcc-5.4.0-lib/lib/libstdc++.so.6 (0x00007f09f3197000)
	libm.so.6 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libm.so.6 (0x00007f09f2e90000)
	libpthread.so.0 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libpthread.so.0 (0x00007f09f2c73000)
	libc.so.6 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libc.so.6 (0x00007f09f28d5000)
	/nix/store/hwbvmr4imiyi5ziq6v2snynr7zf022b5-glibc-2.24/lib64/ld-linux-x86-64.so.2 (0x00005569a8ea1000)
	libdl.so.2 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libdl.so.2 (0x00007f09f26d1000)
	libutil.so.1 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libutil.so.1 (0x00007f09f24ce000)
	libresolv.so.2 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libresolv.so.2 (0x00007f09f22b5000)
	libsqlite3.so.0 => /nix/store/i2qcxwbfhrj391vw81y9v7yj55dbim0a-sqlite-3.14.1/lib/libsqlite3.so.0 (0x00007f09f1fdd000)
	libaprutil-1.so.0 => /nix/store/ar2iwj02cjw8ghx1ssw20p0nbmyhdqh1-apr-util-1.5.4/lib/libaprutil-1.so.0 (0x00007f09f1db4000)
	libexpat.so.1 => /nix/store/a6hjv9f55ax12z5n0z3krispalv3j2ca-expat-2.2.0/lib/libexpat.so.1 (0x00007f09f1b8a000)
	libcrypt.so.1 => /nix/store/78sry5bqg60qx4cqqdfficbxshaj9adf-glibc-2.24/lib/libcrypt.so.1 (0x00007f09f194f000)
	libnghttp2.so.14 => /nix/store/3dawp2fn8xxhcy6l0hpzbgkc97azk67p-nghttp2-1.10.0-lib/lib/libnghttp2.so.14 (0x00007f09f1728000)
	libssh2.so.1 => /nix/store/y1nvndkrbvj6j8rc7kx1yq8rsj49yiy5-libssh2-1.7.0/lib/libssh2.so.1 (0x00007f09f14fa000)

1.1.0 (NixOS)
$ ldd /nix/store/irwmx4jyvmb1c3i4xykvnbb86ynkvjvq-mesos-1.0.1/lib/libmesos.so
	linux-vdso.so.1 (0x00007fff0758a000)
	libleveldb.so.1 => /nix/store/5h0wizsa981hd95agkcw1v0y48qm1h53-leveldb-1.18/lib/libleveldb.so.1 (0x00007f75f1f86000)
	libglog.so.0 => /nix/store/909z52mhyilscwn244mzpk80042r31mr-glog-0.3.4/lib/libglog.so.0 (0x00007f75f1d55000)
	libprotobuf.so.9 => /nix/store/sa55q8vm5d3wlq1844ywl4dggivm49rm-protobuf-2.6.1-lib/lib/libprotobuf.so.9 (0x00007f75f1a47000)
	libsvn_delta-1.so.0 => /nix/store/jmjk5wi9fr7sa1pdxhdjhnk23r2rs0ws-subversion-1.9.5/lib/libsvn_delta-1.so.0 (0x00007f75f1834000)
	libsvn_subr-1.so.0 => /nix/store/jmjk5wi9fr7sa1pdxhdjhnk23r2rs0ws-subversion-1.9.5/lib/libsvn_subr-1.so.0 (0x00007f75f150d000)
	libaprutil-1.so.0 => /nix/store/4q7pr0yg58j1hpk16ggz03nxdpi1v7k0-apr-util-1.5.4/lib/libaprutil-1.so.0 (0x00007f75f12e4000)
	libexpat.so.1 => /nix/store/2nvsa2m6ss08f7kz4wi26dp43x6gvav3-expat-2.2.0/lib/libexpat.so.1 (0x00007f75f10ba000)
	libsqlite3.so.0 => /nix/store/9fqd4xnrf7cxx0k4384hmjr2pcfr41l9-sqlite-3.15.2/lib/libsqlite3.so.0 (0x00007f75f0dbb000)
	libevent_openssl-2.0.so.5 => /nix/store/irimhimk9plpwsnmrw1dcj910xmnpd3g-libevent-2.0.22/lib/libevent_openssl-2.0.so.5 (0x00007f75f0bb4000)
	libsasl2.so.3 => /nix/store/np3nl0ykvci9p4kqkvi6nhrbdm1bjkx6-cyrus-sasl-2.5.10/lib/libsasl2.so.3 (0x00007f75f0997000)
	libresolv.so.2 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libresolv.so.2 (0x00007f75f0780000)
	libnl-idiag-3.so.200 => /nix/store/5jwn7g9fbzn9nmvns1y3r04ivpvwbwww-libnl-3.2.28/lib/libnl-idiag-3.so.200 (0x00007f75f0577000)
	libnl-route-3.so.200 => /nix/store/5jwn7g9fbzn9nmvns1y3r04ivpvwbwww-libnl-3.2.28/lib/libnl-route-3.so.200 (0x00007f75f030b000)
	libnl-3.so.200 => /nix/store/5jwn7g9fbzn9nmvns1y3r04ivpvwbwww-libnl-3.2.28/lib/libnl-3.so.200 (0x00007f75f00e8000)
	libevent_pthreads-2.0.so.5 => /nix/store/irimhimk9plpwsnmrw1dcj910xmnpd3g-libevent-2.0.22/lib/libevent_pthreads-2.0.so.5 (0x00007f75efee5000)
	libevent-2.0.so.5 => /nix/store/irimhimk9plpwsnmrw1dcj910xmnpd3g-libevent-2.0.22/lib/libevent-2.0.so.5 (0x00007f75efc9c000)
	libcurl.so.4 => /nix/store/jic3d80c119cxkqdh62q5rq4cni2jjdb-curl-7.51.0/lib/libcurl.so.4 (0x00007f75efa28000)
	libnghttp2.so.14 => /nix/store/yizk9gj1ivjz56hciikapg614ldj2jdz-nghttp2-1.17.0-lib/lib/libnghttp2.so.14 (0x00007f75ef802000)
	libssh2.so.1 => /nix/store/dbqc46f5pyi8qh274d619ca90fdqxwf6-libssh2-1.7.0/lib/libssh2.so.1 (0x00007f75ef5d4000)
	libssl.so.1.0.0 => /nix/store/f7vp024rwfnmzm17p3c6ji3zc79a5vyr-openssl-1.0.2j/lib/libssl.so.1.0.0 (0x00007f75ef364000)
	libcrypto.so.1.0.0 => /nix/store/f7vp024rwfnmzm17p3c6ji3zc79a5vyr-openssl-1.0.2j/lib/libcrypto.so.1.0.0 (0x00007f75eef28000)
	libapr-1.so.0 => /nix/store/8b380pg44z2da1kl76xb777n1gm3rnv2-apr-1.5.2/lib/libapr-1.so.0 (0x00007f75eecf4000)
	libcrypt.so.1 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libcrypt.so.1 (0x00007f75eeab9000)
	libpthread.so.0 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libpthread.so.0 (0x00007f75ee89c000)
	libdl.so.2 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libdl.so.2 (0x00007f75ee698000)
	libz.so.1 => /nix/store/nlvp2f6p41k0bf3ymqkmsg2llqm19xwp-zlib-1.2.8/lib/libz.so.1 (0x00007f75ee480000)
	librt.so.1 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/librt.so.1 (0x00007f75ee278000)
	libstdc++.so.6 => /nix/store/h9nfcpcmnax1pi2lz897irbk822833vq-gcc-5.4.0-lib/lib/../lib64/libstdc++.so.6 (0x00007f75edf00000)
	libm.so.6 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libm.so.6 (0x00007f75edbfb000)
	libc.so.6 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libc.so.6 (0x00007f75ed85d000)
	/nix/store/hwbvmr4imiyi5ziq6v2snynr7zf022b5-glibc-2.24/lib64/ld-linux-x86-64.so.2 (0x0000559bf471d000)
	libgcc_s.so.1 => /nix/store/h9nfcpcmnax1pi2lz897irbk822833vq-gcc-5.4.0-lib/lib/../lib64/libgcc_s.so.1 (0x00007f75ed646000)

$ ldd /nix/store/irwmx4jyvmb1c3i4xykvnbb86ynkvjvq-mesos-1.0.1/lib/python2.7/site-packages/mesos/executor/_executor.so
	linux-vdso.so.1 (0x00007ffe8f528000)
	libgcc_s.so.1 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libgcc_s.so.1 (0x00007fbc1d396000)
	libleveldb.so.1 => /nix/store/5h0wizsa981hd95agkcw1v0y48qm1h53-leveldb-1.18/lib/libleveldb.so.1 (0x00007fbc1d139000)
	libglog.so.0 => /nix/store/909z52mhyilscwn244mzpk80042r31mr-glog-0.3.4/lib/libglog.so.0 (0x00007fbc1cf0a000)
	libprotobuf.so.9 => /nix/store/sa55q8vm5d3wlq1844ywl4dggivm49rm-protobuf-2.6.1-lib/lib/libprotobuf.so.9 (0x00007fbc1cbfa000)
	libpython2.7.so.1.0 => /nix/store/q45sl6xg6ah6896v0f1nyvbixss5j9y6-python-2.7.13/lib/libpython2.7.so.1.0 (0x00007fbc1c81a000)
	libz.so.1 => /nix/store/nlvp2f6p41k0bf3ymqkmsg2llqm19xwp-zlib-1.2.8/lib/libz.so.1 (0x00007fbc1c604000)
	libevent_openssl-2.0.so.5 => /nix/store/irimhimk9plpwsnmrw1dcj910xmnpd3g-libevent-2.0.22/lib/libevent_openssl-2.0.so.5 (0x00007fbc1c3fd000)
	libcrypto.so.1.0.0 => /nix/store/f7vp024rwfnmzm17p3c6ji3zc79a5vyr-openssl-1.0.2j/lib/libcrypto.so.1.0.0 (0x00007fbc1bfc1000)
	libssl.so.1.0.0 => /nix/store/f7vp024rwfnmzm17p3c6ji3zc79a5vyr-openssl-1.0.2j/lib/libssl.so.1.0.0 (0x00007fbc1bd53000)
	libevent_pthreads-2.0.so.5 => /nix/store/irimhimk9plpwsnmrw1dcj910xmnpd3g-libevent-2.0.22/lib/libevent_pthreads-2.0.so.5 (0x00007fbc1bb4e000)
	libevent-2.0.so.5 => /nix/store/irimhimk9plpwsnmrw1dcj910xmnpd3g-libevent-2.0.22/lib/libevent-2.0.so.5 (0x00007fbc1b905000)
	librt.so.1 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/librt.so.1 (0x00007fbc1b6fd000)
	libstdc++.so.6 => /nix/store/h9nfcpcmnax1pi2lz897irbk822833vq-gcc-5.4.0-lib/lib/libstdc++.so.6 (0x00007fbc1b385000)
	libm.so.6 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libm.so.6 (0x00007fbc1b080000)
	libpthread.so.0 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libpthread.so.0 (0x00007fbc1ae63000)
	libc.so.6 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libc.so.6 (0x00007fbc1aac3000)
	/nix/store/hwbvmr4imiyi5ziq6v2snynr7zf022b5-glibc-2.24/lib64/ld-linux-x86-64.so.2 (0x000056087d735000)
	libdl.so.2 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libdl.so.2 (0x00007fbc1a8bf000)
	libutil.so.1 => /nix/store/8lbpq1vmajrbnc96xhv84r87fa4wvfds-glibc-2.24/lib/libutil.so.1 (0x00007fbc1a6bc000)

1.1.0 (deb pkg)
$ ldd ./usr/lib/libmesos.so
	linux-vdso.so.1 (0x00007fffebbd4000)
	libpthread.so.0 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libpthread.so.0 (0x00007effddd4b000)
	libsvn_delta-1.so.1 => not found
	libsvn_subr-1.so.1 => not found
	libevent_openssl-2.0.so.5 => not found
	libcrypto.so.1.0.0 => not found
	libssl.so.1.0.0 => not found
	libsasl2.so.2 => not found
	libevent_pthreads-2.0.so.5 => not found
	libevent-2.0.so.5 => not found
	libcurl.so.4 => not found
	libapr-1.so.0 => not found
	libz.so.1 => not found
	librt.so.1 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/librt.so.1 (0x00007effddb3f000)
	libstdc++.so.6 => not found
	libm.so.6 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libm.so.6 (0x00007effdd83a000)
	libc.so.6 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libc.so.6 (0x00007effdd49c000)
	/nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib64/ld-linux-x86-64.so.2 (0x000056161b403000)
	libgcc_s.so.1 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libgcc_s.so.1 (0x00007effdd286000)

$ ldd ./usr/lib/python2.7/site-packages/mesos/executor/_executor.so >> ../blah.txt
	linux-vdso.so.1 (0x00007fff553fc000)
	libz.so.1 => not found
	libevent_openssl-2.0.so.5 => not found
	libcrypto.so.1.0.0 => not found
	libssl.so.1.0.0 => not found
	libevent_pthreads-2.0.so.5 => not found
	libevent-2.0.so.5 => not found
	librt.so.1 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/librt.so.1 (0x00007fa8e29a9000)
	libstdc++.so.6 => not found
	libm.so.6 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libm.so.6 (0x00007fa8e26a4000)
	libgcc_s.so.1 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libgcc_s.so.1 (0x00007fa8e248e000)
	libpthread.so.0 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libpthread.so.0 (0x00007fa8e2271000)
	libc.so.6 => /nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib/libc.so.6 (0x00007fa8e1ed1000)
	/nix/store/6fix3zqpnahyml8zp2sxi2rwan55rgb8-glibc-2.24/lib64/ld-linux-x86-64.so.2 (0x000055c821099000)

One thing that stands out is that in both the 0.28.2 package and the debian package of 1.1.0: libprotobuf is statically linked.
I suspect this is due to telling the mesos build system to use our package of protobuf, as opposed to using the bundled version. I'll see if building with the bundled version resolves things, and if that works, I'll see if I can write a patch to have mesos always statically link the lib (and then I'll see if I can upstream that patch).

@kamilchm I fixed the libprotobuf+python problems by statically linking libprotobuf:
    substituteInPlace 3rdparty/stout/Makefile.am \
      --replace "-lprotobuf" \
                "${pythonProtobuf.protobuf.lib}/lib/libprotobuf.a"

    substituteInPlace src/python/native_common/ext_modules.py.in \
      --replace "-lprotobuf" \
                "${pythonProtobuf.protobuf.lib}/lib/libprotobuf.a"

    substituteInPlace src/Makefile.am \
      --replace "-lprotobuf" \
                "${pythonProtobuf.protobuf.lib}/lib/libprotobuf.a"

I'm running one more build to sanity check. However, I'm pretty sure that the package is now in a state that I feel comfortable asking for testing. So for anyone following this PR, please do try it out and let me know if you run into any issues. In the meantime, I'm going to try to write some tests.

@kamilchm I'm getting an error that, from looking through the IRC logs, I see you too were running into:

mesos-slave[700]: Failed to create a containerizer: Could not create DockerContainerizer: Failed to create docker: Failed to getdocker version: Failed to execute '/nix/store/8gayxk8vg453asxypc1qvmvsbdarybcv-docker-1.12.5/libexec/docker/docker -H unix:///var/run/docker/libcontainerd/docker-containerd.sock --version': terminated with signal Aborted

Interestingly, if I override the docker path in the following ways and I still get the same "Aborted" error:

--docker=${pkgs.coreutils}/bin/true
--docker=does-not-exist

So it's clearly not a problem invoking docker - it would seem that the subprocess function is failing at some point inside the child process (i.e. after the call to clone) before it ever execs the target program.
I've sprinkled in some LOG statements, and I'll see if I can figure out where precisely it's failing, and then I'll try to step through with gdb.

So, it's definitely failing at the os::execvpe call, and I presume the abort is due to the following ABORT (the message doesn't show up in the logs because stdout/stderr have been redirected). I'll see what errno is and see if I can figure out what's going on.

Ah, that's because, per the problems mentioned in the previous PR, I removed the patch to set os::Shell::name to the ${pkgs.stdenv}/bin/sh, and the variant of subprocess that is used here is one that uses that shell (which is just sh). For the curious, here's what get's invoked:
slave# [    3.702704] mesos-slave[687]: XXX execing program: sh
slave# [    3.703439] mesos-slave[687]: XXX argv[0]=sh
slave# [    3.704073] mesos-slave[687]: XXX argv[1]=-c
slave# [    3.704733] mesos-slave[687]: XXX argv[2]=/nix/store/8gayxk8vg453asxypc1qvmvsbdarybcv-docker-1.12.5/libexec/docker/docker -H unix:///var/run/docker/libcontainerd/docker-containerd.sock --version
slave# [    3.705925] mesos-slave[687]: XXX envp[0]=LANG=en_US.UTF-8
slave# [    3.706767] mesos-slave[687]: XXX envp[1]=PATH=/nix/store/8gayxk8vg453asxypc1qvmvsbdarybcv-docker-1.12.5/bin:/nix/store/cymbr3a1s7d1zj4073mb85hb0vdrr4la-coreutils-8.26/bin:/nix/store/r2g04csk4flx3v9kf5g0i3h6j7m5wfq1-findutils-4.6.0/bin:/nix/store/rff8mpdyx6782qr12y65vc05f7n16qhb-gnugrep-2.27/bin:/nix/store/64xlllqh7gak9kf7g608ck5axd29r98k-gnused-4.2.2/bin:/nix/store/4maz3hyzx3m0m4w11988w8l8y4l9h2y7-systemd-231/bin:/nix/store/8gayxk8vg453asxypc1qvmvsbdarybcv-docker-1.12.5/sbin:/nix/store/cymbr3a1s7d1zj4073mb85hb0vdrr4la-coreutils-8.26/sbin:/nix/store/r2g04csk4flx3v9kf5g0i3h6j7m5wfq1-findutils-4.6.0/sbin:/nix/store/rff8mpdyx6782qr12y65vc05f7n16qhb-gnugrep-2.27/sbin:/nix/store/64xlllqh7gak9kf7g608ck5axd29r98k-gnused-4.2.2/sbin:/nix/store/4maz3hyzx3m0m4w11988w8l8y4l9h2y7-systemd-231/sbin
slave# [    3.709971] mesos-slave[687]: XXX envp[2]=JOURNAL_STREAM=8:12999
slave# [    3.710672] mesos-slave[687]: XXX envp[3]=GCOV_PREFIX=/tmp/xchg/coverage-data
slave# [    3.711411] mesos-slave[687]: XXX envp[4]=LOCALE_ARCHIVE=/nix/store/261s1323apwhv8xszff5w2nz2myrk1d8-glibc-locales-2.24/lib/locale/locale-archive
slave# [    3.712420] mesos-slave[687]: XXX envp[5]=MESOS_CONTAINERIZERS=mesos,docker
slave# [    3.713175] mesos-slave[687]: XXX envp[6]=TZDIR=/nix/store/aacmjq0zmkcwchaxz7zs5lnh176jv9qf-tzdata-2016f/share/zoneinfo
slave# [    3.714108] mesos-slave[687]: XXX envp[7]=LIBPROCESS_IP=<IP_ADDRESS>
slave# [    3.714812] mesos-slave[687]: XXX envp[8]=LIBPROCESS_PORT=5051
slave# [    3.715637] mesos-slave[687]: XXX failed to exec: (2) No such file or directory

@cstrahan It was some time ago when I was trying to run different NixOS configuration. However, I would stick with nixos tests which I introduced later. If we find new bugs these needs to be added to the test module.
Good work with the python bindings 👍
I'll try to test all your changes before the weekend.

I resolved the os::Shell::name problem by replacing "sh" with "/bin/sh". Now the master and agent both run without crashing.
I'm still adapting @kamilchm's tests, as I'm running into issues with the "docker" containerizer (it really wants to connect to the internet to fetch the test image, despite having already docker loaded the image...). I'm going to try switching to the "mesos" containerizer and point the agent at a directory containing the test image(s) via --docker_registry.

Oh, so I made some bad assumptions, and I need to patch out some more paths. I'm going to let mesos build overnight, and then I'll update this tomorrow morning. Hopefully that's the last big change before I have the new tests working.

Hm... So I'm having a hard time deciding what to do about os::Shell::name. In the original source it's "sh", but that causes the initial docker --version check (and other similar shell invocations at early startup) to fail, because it's not guaranteed that sh is on $PATH. I suppose we could either depend on sh being on $PATH via the systemd unit, or find some way (via a wrapper or patches to the source) to ensure any invocation of the mesos binaries has $PATH setup accordingly.
Another option, and the one I've been experimenting with up to now, is to patch the source so os::Shell::name is "/bin/sh". The problem there is that os::Shell::name is also used within the chrooted container environments too, which will fail when the container's rootfs doesn't have /bin/sh. Now, it crossed my mind that stuff like system(3) will fail when /bin/sh doesn't exist, so maybe we can get away with treating such scenarios as wrong and unsupported; however, that's clearly not what mesos is doing - they expect that, in the case of Docker images, the Env setting will setup $PATH so that sh will resolve. Therefore, I'm inclined to think we shouldn't change that behavior, and thus we should keep "sh". The question now is: by what means shall we ensure sh will resolve on the host, which takes us back to the options outlined in the preceding paragraph.
When creating images with our dockerTools functions, we should probably just assume that the user is savvy enough to know to set Env so that sh is on $PATH.

I think, for now, I'm going to add stdenv.shell to the systemd unit's path setting. We can revisit this part at a later time, if anyone develops strong feelings about how to do this.

It reminds me my confusion about tar and gzip https://github.com/NixOS/nixpkgs/issues/13783#issuecomment-252898322
I don't know how to decide what is the smallest usable dependencies set to fulfill basic mesos use cases?
What are the drawbacks of modifying $PATH with wrapper?

What are the drawbacks of modifying $PATH with wrapper?

I might switch to wrappers... I'll have to give it some thought. I don't like the indirection, but the simplicity of that approach might outweigh any objections to wrappers.

We shouldn't place additional restrictions on containers, outside of what Mesos does itself. We should always be able to run the same containers on a NixOS Mesos as on a Mesosphere Mesos, etc. I agree that forcing the container shell to /bin/sh is bad.

@philip-wernersbach Thanks for the feedback! Are you using Mesos on NixOS? Curious how things have been working for you, if so.

As of the last push, @kamilchm's test cases pass (with some minor edits, e.g. using mesos executor instead of docker). There are also a handful of new module options that I've found useful while testing Mesos locally and in the NixOS tests.

@cstrahan No, we're using Mesos 1.0.0 on CentOS, installed via Nix and Disnix (@svanderburg). Except for the problems noted here and here, which I've fixed with hacks, everything is working well for our use case. Which is using Marathon with the Mesos containerizer.

Should this be merged? Or is it a WIP?

I think this is, at this point, strictly an improvement on what we had before, and shouldn't introduce any regressions. So it should be safe to merge, though I do want to make some minor changes here and there.

Ok, since you have merge rights I'll just leave it to you :)

Alright, think I've waited long enough; merging.


Handling email & username on Signup

Currently there is one page with two text inputs, and the return key for the username text input is "next".
Tapping on it dismisses the keyboard (and checks username) but doesn't focus on the email text input.

username should be checked on blur (in case the user doesn't hit "next" but moves on to the email text input )
should the next button focus on the email text input? The keyboard will go down and up

Alternatively, if the inputs are on two different screens, "next" will actually make sense. Not sure how the keyboard should behave though.

Using two "screens" for now - will reopen if there's a jitter


Add Numa support to DomainCPU

This patch add Numa field in DomainCPU so that we can support Numa in QEMU/KVM.
Signed-off-by: Crazykev<EMAIL_ADDRESS>

Thanks, pushed to master


[ENHANCEMENT] Update release to access on Replit

Hiya!
About
I found this Repl that allowed Replit Users to use (pretty much any lang that had a release) custom langs. However, the current release seems (very) outdated, and I would like to ask if any of the devs could make a new release that includes all the current code? That way, we can access the current version on Replit (I'm testing with it to test my own lang as well :P). Thanks!
Question
So just to clarify, the question was if you could release a release that holds all the current code :)

Doesn't replit support Nix?  So you could just merge this into nixpkgs then do a nix-shell invocation...

Well, yes, I tried that, but it doesn’t seem to work from what I did…
But I’ll try that again and see if it works

The current code might not work :/
That repl downloads the latest release (which does work)

Okay! Quick question, could you make a README that holds the syntax for that night version?
So the current version is still a wip?

@CodeLongAndProsper90 - so I have a question: I tried using Nix (using DynamicSquid's repl fork), but I didn't know how to start the file, and I got stumped on running the file. Could you help with this?

Repl source code<EMAIL_ADDRESS>

@JBYT27 Some syntax is in the website https://dynamicsquid.github.io/night/ it's still in development
To run Night on Linux, follow the Linux instructions in the Readme. Once you built the project, you should see a ./night folder somewhere, and you can run that

Oh okay! Thank you!
i’ll try that and see if its up-to-daye and works (it prob will as u said tho)


Collapse on tr results on tr losing width

Before opening an issue:
Using bootstrap 4-alpha 3
Example: https://github.com/roybrener/tableCollapseBug
I've created a simple table with 2 rows. The 2nd row is hidden using class="collapse". After clicking the first row
The second row is being showed but then losses It's width- the FIrst column of row 1 takes much
more space and pushes the rest of the columns and the second row gets the width of only the first column.
When removing the "class=collapse" then the row cover the full colSpan
Bootstrap 3 (3.3.7) Works as expected
tested on windows 10- Chrome 53, IE 11.545 and edge, All showing the same behavior

The tr and trbody tags were commented out within the .collapse class. Additionally, when uncommented, they generated incorrect css when compiled. Restructed. Compared generated css with css from 3.3.7


Any actual code for open source?

When can we find the code? I find that the repo is empty

Sorry for the late reply. We've uploaded the dataset and the code.
where is the code ?