python312Packages.lockfile: Remove usage of nose; modernize

Description of changes
Part of #326513

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

By the way, I’m not sure if pytest tries to run tests in parallel but if it does it should definitely be disabled for these cursed tests that mutate global state.

By the way, I’m not sure if pytest tries to run tests in parallel but if it does it should definitely be disabled for these cursed tests that mutate global state.

Pytest only parallelizes with pytest-xdist installed, which is not the case here. Good catch though.

Result of nixpkgs-review pr 343765 run on aarch64-linux 1

4 packages failed to build:

python311Packages.ansible-kernel
python311Packages.ansible-kernel.dist
python311Packages.ansible-runner
python311Packages.ansible-runner.dist

82 packages built:

ansible-navigator
ansible-navigator.dist
deja-dup
duplicity
duplicity.dist
duply
esphome
esphome.dist
evdevremapkeys
evdevremapkeys.dist
hddfancontrol
hddfancontrol.dist
irrd
irrd.dist
keepkey-agent (python312Packages.keepkey-agent)
keepkey-agent.dist (python312Packages.keepkey-agent.dist)
ledger-agent (python312Packages.ledger-agent)
ledger-agent.dist (python312Packages.ledger-agent.dist)
luigi
luigi.dist
onlykey-agent
onlykey-agent.dist
platformio
platformio-core
platformio-core.dist
platformio-core.udev
pyrosimple
pyrosimple.dist
python311Packages.bugwarrior
python311Packages.bugwarrior.dist
python311Packages.keepkey-agent
python311Packages.keepkey-agent.dist
python311Packages.ledger-agent
python311Packages.ledger-agent.dist
python311Packages.libagent
python311Packages.libagent.dist
python311Packages.lockfile
python311Packages.lockfile.dist
python311Packages.mirakuru
python311Packages.mirakuru.dist
python311Packages.orange-canvas-core
python311Packages.orange-canvas-core.dist
python311Packages.orange-widget-base
python311Packages.orange-widget-base.dist
python311Packages.orange3
python311Packages.orange3.dist
python311Packages.pytest-postgresql
python311Packages.pytest-postgresql.dist
python311Packages.python-daemon
python311Packages.python-daemon.dist
python311Packages.python-fedora
python311Packages.python-fedora.dist
python311Packages.salmon-mail
python311Packages.salmon-mail.dist
python311Packages.trezor-agent
python311Packages.trezor-agent.dist
python312Packages.ansible-kernel
python312Packages.ansible-kernel.dist
python312Packages.ansible-runner
python312Packages.ansible-runner.dist
python312Packages.libagent
python312Packages.libagent.dist
python312Packages.lockfile
python312Packages.lockfile.dist
python312Packages.mirakuru
python312Packages.mirakuru.dist
python312Packages.orange-canvas-core
python312Packages.orange-canvas-core.dist
python312Packages.orange-widget-base
python312Packages.orange-widget-base.dist
python312Packages.orange3
python312Packages.orange3.dist
python312Packages.pytest-postgresql
python312Packages.pytest-postgresql.dist
python312Packages.python-daemon
python312Packages.python-daemon.dist
python312Packages.python-fedora
python312Packages.python-fedora.dist
python312Packages.salmon-mail
python312Packages.salmon-mail.dist
trezor-agent (python312Packages.trezor-agent)
trezor-agent.dist (python312Packages.trezor-agent.dist)

I’m baffled by the regression, but it seems real at first glance.

The ansible-runner tests seem flaky, sometimes they work(seemingly more when they're run on their own) but sometimes they don't. I don't believe it's a problem with this package.


Compaction dies constantly after a certain amount of documents

Description
We have an issue with our CouchDB 3.1.1. We are using the default compaction configuration and this seems to work fine till the database reaches a certain amount of documents (~76K). Then the compaction dies and it is no longer able to finish the task. The compaction is restarted every 2 seconds and it always dies immediately. Till now, the problem is consistent and I didn't find any way (except of deleting the database) to fix the issue.
I read some other compaction related issues, but here I only used version 3.1.1. So no upgrade, no migration or something similar.
What I tried so far:

I tried to remove the compaction files manually and restart CouchDB. Compaction fails again
I tried to reboot the node. Compaction fails again
Reading the issues #3292 and #2941, I tinkered an own version based on 3.1.1 including the following two changes. Compaction still fails.

fix race condition (#3150)
add remonitor code to DOWN message (#3144)

First the slack compactor always failed, then I disabled it, but then the radio_dbs compactor failed as well.

This is the log, which is repeated every two seconds:
[notice] 2021-05-19T14:42:38.848090Z<EMAIL_ADDRESS><0.460.0> -------- ratio_dbs: adding <<"shards/80000000-ffffffff/directory.1621404274">> to internal compactor queue with priority 2.100073355455779
[info] 2021-05-19T14:42:38.848533Z<EMAIL_ADDRESS><0.5146.0> -------- Starting compaction for db "shards/80000000-ffffffff/directory.1621404274" at 40726
[notice] 2021-05-19T14:42:38.848615Z<EMAIL_ADDRESS><0.460.0> -------- ratio_dbs: Starting compaction for shards/80000000-ffffffff/directory.1621404274 (priority 2.100073355455779)
[notice] 2021-05-19T14:42:38.849705Z<EMAIL_ADDRESS><0.460.0> -------- ratio_dbs: Started compaction for shards/80000000-ffffffff/directory.1621404274
[warning] 2021-05-19T14:42:38.893633Z<EMAIL_ADDRESS><0.460.0> -------- exit for compaction of ["shards/80000000-ffffffff/directory.1621404274"]: {undef,[{math,ceil,[1.6],[]},{couch_emsort,num_merges,2,[{file,"src/couch_emsort.erl"},{line,366}]},{couch_bt_engine_compactor,sort_meta_data,1,[{file,"src/couch_bt_engine_compactor.erl"},{line,508}]},{lists,foldl,3,[{file,"lists.erl"},{line,1263}]},{couch_bt_engine_compactor,start,4,[{file,"src/couch_bt_engine_compactor.erl"},{line,75}]}]}
[error] 2021-05-19T14:42:38.894691Z<EMAIL_ADDRESS>emulator -------- Error in process <0.5148.0> on node<EMAIL_ADDRESS>with exit value:
{undef,[{math,ceil,[1.6],[]},{couch_emsort,num_merges,2,[{file,"src/couch_emsort.erl"},{line,366}]},{couch_bt_engine_compactor,sort_meta_data,1,[{file,"src/couch_bt_engine_compactor.erl"},{line,508}]},{lists,foldl,3,[{file,"lists.erl"},{line,1263}]},{couch_bt_engine_compactor,start,4,[{file,"src/couch_bt_engine_compactor.erl"},{line,75}]}]}

[info] 2021-05-19T14:42:38.894453Z<EMAIL_ADDRESS><0.226.0> -------- db shards/80000000-ffffffff/directory.1621404274 died with reason {undef,[{math,ceil,[1.6],[]},{couch_emsort,num_merges,2,[{file,"src/couch_emsort.erl"},{line,366}]},{couch_bt_engine_compactor,sort_meta_data,1,[{file,"src/couch_bt_engine_compactor.erl"},{line,508}]},{lists,foldl,3,[{file,"lists.erl"},{line,1263}]},{couch_bt_engine_compactor,start,4,[{file,"src/couch_bt_engine_compactor.erl"},{line,75}]}]}

If the problem occurs, inserting data is still possible, but often I get the following error message (btw, I'm using python-cloudant)
500 Server Error: Internal Server Error unknown_error undefined for url: http://localhost:5984/directory

Steps to Reproduce

Clean database
Create a script, which creates documents in an endless loop (pur json, no attachments, just one revision)
After around 76K documents the compactor starts to fail.
Inserts are still possible, but time and again, the insert fails with (see above 500 Server Error)

I did the mentioned stress test above on 3 nodes in parallel. All 3 nodes started to fail around the same amount of documents (70K-80K).

In the first node, I created the documents single threaded
In the second node, I created the documents using two threads
In the third node, I created the documents using four threads

Following the script I used to reproduce the issue in my setup:
#!/usr/bin/env python

import signal
import sys
from cloudant.client import CouchDB
from cloudant.document import Document
from copy import deepcopy
from threading import Thread

USERNAME = 'admin'
PASSWORD = 'admin'
COUCHDB_URL = 'http://localhost:5984'
DB_NAME = 'directory'

cdb = CouchDB(USERNAME, PASSWORD, url=COUCHDB_URL, connect=True, auto_renew=True)

account_skeletton = { 'parameter 1': 0,
                      'parameter 2': True,
                      'parameter 3': '',
                      'parameter 4': '',
                      'parameter 5': [],
                      'parameter 6': [],
                      'description': '',
                      'enabled': True,
                      'firstname': '',
                      'parameter 7': False,
                      'lastname': '',
                      'parameter 8': '',
                      'number': '',
                      'parameter 9': '9301162291d5a0480270d97d6c4a6da3edd75aa5',
                      'parameter 10': 'cos02',
                      'parameter 11': '112233',
                      'parameter 12':<PHONE_NUMBER>.572422,
                      'parameter 13': 0,
                      'parameter 14': 0.0,
                      'parameter 15': False,
                      'parameter 16': 4,
                      'parameter 17': '',
                      'parameter 18': '',
                      'parameter 19': 'user',
                      'userid': '',
                      'parameter 20': '',
                      'parameter 21': '',
                      'parameter 22': True}

if DB_NAME not in cdb.all_dbs():
    cdb.create_database(DB_NAME)

def signal_handler(sig, frame):
    print('You pressed Ctrl+C!')
    sys.exit(0)

def create_documents(start=0, thread_id=0):
    try:
        for i in xrange(start, 999999):
            number = '{}{:06}'.format(thread_id, i)
            print('create_documents: Creating document {}'.format(number))
            with Document(cdb[DB_NAME], number) as document:
                document.update(deepcopy(account_skeletton))
                document['firstname'] = 'FN {}'.format(number)
                document['lastname'] = 'LN {}'.format(number)
                document['number'] = number
                document['userid'] = number
    except Exception as err:
        print('create_documents: {}'.format(err))

def create_documents_threaded(threads=2):
    for i in xrange(threads):
        t = Thread(target=create_documents, args=(0, i))
        t.daemon = True
        t.start()

    signal.signal(signal.SIGINT, signal_handler)
    print('Press Ctrl+C')
    signal.pause()

Expected Behaviour
Compaction doesn't fail :-)
Your Environment

CouchDB version used:
{"couchdb":"Welcome","version":"3.1.1","git_sha":"ce596c65d","uuid":"08fb7cd0a10f35f6215a531742f7b356","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}
python-cloudant: 2.14.0
python2.7
Operating system and version:

Own Linux distribution

CouchDB running in a VM

Single Core (also changed to 2 cores, no difference)
1GB Ram (also increased it to 1GB, no difference)

To trigger this issue, I used an isolated node, no replication, no clustering

Additional Context
Following you can find the configuration. Most of it is default:
curl http://admin:admin<EMAIL_ADDRESS>| python -m json.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2823  100  2823    0     0   310k      0 --:--:-- --:--:-- --:--:--  344k
{
    "admins": {
        "admin": "-pbkdf2-d5b128e39ebe61b4f50fb9c2e3241c0ea1bc28f9,6b6e6d21c67f685f753d8fa1fe72db71,10"
    },
    "attachments": {
        "compressible_types": "text/*, application/javascript, application/json, application/xml",
        "compression_level": "8"
    },
    "chttpd": {
        "backlog": "512",
        "bind_address": "<IP_ADDRESS>",
        "max_db_number_for_dbs_info_req": "100",
        "port": "5984",
        "prefer_minimal": "Cache-Control, Content-Length, Content-Range, Content-Type, ETag, Server, Transfer-Encoding, Vary",
        "require_valid_user": "false",
        "server_options": "[{recbuf, undefined}]",
        "socket_options": "[{sndbuf, 262144}, {nodelay, true}]"
    },
    "cluster": {
        "n": "3",
        "q": "2"
    },
    "cors": {
        "credentials": "false"
    },
    "couch_httpd_auth": {
        "allow_persistent_cookies": "true",
        "auth_cache_size": "50",
        "authentication_db": "_users",
        "authentication_redirect": "/_utils/session.html",
        "iterations": "10",
        "require_valid_user": "false",
        "secret": "a0ec90afc5f896e3cf90e8c4adc9dafa",
        "timeout": "600"
    },
    "couch_peruser": {
        "database_prefix": "userdb-",
        "delete_dbs": "false",
        "enable": "false"
    },
    "couchdb": {
        "attachment_stream_buffer_size": "4096",
        "changes_doc_ids_optimization_threshold": "100",
        "database_dir": "/var/crypt/couchdb/couchdb",
        "default_engine": "couch",
        "default_security": "everyone",
        "file_compression": "snappy",
        "max_dbs_open": "500",
        "max_document_size": "8000000",
        "os_process_timeout": "5000",
        "single_node": "true",
        "users_db_security_editable": "false",
        "uuid": "08fb7cd0a10f35f6215a531742f7b356",
        "view_index_dir": "/var/crypt/couchdb/couchdb"
    },
    "couchdb_engines": {
        "couch": "couch_bt_engine"
    },
    "csp": {
        "enable": "true"
    },
    "feature_flags": {
        "partitioned||*": "true"
    },
    "httpd": {
        "allow_jsonp": "false",
        "authentication_handlers": "{couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler}",
        "bind_address": "<IP_ADDRESS>",
        "enable_cors": "false",
        "enable_xframe_options": "false",
        "max_http_request_size": "4294967296",
        "port": "5986",
        "secure_rewrites": "true",
        "socket_options": "[{sndbuf, 262144}]"
    },
    "indexers": {
        "couch_mrview": "true"
    },
    "ioq": {
        "concurrency": "10",
        "ratio": "0.01"
    },
    "ioq.bypass": {
        "compaction": "false",
        "os_process": "true",
        "read": "true",
        "shard_sync": "false",
        "view_update": "true",
        "write": "true"
    },
    "log": {
        "file": "/var/log/couchdb/couchdb.log",
        "level": "info",
        "writer": "file"
    },
    "query_server_config": {
        "os_process_limit": "100",
        "reduce_limit": "true"
    },
    "replicator": {
        "connection_timeout": "30000",
        "http_connections": "20",
        "interval": "60000",
        "max_churn": "20",
        "max_jobs": "500",
        "retries_per_request": "5",
        "socket_options": "[{keepalive, true}, {nodelay, false}]",
        "ssl_certificate_max_depth": "3",
        "startup_jitter": "5000",
        "verify_ssl_certificates": "true",
        "worker_batch_size": "500",
        "worker_processes": "4"
    },
    "smoosh": {
        "db_channels": "upgrade_dbs,ratio_dbs",
        "view_channels": "upgrade_views,ratio_views"
    },
    "ssl": {
        "port": "6984"
    },
    "uuids": {
        "algorithm": "sequential",
        "max_count": "1000"
    },
    "vendor": {
        "name": "The Apache Software Foundation"
    }
}

We have a similar issue (Ubuntu Server 20.04, Docker version of CouchDB 3.1.1).
We have a 30GB database which is being replicated from an another machine. Looking at the files I can see that the database files take someting like 100GB + another ca. 30GB for the compaction files.
The compaction starts but always dies before it finishes. So the database gets never compacted and the compaction files are hanging there forever.
Some logs:
couchdb-backup-service-01 | [info] 2021-05-21T08:27:57.466850Z nonode@nohost <0.222.0> -------- db shards/80000000-ffffffff/yoda_filesystem.1614838752 died with reason {{badarg,[{erlang,monitor,[process,{main,'clouseau@<IP_ADDRESS>'}],[]},{ioq,submit_request,2,[{file,"src/ioq.erl"},{line,187}]},{ioq,maybe_submit_request,1,[{file,"src/ioq.erl"},{line,150}]},{ioq,handle_info,2,[{file,"src/ioq.erl"},{line,123}]},{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,616}]},{gen_server,handle_msg,6,[{file,"gen_server.erl"},{line,686}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]},{gen_server,call,[ioq,{request,<0.24352.1>,{append_bin,[<<0,0,32,0>>,[<<6,66,160,149,155,150,189,119,66,50,121,52,14,190,9,143...}}
couchdb-backup-service-01 | [warning] 2021-05-21T08:27:57.467050Z nonode@nohost <0.428.0> -------- exit for compaction of ["shards/00000000-7fffffff/yoda_filesystem.1614838752"]: {{badarg,[{erlang,monitor,[process,{main,'clouseau@<IP_ADDRESS>'}],[]},{ioq,submit_request,2,[{file,"src/ioq.erl"},{line,187}]},{ioq,maybe_submit_request,1,[{file,"src/ioq.erl"},{line,150}]},{ioq,handle_info,2,[{file,"src/ioq.erl"},{line,123}]},{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,616}]},{gen_server,handle_msg,6,[{file,"gen_server.erl"},{line,686}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]},{gen_server,call,[ioq,{request,<0.22588.1>,{pread_iolist,40340132370},compaction,<0.22589.1>,undefined},infinity]}}
couchdb-backup-service-01 | [info] 2021-05-21T08:27:57.467190Z nonode@nohost <0.222.0> -------- db shards/00000000-7fffffff/yoda_filesystem.1614838752 died with reason {{badarg,[{erlang,monitor,[process,{main,'clouseau@<IP_ADDRESS>'}],[]},{ioq,submit_request,2,[{file,"src/ioq.erl"},{line,187}]},{ioq,maybe_submit_request,1,[{file,"src/ioq.erl"},{line,150}]},{ioq,handle_info,2,[{file,"src/ioq.erl"},{line,123}]},{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,616}]},{gen_server,handle_msg,6,[{file,"gen_server.erl"},{line,686}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]},{gen_server,call,[ioq,{request,<0.22588.1>,{pread_iolist,40340132370},compaction,<0.22589.1>,undefined},infinity]}}

couchdb-backup-service-01 | [info] 2021-05-21T08:27:57.468479Z nonode@nohost <0.28448.1> -------- Starting compaction for db "shards/80000000-ffffffff/yoda_filesystem.1614838752" at 125776
couchdb-backup-service-01 | [notice] 2021-05-21T08:27:57.468708Z nonode@nohost <0.428.0> -------- ratio_dbs: Started compaction for shards/80000000-ffffffff/yoda_filesystem.1614838752
couchdb-backup-service-01 | [error] 2021-05-21T08:27:57.469504Z nonode@nohost <0.22508.1> -------- gen_server ioq terminated with reason: bad argument in call to erlang:monitor(process<EMAIL_ADDRESS>at ioq:submit_request/2(line:187) <= ioq:maybe_submit_request/1(line:150) <= ioq:handle_info/2(line:123) <= gen_server:try_dispatch/4(line:616) <= gen_server:handle_msg/6(line:686) <= proc_lib:init_p_do_apply/3(line:247)
couchdb-backup-service-01 |   last msg: timeout
couchdb-backup-service-01 |      state: {state,10,0.01,{[{request,{main,'clouseau@<IP_ADDRESS>'},{open,<0.28430.1>,<<"shards/80000000-ffffffff/yodadev_features.1614849634/de6fcb4cc39fbd3e0c1d621d441e9057">>,<<"standard">>},other,{<0.28430.1>,#Ref<0.2791382983.2

Short appendix to what @schneuwlym wrote.
I was able to completely turn off auto-compaction (smoosh).
After insertion of ~70k records, I triggered manually a compaction task.
It was crashing at the very end (Fauxton showed progress ~99%) with the above mentioned error.
CPU and memory usage was decent all the time.

{undef,[{math,ceil,[1.6],[]},{couch_emsort,num_merges,2, is quite odd. I can't figure out where it is coming from
I see erlang ceil function in https://github.com/apache/couchdb/blob/ce596c65d9d7f0bc5d9937bcaf6253b343015690/src/couch/src/couch_emsort.erl#L363-L366 is calling erlang:ceil in https://github.com/erlang/otp/blob/8b29b1ca870e6b31a0f3da067ebf4b1b4ceaa969/erts/preloaded/src/erlang.erl#L566-L570 which seems to call a C NIF function but not math:ceil which the error indicates.
@schneuwlym what version of Erlang are you running? Wonder if there is something related to that. ceil is a fairly new function in Erlang 20+ only.

Hi nickva
Thanks for your reply. We are using Version 19.3.
erl -eval '{ok, Version} = file:read_file(filename:join([code:root_dir(), "releases", erlang:system_info(otp_release), "OTP_VERSION"])), io:fwrite(Version), halt().' -noshell
19.3

@schneuwlym Thanks for replying. Erlang 19 would explain why you got an undef error there. That ceil/1 function is not present in Erlang 19. Unfortunately Erlang 19 is not supported any longer for CouchDB 3.x releases.
From the error message it seems as if someone had "patched" the CouchDB release to compile on 19.x and replaced the undefined ceil/1 function (which would have prevented compiling on < 20.0 releases) with math:ceil/1. However, math:ceil/1 is also not defined in < 20.0 release but we'd only find out about it at runtime.
4> catch ceil(1.6).
{'EXIT',{{shell_undef,ceil,1,[]},
         [{shell,shell_undef,2,[{file,"shell.erl"},{line,1061}]},

5> catch math:ceil(1.6).
{'EXIT',{undef,[{math,ceil,[1.6],[]},
                {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]},

Hi nickva, thanks for your reply.
Indeed it seems that our packager patched the source to build couchdb
--- a/src/couch/src/couch_emsort.erl.clean      2021-01-14 17:18:40.436549175 +0000
+++ a/src/couch/src/couch_emsort.erl    2021-01-14 17:17:39.128103923 +0000
@@ -133,6 +133,8 @@
 -export([add/2, merge/1, merge/2, sort/1, iter/1, next/1]).
 -export([num_kvs/1, num_merges/1]).

+-import(math, [ceil/1]).
+
 -record(ems, {
     fd,
     root,
--- a/src/couch/rebar.config.script.clean       2021-01-14 17:28:34.570100193 +0000
+++ b/src/couch/rebar.config.script     2021-01-14 19:06:56.523186136 +0000
@@ -107,7 +107,7 @@
         };
     {unix, _} when SMVsn == "1.8.5" ->
         {
-            "-DXP_UNIX -I/usr/include/js -I/usr/local/include/js",
+            "-DXP_UNIX " ++ os:getenv("JS_CFLAGS"),
             "-L/usr/local/lib -lmozjs185 -lm"
         };
     {win32, _} when SMVsn == "60" ->
@@ -164,7 +164,7 @@
 CouchJSEnv = case SMVsn of
     "1.8.5" ->
         [
-            {"CFLAGS", JS_CFLAGS ++ " " ++ CURL_CFLAGS},
+            {"CFLAGS", JS_CFLAGS ++ " " ++ CURL_CFLAGS ++ os:getenv("JS_CFLAGS")},
             {"LDFLAGS", JS_LDFLAGS ++ " " ++ CURL_LDFLAGS}
         ];
     _ ->

But what I don't understand is, the dependency page (https://docs.couchdb.org/en/3.1.1/install/unix.html#dependencies) mentions Erlang OTP 19.x as requirement. Do I don't understand the line "Erlang OTP (19.x, 20.x >= <IP_ADDRESS>, 21.x >= 21.2.3, 22.x >= 22.0.5)" or is this information wrong? Since it is comma sparated, I assumed that 19.x is fully supported...
What Erlang version should we try? 22 or should we already try the latest, eg 24? Since 24 is not mentioned in the list I guess we should go with 22, right?
Regards
Mathias

@schneuwlym that was a mistake on our part, we have documented it as "soft" supported in release notes for 3.0:  https://docs.couchdb.org/en/3.1.1/whatsnew/3.0.html
19.x - “soft” support only. No longer tested, but should work.

Basically saying we're not going to go out of our way to break it but it may break at some point accidentally and we're not testing it. With ceil the idea I think was that a failed compilation error would indicate that it obviously won't build. In retrospect, we should have taken a firmer stance and explicitly indicated we are not supporting Erlang versions < 20 in documentation at that point.
I already updated the rebar config file to disallow Erlang 19 and will update the dependencies list in unix.html docs file too.
As for which versions to try. The binary packages we release are shipped with the latest versions of 20. In production at Cloudant I have seen 20 run for a few years without any issues. So could pick <IP_ADDRESS> for example. However, the downside there is Erlang developers promise to support only the last two versions behind the current one. If that's a concern perhaps pick the latest patch version of 23 and make sure to periodically check for fixes.

Note that 23.x and 24.x are not yet supported in CouchDB 3, unless you are building from the 3.x branch directly. For 3.1.1 you cannot go any newer than 22.x.
See: https://docs.couchdb.org/en/3.1.1/install/unix.html#installation-from-source for the versions supported at the time 3.1.1 was released. We acknowledge 19.x was incorrectly included there, and will support 23.x and 24.x with the forthcoming 3.2 release.

@wohali good point, thanks for clarifying

Hi
Updating the Erlang compiler to 22 definitely seems to fix our issue!
Thank you very much for your help!
Best regards
Mathias


python312Packages.hishel: 0.0.29 -> 0.0.30

Diff: https://github.com/karpetrosyan/hishel/compare/refs/tags/0.0.29...0.0.30
Changelog: https://github.com/karpetrosyan/hishel/blob/0.0.30/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 327124 run on x86_64-linux 1

10 packages built:

pdm
pdm.dist
python311Packages.githubkit
python311Packages.githubkit.dist
python311Packages.hishel
python311Packages.hishel.dist
python312Packages.githubkit
python312Packages.githubkit.dist
python312Packages.hishel
python312Packages.hishel.dist


Issue #62: For calcite SqlSearchOperator expand the Sarg Literals into a simple predicates.

Invoke RexUtil.expandSearch to do the conversion.

Please rebase when you get a chance, @hbutani. Thanks!


Long double from chars

@pdimov What do I need to adjust for ctest to find tests in the Jamfile that have configuration options? Right now all of the runners are failing for no tests found. To support __float128 libquadmath needs to be linked when using gnu++XX.

Why are you linking libquadmath in all the tests, instead of just the float128 one?

I'll take a closer look later, no time at the moment, but what I think you want here is to make the library build link to quadmath and not the test executables. Users don't do anything with the test executables, so if the library is not built with float128 support, it won't support float128 regardless of what you put into test/Jamfile.
How the library is built is described in build/Jamfile, not in test/Jamfile.
In addition, you should never use <linkflags> to link to a library. This won't work correctly for all shared/static cases. You want
lib quadmath ;

and then instead of <linkflags>-lquadmath, <library>quadmath.

Rather than trying to shoe horn the old from_chars impl to support 80 and 128 bit long double's it is likely best to start over with ryu/generic_128


Updating check-java.sh and server.xml templates to upstream version

Pull Request (PR) description
Updates check-java.sh and server.xml templates to upstream version. Especially the check-java update is required, when using a java version > 8 (or 1.8, depending which versioning scheme you look at.
This Pull Request (PR) fixes the following issues
Fixes #339
Kind of fixes #300
This replaces PR #317.

The tests are failing. Could you have a look?

Will do (probably on weekend), didn't find the time yet, sorry.
Will revert the removal of < 8 support - as you said, it should be another PR, that should make the tests be green again.

@ekohl PR is now updated

Can you clean up the commit history (get rid of merge commit, combine fixup commits)? Or set the PR to allow edits by maintainers so we can do it.

Also note that your kps email address is not registered with your GitHub account.

@kenyon Thanks for the hints. Hope i won my fight against git rebase successfully now... (i am always fighting with it)

@kenyon @ekohl Can i get a merge please?


ChibiOS needs to handle optional thread data better

Currently, if there are no thread status, it would crash. I fixed (kludge) the crash just to move forward but we need to handle this better.

We need to either remove those columns and/or provide help for how the user can get those stats (what do they have to do in their FW).
I also do not like the top of the stack being printed for each thread. If you don't have thread names, so be it. Don't combine that with Status. that column should simply be Status.

@vrepetenko, can you take a look at this?

@vrepetenko wrote following in the Cortex-Debug issue

there is a problem with stack size detection in current ChibiOS thread_t implementation, no chance to get stack size/stack start, only stack base (bottom) and free size. New ChibiOS version with stack size is coming, but how should we fill stack top , stack start now? I use SP value for stack start/top now, but sometimes SP can have zero value, is it ok?

So it seems that you are using the released version (which i used too for my tests)
According to the info above, the output looks ok to me

Check version of the OS if you can. Either an (non)existence of a variable can perhaps help
Depending on that, you can eliminate the columns you will never have
Or for missing information, use '0x????????' and do the following
Free RTOS also has this issue. Some stack info is optional, and if it does not exist, I explain why in the help section. I also do not read any memory if I do not have enough info.

No, using SP does not make sense. There is only one SP and only makes sense for one thread. Do not try to guess is my opinion.
Please see the screenshots in the top-level readme.md file.

One thing i found out is that they have a variable in their thread handle named sp. most likely this variable was ment

One thing i found out is that they have a variable in their thread handle named sp. most likely this variable was meant

Could be. We may have to study the OS code or ask. Any OS will need to remember the tasks stack-top to eventually switch to that task
So, we combined 4 things into one column? Thread Name, Address, State and Priority.  But, flags gets its own column. Not sure how I feel about this. I agree that this is too many columns

Here is the FreeRTOS view with expanded Help -- I thought I had it in fixed width font and it is broken right now. You won't see any HELP is none is needed

Warning: I am going through one major edit/refactoring
It is bleeding edge indeed

Done. Varialble values are no longer suffixed with '-val', '-exp', etc. Instead we create an object... Meaning to do this forever
https://github.com/mcu-debug/rtos-views/blob/a42fb075c327569e03107763173e64b3d7bae426/src/rtos/rtos-common.ts#L18
export interface VarObjVal {
    val: string;                    // The value
    ref: number;                    // Variable reference. Technically, this is not a number, it is handle
    exp: string | undefined;        // This is the expression that represents the value
}

export type RTOSStrToValueMap = { [key: string]: VarObjVal };

@vrepetenko, can you take a look at this?

sure, it is in todo list

Currently, if there are no thread status, it would crash. I fixed (kludge) the crash just to move forward but we need to handle this better.

We need to either remove those columns and/or provide help for how the user can get those stats (what do they have to do in their FW).
I also do not like the top of the stack being printed for each thread. If you don't have thread names, so be it. Don't combine that with Status. that column should simply be Status.

Thread name, address, state and priority combined in one column to make table more compact, otherwise it looks weird on normal screen size.

Now there is help information:

Thread name, address, state and priority combined in one column to make table more compact, otherwise it looks weird on normal screen size.

I personally do not see a need to always show the thread address. Either name or thread address as a fallback would be enough.
To further improve size, you can combine Stack stuff into a percentage column, as at least i do not see a big value in listing the start and end address. It's much more interesting how much is currently (and assumed 'peak' by looking for not default stack pattern) is used/free. That's why i introduced the percentage column type and added it to the uC/OS-II view (see a screenshot in the README.md)
After that there should be enough/more space for a separate state and Prio column

Thread name, address, state and priority combined in one column to make table more compact, otherwise it looks weird on normal screen size.

I personally do not see a need to always show the thread address. Either name or thread address as a fallback would be enough.
To further improve size, you can combine Stack stuff into a percentage column, as at least i do not see a big value in listing the start and end address. It's much more interesting how much is currently (and assumed 'peak' by looking for not default stack pattern) is used/free. That's why i introduced the percentage column type and added it to the uC/OS-II view (see a screenshot in the README.md)
After that there should be enough/more space for a separate state and Prio column

I would suggest to keep thread address, it is really useful to quick create watch like this: (thread_t*) [thread address].
There is no way to show percentage column now, it is not possible to get thread stack size, only SP, wabase (stack bottom) and peak usage - by scanning 0x55 from wabase to SP.
Question: is it possible to get MCU registers (to get real SP for current thread)?

Question: is it possible to get MCU registers (to get real SP for current thread)?

Majority of the time evaluating $sp gets you the current SP right? But it could be wrong. When the program is paused, execution can be anywhere including in the kernel, about to context switch and SP could be in no thread. Current thread is just a notion kept by the Kernel.
Note: I do not like us to get down to the register level here.  I want this extension to be processor agnostic. There will be RISC-V clients.
I recommend you look at the following (See line 478)
https://openocd.org/doc/doxygen/html/chibios_8c_source.html
On the surface, it appears to be the p_ctx field of the data structure. But this data structure is available only if the user enabled debug. And, still might not be right for current thread.

yes, I know ch_debug structure, you can use it in plugins/code with restricted symbols reading.

Now, I am beginning to wonder if the StackTop for any RTOS is correct. I have to run some experiments. There is no way any kernel can keep this up-to-date while the current thread is running.  At best the StackTop for FreeRTOS for instance would be the top the last time it got kicked off.

Yup. For FreeRTOS, the Stack Top is definitely wrong. For current, I have a couple of options

Depending on arch use $sp. For now, this works for both ARM, ARC, RISC-V. Even x86!! But not Xtensa -- it is $a1. Anyways, these are the architectures I run into.
If we know the stack range, it should be within that range and we are done
Else we may still be okay to use the $sp as if it is in Kernel code, there shouldn't be (mostly) a current-thread. The window of vulnerability is tiny
We can figure this out if this becomes a problem that the stack top should be within a certain range of a user-specified limit or we would not use it.

Just thinking out loud
I will make a common function to get the current stack pointer that we all can use.

Yup. For FreeRTOS, the Stack Top is definitely wrong. For current, I have a couple of options

Depending on arch use $sp. For now, this works for both ARM, ARC, RISC-V. Even x86!! But not Xtensa -- it is $a1. Anyways, these are the architectures I run into.

If we know the stack range, it should be within that range and we are done

Else we may still be okay to use the $sp as if it is in Kernel code, there shouldn't be (mostly) a current-thread. The window of vulnerability is tiny

We can figure this out if this becomes a problem that the stack top should be within a certain range of a user-specified limit or we would not use it.

Just thinking out loud
I will make a common function to get the current stack pointer that we all can use.

I would be very nice if we could get the actual stack usage of the current running thread, as it improves debugging stack issues a lot.
One more thing to consider is if the current execution is a interrupt/exception (mostly your point 3, but not sure what you mean exactly with kernel code), as they mostly use a dedicated system stack (initial stack pointer before start of OS). At least it's like that for uC/OS-II on Cortex-M processors.
When we implemented a uC/OS-II J-Link thread aware plugin we did this by checking the OSIntNesting variable of uC/OS and the NVIC VECTACTIVE bit. So we maybe also need a common function to test that that one.
Just my thoughts on this topic
@haneefdm Did you do anything regarding this topic until now?
Best regards

Unfortunately, I have not had any time to look at this. By Kernel code meaning when you in the scheduler when it is about to swap out one thread with another. But this could include interrupt/exceptions
VECTACTIVE is a good idea but it is very ARM specific. I am expecting non-ARM clients as well. I will keep this in mind.

Hi, @PhilippHaefele !
Do you run J-Link plugin on macOs without signing plugin lib?

When we implemented a uC/OS-II J-Link thread aware plugin we did this by checking the OSIntNesting variable of uC/OS and the NVIC VECTACTIVE bit. So we maybe also need a common function to test that that one.

Hi, @PhilippHaefele !
Do you run J-Link plugin on macOs without signing plugin lib?

When we implemented a uC/OS-II J-Link thread aware plugin we did this by checking the OSIntNesting variable of uC/OS and the NVIC VECTACTIVE bit. So we maybe also need a common function to test that that one.

Hi,
sorry but i do not use it on MacOS, so i didn't have seen this issue.
Best regards
Philipp

@haneefdm @vrepetenko Are there any points open regarding ChibiOS
I will split out the SP thing of the current running task into a separate issue

@haneefdm @vrepetenko Are there any points open regarding ChibiOS?
I will split out the SP thing of the current running task into a separate issue

Do not remember any but I am working on new version now:

and would like to discuss separation of UI(View) and RTOS Data Model.

Ok, so i will close this one now.
Your approach looks and reads reasonable.
Please create another issue for discussion of this if needed.

I will create a new issue based on @vrepetenko comment
A couple of things:

Such open-coded generation of HTML is not scaleable and not good enough separate of model and view
Each RTOS, should have more info on what is interesting to look at. Example above is good. I want to see semaphore states, timers, etc.

It is one of those things. I started out small, I didn't know much about WebViews back then and followed examples to generate the entire HTML/CSS on the fly. But with memory view, I learned a LOT, and I used React
My worry is that React is not that easy or simple for most people. It also has quite a few UI bugs/quirks that they can't fix for legacy reasons. Using React (or something else) means that the view(s) is totally separated from the model(s)

Submitted new issue https://github.com/mcu-debug/rtos-views/issues/29


[FLINK-3383] remove Maven deployment from Travis CI config

Deployment will be handled by Apache's buildbot instances which trigger the deployment of snapshot versions every night. This way, we have not only separated deployment from CI testing, but also improved the reliability of the test and deployment infrastructure.
I would like to merge this pull request once I've set up the buildbot infrastructure and verified that it works. I will probably do this next week. In the meantime, we can discuss any problems and suggestions here.

Changes look good. Do we have another way of deploying the snapshots then?

Thanks for the comment. Yes, as stated above, I would like to migrate snapshot deployment to the a nightly Buildbot job at Apache's infrastructure (like we also do for the documentation). I'll probably find some time to do this next week.

Snapshots are now deployed nightly using the ASF Jenkins installation: https://builds.apache.org/job/flink-snapshot-deployment/


Docker mm update

Hi
I have just installed mm using your docker image which is supposed to be the latest one as I checked in the docker hub that your files were updated 2 days ago.
However I get a message regarding updating my mm. I thought I had the latest one released 2 days ago i.e. 2.7.1. Can you please help ? I have already deleted the image on portainer and pulled the latest one but still no joy.
Also how do I check my mm version ? Do I have to login into mm container ? If yes what is the username ?
Thank you again.

Hi, I just checked the Travis CI builds and it fails because it couldn't find Electron v3.0.13 for linux-armv6l:
/opt/magic_mirror/node_modules/electron/install.js:49
  throw err
  ^
Error: Failed to find Electron v3.0.13 for linux-armv6l at https://github.com/electron/electron/releases/download/v3.0.13/electron-v3.0.13-linux-armv6l.zip
    at Request.<anonymous> (/opt/magic_mirror/node_modules/nugget/index.js:169:61)
    at emitOne (events.js:115:13)
    at Request.emit (events.js:210:7)
    at Request.onRequestResponse (/opt/magic_mirror/node_modules/request/request.js:1062:10)
    at emitOne (events.js:115:13)
    at ClientRequest.emit (events.js:210:7)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:564:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:116:23)
    at TLSSocket.socketOnData (_http_client.js:453:20)
    at emitOne (events.js:115:13)
The command '/bin/sh -c npm install --unsafe-perm --silent' returned a non-zero code: 1
The command "docker build -t $DOCKER_USER/docker-magicmirror:raspberry -f ./raspberry/Dockerfile ." exited with 1.

Therefore Travis CI didn't push a new version to the Docker Hub. I'll check what the corse for this is.

Any progress on this? Thanks.

Hope this will be fixed soon. Thanks for all efforts.

I am getting this on the non-armhf build as well.

Any update?

Any update on this?

as long as this is not solved here you can use my setup.

@khassel Thx, but the container is restarting every 5 to 10 seconds. I'll stick this right now.

Sorry for the late response. I’ll take another look at this.

@trombonekenny @Tezzlicious @ax42 @khassel @idoodler I provided a fix for the issue in PR #25. The image was successfully updated. Could someone please verify, that everything works as expected?

@bastilimbach This is not working on my side.
I changed FROM bastilimbach/docker-magicmirror:raspberry to  FROM bastilimbach/docker-magicmirror:latest and I am getting the error no matching manifest for linux/arm64 in the manifest list entries

@idoodler Ah probably because I only added arm and not arm64. Will add that to the travis build

@idoodler See commit fad5dea42c636fe3139501255c5ebe07d93a540c
Could you please try again after Travis pushed the image?

This is the output of manifest inspect. Looks good:
Created manifest list docker.io/bastilimbach/docker-magicmirror:latest
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 3891,
         "digest": "sha256:1489c63d25972d6cbfb2104b9dbcac1fb5cec3baff3002c97220f2b1929140c9",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 3891,
         "digest": "sha256:1489c63d25972d6cbfb2104b9dbcac1fb5cec3baff3002c97220f2b1929140c9",
         "platform": {
            "architecture": "arm",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 3891,
         "digest": "sha256:1489c63d25972d6cbfb2104b9dbcac1fb5cec3baff3002c97220f2b1929140c9",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      }
   ]
}

@bastilimbach I am not using plain docker, but balena-cloud. It looks like your image is working again. But I do have issues execute RUN chmod +x /opt/moduleInstall.sh the following Dockerfile.
Issue:
panic: standard_init_linux.go:175: exec user process caused "exec format error" [recovered]
FROM bastilimbach/docker-magicmirror:latest

COPY ./config /opt/magic_mirror/config
COPY ./modules /opt/magic_mirror/modules
COPY ./moduleInstall.sh /opt

RUN chmod +x /opt/moduleInstall.sh
RUN /opt/moduleInstall.sh
RUN apt-get update && apt-get install -y libraspberrypi-bin

@bastilimbach I am running on a Raspberry Pi 3 B+ (I won't response the next few hours because I have to sleep now)

couldn't test earlier, now running on a raspi3 doesn't work for me, getting the standard_init_linux.go:211: exec user process caused "exec format error" error so it seems this image is not build for arm
pi@raspberrypi3:~ $ docker images
REPOSITORY                        TAG                 IMAGE ID            CREATED             SIZE
bastilimbach/docker-magicmirror   arm                 bb905b257622        29 hours ago        1.19GB
bastilimbach/docker-magicmirror   latest              bb905b257622        29 hours ago        1.19GB

anyone with the same problem?

Looking into the travis-file: Afaik you are building 3 times the same image for the architecture the travis job is running on, probably amd64.

Mh, thats strange. I thought with the following line I would configure qemu and therefore compile in arm. Used to do that also with the old raspberry pi image. Maybe I need to add a --arch to the docker build command:
docker run --rm --privileged multiarch/qemu-user-static:register --reset

I will open a new issue.


macos build fails with unknown random_device and mt19937 types

eos/cyberway/tests/chaindb/main.cpp:80:14: error: no type named 'random_device' in namespace 'std'
        std::random_device rd;
        ~~~~~^
eos/cyberway/tests/chaindb/main.cpp:81:21: error: expected ';' after expression
        std::mt19937 g(rd());
                    ^
                    ;
eos/cyberway/tests/chaindb/main.cpp:81:14: error: no member named 'mt19937' in namespace 'std'

#49


🔨 grapher schema: update to version 006

Sibling PR of https://github.com/owid/owid-grapher/pull/4108 that introduces a breaking change to the Grapher config schema (the relatedQuestions array is migrated to a relatedQuestion object).

This conflicts with later changes in master, which were made by merging https://github.com/owid/etl/pull/3558 (only two files though).
This PR proposes to use https://files.ourworldindata.org/schemas/grapher-schema.006.json, but currently master points to https://files.ourworldindata.org/schemas/grapher-schema.latest.json for some files (not all).
@sophiamersmann Could you look into the conflict and decide whether we should point to one or the other?

I'll close this PR because it's outdated and I probably won't merge it anytime soon.
As for your question: If the schema file was referred to in a comment, I replaced it with the latest version, so that we don't have to update those instances when the schema version is bumped. Both are fine though – it doesn't matter much.


Add test composability KEP

rebased

Hmm, I just had an idea: instead of defining each of these types as different settings (asserts, apply, commands, etc), what if we had one setting that was a list and then users can define their order instead of having to learn it?
Something like:
steps:
- assert:
     path: ../assert.yaml
- command:
     command: kubectl apply

That would be both more flexible and more obvious.


chdir: No such file or directory

FROM dockerfile/java:oracle-java8

ADD app.jar /app/app.jar

CMD java -Djava.awt.headless=true -server -jar /app/app.jar

EXPOSE 8080

this image will fail with chdir: No such file or directory error without -w /app/ option.
Workaround: specify -w /app/ option.

I looks like dockerfile/java:oracle-java8 defines /data to be the WORKDIR
You could add WORKDIR /app to your Dockerfile -- then you won't need -w

@onsi this Dockerfile works great inside Docker :)

can you send me the logs you get out of ltc create

No port specified, using exposed ports from the image metadata.
	Exposed Ports: 8080
No working directory specified, using working directory from the image metadata...
Working directory is:
/data
Monitoring the app on port 8080...
No start command specified, using start command from the image metadata...
Start command is:
/bin/sh -c java -Djava.awt.headless=true -server -jar /app/app.jar
Creating App: app2
.30 Mar 22:53 [APP|0] Creating container
.....30 Mar 22:53 [APP|0] Successfully created container
30 Mar 22:53 [APP|0] chdir: No such file or directory
30 Mar 22:53 [APP|0] Exit status 255
30 Mar 22:53 [APP|0] Creating container
.....30 Mar 22:53 [APP|0] Successfully created container
30 Mar 22:53 [APP|0] chdir: No such file or directory
30 Mar 22:53 [APP|0] Exit status 255
30 Mar 22:53 [APP|0] Creating container
.....30 Mar 22:53 [APP|0] Successfully created container
30 Mar 22:53 [APP|0] chdir: No such file or directory
30 Mar 22:53 [APP|0] Exit status 255
............................................
app2 took too long to start.

And here is logs from ltc dl: https://gist.github.com/bsideup/daf6f26121dc01d01ef5

@bsideup - this one's definitely interesting ;)
I was hoping to take a look today but ran out of time.  Will try again tomorrow - is there a repo you can point me to (either github or docker) that will let me reproduce exactly this issue?

@onsi since Dockefile is simple (see this issue details) I can easily setup repo for you little bit later. You can reproduce it by yourself as well I think

I think I've identified the root cause.  Docker automatically creates creates the working directory if it does not already exists.  Garden does not do this.  I'll open an issue in Garden-Linux.

This was addressed with [#91550852]; fixed in CF Garden v0.290.0, landed in CF Diego on 0.1412.0, which was upgraded to 0.1424.1 with Lattice v0.5.0.
@bsideup Can you retry with our latest version and let us know if it works?

Closing this issue.  Re-open if this issue resurfaces.
Thanks again!


Restore rootFS bricks FaceID

Describe the bug
After using restoreFS option, faceID stopped working. When trying to re-setup faceID, it just says "move up" or "move down". Sometimes it shows a generic error "FaceID isn't available".
Tried everything:
-Restart
-Rejailbreak
-Restore
-DFU restore (+icloud backup)
-OTA update
I'm not the only one; just Google "reddit jailbreak rootfs faceid", tens of results show up.
In some cases they associate the issue with having had a screen repair in the past. It's not my case.
To Reproduce
Steps to reproduce the behavior:

Do restore rootFS
FaceID magically stops working

Device (please complete the following information):

iOS Version: iOS11 (did rootFS in this version), faceID continues not working on iOS12 and iOS13.
iOS Device: iPhone X
unc0ver Version: don't remember

Place an "x" between the brackets if true:

[ ?] this is a bug others will be able to reproduce
[ x] this issue is present with all tweaks uninstalled(except for default packages) or disabled
[ xxxxxxx] this issue is present after a rootfs restore
[ ?] this issue is present on the latest version of unc0ver

I have the same issue. I used to do rootfs frequently on 4.3.1 with no problems until I got my screen replaced at Apple. Approximately 2 months after the screen replacement, first time I did Rootfs gave me faceid error. Since then I tried reset, DFU restore, IOS update (13.5) unc0ver updates until 5.2.0 and nothing so far seems to be getting it to work again.
What I have noticed is; flood illuminator isn’t as bright as it was before (I used to see it brighter when I was recording a video of my screen with another phone)
I’m also very sure that there are many people who have their faceid bricked. And I am hoping that someday there will be a software fix for this. Looking for for it


Request to update the token address and decimal attribute (PR attached)

Request to update the token address and decimal attribute
Current PR: https://github.com/solana-labs/token-list/pull/22971
OLD PR : https://github.com/solana-labs/token-list/pull/22567#issue-1174373447

merged

Thank you! :) @keone


validateNonSpecial IP returns 500 errors

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
change  https://github.com/rancher/rancher/blob/c8da22fb9218fcfa5df8921bd188afc3517462af/tests/core/test_dns.py#L106 to remove the indent
Run test_dns.py
Result:
Errors with status code 500 are returned rather than the expected 422
Other details that may be helpful:
Tested on 573a3695c048724e31cd80e9e24600a5ae4fac12

Tested with 2.1.9-rc3. Able to reproduce the issue that we get a "500 Server Error" when trying to create a dnsRecord pointing to invalid ip address.
{
"baseType": "error",
"code": "ServerError",
"message": "<IP_ADDRESS> may not be unspecified (<IP_ADDRESS>)",
"status": 500,
"type": "error"
}

Tested with latest build from master - c098b38 we get a "422 InvalidOption" error when trying to create a dnsRecord pointing to invalid ip address.
{
"baseType": "error",
"code": "InvalidOption",
"message": "<IP_ADDRESS> may not be unspecified (<IP_ADDRESS>)",
"status": 422,
"type": "error"
}


Merge this repo into purescript-parsing?

https://github.com/purescript-contrib/purescript-parsing/issues/88
All of the dependencies are now from purescript or purescript-contrib.

https://github.com/purescript-contrib/purescript-parsing/pull/219


Issue while writing streaming data from Databricks to SQL DW (Synapse)

Doc: https://docs.microsoft.com/en-ca/azure/databricks/data/data-sources/azure/sql-data-warehouse?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-ca%2Fazure%2Fazure-databricks%2FTOC.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-ca%2Fazure%2Fbread%2Ftoc.json#feedback
Trying to write data into SQl DW through databricks stream data frame. process is trying to delete the temp folder in the BLOB storage and throwing below. In the documentation I see that process will not automatically cleanup tempdir. Is it true? if true, then why is this error? Using below query in python
df1.writeStream
.format("com.databricks.spark.sqldw")
.option("url", sqlDwUrlSmall)
.option("tempDir", tempDir)
.option("forwardSparkAzureStorageCredentials", "true")
.option("dbTable", "SampleTable")
.option("checkpointLocation", "/tmp_checkpoint_location1")
.option("numStreamingTempDirsToKeep", -1)
.start()
ERROR AzureNativeFileSystemStore: Encountered Storage Exception for delete on Blob: , Exception Details: This operation is not permitted on a non-empty directory. Error Code: DirectoryIsNotEmpty 19/12/20 21:27:32 ERROR AzureNativeFileSystemStore: Failed while attempting to delete key tempDirs/2019-12-20/21-27-29-347/adca2ed6-a705-4274-8c24-0f0e3d7c64a7/batch0

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9e046969-f169-7f56-601f-780aad0daa1f
Version Independent ID: e8c584e9-3f99-87ce-392a-df21fdb1f9b6
Content: Azure SQL Data Warehouse - Azure Databricks
Content Source: databricks/data/data-sources/azure/sql-data-warehouse.md
Service: azure-databricks
GitHub Login: @mamccrea
Microsoft Alias: mamccrea

Duplicate of #45074


Remove trailing whitespace

When setting up hyprland/workspaces, I'm setting format to {id} {windows}. This means that the workspaces are usually displayed as 3  which is great.
However, when I open a new workspace, it has no windows yet. The trailing space that is normally between the id and the windows is still there, though. This looks quite weird as the button of the workspace in Waybar is too long. Is there a way to remove training whitespace, or should we even do that by default? Or is there another way of having some space between the id and the windows (e.g., through styling)?

I'm running into the same problem. I think it could be useful to have an option for format fields in the config that will insert a string between the predefined tokens (i.e. icon, id, windows, etc.) if that string has a token following it.
For example, my current format for workspaces is {icon} {windows}, which will render to something like "3 " or "5 ". But maybe if it were something like {icon}< >{windows}, the white space would only render after icon if there is a valid non-blank value for windows.
I think this could be a useful generalized feature. Another example where it could be used is my mpris module, where my tooltip formatting could avoid a trailing " on " in certain cases by making the tooltip {title} [{length}]\nby {artist}< on >{album}
You could maybe do this with white space in general by default. That being said, people should be able to add spaces that lead or trail if they want to and it might be good to not change the behavior of existing configurations by automatically treating white space differently than it was treated before.


Update Vcpkg to fix SDL/X11 issues on Fedora systems

Fixing the same issue present in the base libtcod library

Thanks for the PR's!  If you have any other issues you can raise them on this repo or ask for help on one of the community chat channels.


linux_raspberrypi_4.19: Update to 4.19.32

The rpi-4.19.y branch has been rebased and the commit specified for
4.19.30 no longer exists upstream.
Signed-off-by: Peter A. Bigot<EMAIL_ADDRESS>

Lgtm

Thanks @pabigot. Merged to master.


Add splashColor and highlightColor to IconButton

Fixes https://github.com/flutter/flutter/issues/11397

Ping. :)


Publish bevy_rapier

Only two flavours are available for bevy_rapier as 2D and 3D which is fine however, if a library is depending on the crate and also has an optional 2D or 3D varient, it becomes awkward to forward the features.
Which ends up looking like the below:
# 2D
dim2 = []
dim2-enhanced-determinism = ["bevy_rapier2d/enhanced-determinism"]
dim2-parallel = ["bevy_rapier2d/parallel"]
dim2-serde-serialize = ["bevy_rapier2d/serde-serialize"]
dim2-simd-nightly = ["bevy_rapier2d/simd-nightly"]
dim2-simd-stable = ["bevy_rapier2d/simd-stable"]
dim2-wasm-bindgen = ["bevy_rapier2d/wasm-bindgen"]

# 3D
dim3 = []
dim3-enhanced-determinism = ["bevy_rapier3d/enhanced-determinism"]
dim3-parallel = ["bevy_rapier3d/parallel"]
dim3-serde-serialize = ["bevy_rapier3d/serde-serialize"]
dim3-simd-nightly = ["bevy_rapier3d/simd-nightly"]
dim3-simd-stable = ["bevy_rapier3d/simd-stable"]
dim3-wasm-bindgen = ["bevy_rapier3d/wasm-bindgen"]

A solution would be simply just to publish bevy_rapier which allows people to conditionally feature gate it as they wish given context. Its just so much cleaner.
Then simply would end up looking like:
dim2 = []
dim3 = []
enhanced-determinism = ["bevy_rapier/enhanced-determinism"]
parallel = ["bevy_rapier/parallel"]
serde-serialize = ["bevy_rapier/serde-serialize"]
simd-nightly = ["bevy_rapier/simd-nightly"]
simd-stable = ["bevy_rapier/simd-stable"]
wasm-bindgen = ["bevy_rapier/wasm-bindgen"]

Hi! I'm not sure how bevy_rapier itself would do this. Basically the bevy_rapier crate would have to optionally depend on both bevy_rapier2d and bevy_rapier3d, and it will end up having the exact same problem as you regarding transitively enabling features.
Also I'm not sure why you need to have these transitive features in the first place. The end-user can do this for example:
[dependencies]
your_crate = { version = "...",  features = [ "dim2" ] }
bevy_rapier2d = { version = "...", features = ["parallel", "simd-nightly"] }

Which would achieve the same effect as the transitive features.

Hi! I'm not sure how bevy_rapier itself would do this. Basically the bevy_rapier crate would have to optionally depend on both bevy_rapier2d and bevy_rapier3d, and it will end up having the exact same problem as you regarding transitively enabling features.
Also I'm not sure why you need to have these transitive features in the first place. The end-user can do this for example:
[dependencies]
your_crate = { version = "...",  features = [ "dim2" ] }
bevy_rapier2d = { version = "...", features = ["parallel", "simd-nightly"] }

Which would achieve the same effect as the transitive features.

Oh hey, good to know. That I wasn't too sure about, great to hear that Rust handles that.

Oh hey, good to know. That I wasn't too sure about, great to hear that Rust handles that.


Error when making a simple boxplot in ggplot2

Given the code,
> attach(mpg)
> ggplot(data = mpg, aes(y= displ))+
  geom_boxplot()

generates the following error;
Error: stat_boxplot requires the following missing aesthetics: y
In addition: Warning message:
Continuous x aesthetic -- did you forget aes(group=...)?

Solution:
ggplot2 requires both an x and y variable of a boxplot. Here is how to make a single boxplot
ggplot(data = mpg, aes(x = "", y = displ)) +
  geom_boxplot() +
  theme(axis.title.x = element_blank())


[release-1.2] Add support for passing extra env vars for all components

Description of your changes
Backport #189 to release-1.2
I have:

[x] Read and followed Upbound's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[x] Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested
See #189

Push validation error looks like a flake — just triggered rerun 👍🏻

Thanks @hasheddan, I think it is related to some kind related bug which we had other places as well. Cherry-picked submodule update commit (which contains kind version update I believe), let's see it helps.


[BUG] Error: no layer supported for trip

Context
What results were you expecting?
Animated trails.
Describe any relevant background information.
Tried both air-traffic-control and ais-movingpandas notebooks
Resulting behaviour, error message or logs
Describe what happened:
Include relevant screenshots, error messages, and logs:
Messages from chrome console:
Error: no layer supported for trip
at DF (2e45ea9e-addc-49fa-86d5-e00cd48e271c:3203:44197)
at Z1t (2e45ea9e-addc-49fa-86d5-e00cd48e271c:3210:2240)
at 2e45ea9e-addc-49fa-86d5-e00cd48e271c:3210:2763
Error: no layer supported for trip
at DF (f41eecfd-e191-441c-90a0-e313344a8d27:3203:44197)
at Z1t (f41eecfd-e191-441c-90a0-e313344a8d27:3210:2240)
at f41eecfd-e191-441c-90a0-e313344a8d27:3210:2763
Maps render, with no layer.
Environment

OS: [e.g. Windows 10] Windows 11
Browser: [e.g. Chrome, Safari] Chome
Lonboard Version: [e.g. 0.6.0] Latest experimental

Steps to reproduce the bug
Describe the actions that led you to encounter the bug. Example:
Running either notebook in examples folder : both air-traffic-control.ipynb and ais-movingpandas.ipynb

Error: no layer supported for trip

That looks like you have an old version of Lonboard loaded onto the JavaScript side of the page. This can happen especially if you installed a new version of Lonboard from inside Jupyter.
Try restarting your Jupyter server and in particular reloading the chrome tab. https://developmentseed.org/lonboard/latest/troubleshooting/

I kept getting the same message. Ended up rebooting the server, and creating a new conda environment "lonboardv1c".
Created a new folder, lonboard_trails2, and did the following steps:

cd D:\lonboard_trails2
git clone https://github.com/developmentseed/lonboard.git
poetry install
jupyter lab

Now I get this error message about static content missing when running the air-traffic notebook.
---------------------------------------------------------------------------
FileNotFoundError                         Traceback (most recent call last)
Cell In[1], line 7
      4 import requests
      5 from arro3.io import read_parquet
----> 7 from lonboard import Map
      8 from lonboard.experimental import TripsLayer

File [D:\lonboard_trails2\lonboard\lonboard\__init__.py:19](file:///D:/lonboard_trails2/lonboard/lonboard/__init__.py#line=18)
      5 from . import colormap, controls, experimental, layer_extension, traits
      6 from ._layer import (
      7     BaseArrowLayer,
      8     BaseLayer,
   (...)
     17     SolidPolygonLayer,
     18 )
---> 19 from ._map import Map
     20 from ._version import __version__
     21 from ._viz import viz

File [D:\lonboard_trails2\lonboard\lonboard\_map.py:58](file:///D:/lonboard_trails2/lonboard/lonboard/_map.py#line=57)
     38 # HTML template to override exported map as 100% height
     39 _HTML_TEMPLATE = """<!DOCTYPE html>
     40 <html lang="en">
     41 <head>
   (...)
     54 </html>
     55 """
---> 58 class Map(BaseAnyWidget):
     59     """
     60     The top-level class used to display a map in a Jupyter Widget.
     61
   (...)
     83     ```
     84     """
     86     def __init__(
     87         self, layers: Union[BaseLayer, Sequence[BaseLayer]], **kwargs: Unpack[MapKwargs]
     88     ) -> None:

File [~\.conda\envs\lonboardv1c\lib\site-packages\traitlets\traitlets.py:963](http://localhost:8888/lab/tree/examples/~/.conda/envs/lonboardv1c/lib/site-packages/traitlets/traitlets.py#line=962), in MetaHasDescriptors.__new__(mcls, name, bases, classdict, **kwds)
    960         classdict[k] = v()
    961     # ----------------------------------------------------------------
--> 963 return super().__new__(mcls, name, bases, classdict, **kwds)

File [~\.conda\envs\lonboardv1c\lib\site-packages\anywidget\widget.py:70](http://localhost:8888/lab/tree/examples/~/.conda/envs/lonboardv1c/lib/site-packages/anywidget/widget.py#line=69), in AnyWidget.__init_subclass__(cls, **kwargs)
     67 super().__init_subclass__(**kwargs)
     68 for key in (_ESM_KEY, _CSS_KEY) & cls.__dict__.keys():
     69     # TODO: Upgrate to := when we drop Python 3.7
---> 70     file_contents = try_file_contents(getattr(cls, key))
     71     if file_contents:
     72         setattr(cls, key, file_contents)

File [~\.conda\envs\lonboardv1c\lib\site-packages\anywidget\_util.py:264](http://localhost:8888/lab/tree/examples/~/.conda/envs/lonboardv1c/lib/site-packages/anywidget/_util.py#line=263), in try_file_contents(x)
    262 path = maybe_path
    263 if not path.is_file():
--> 264     raise FileNotFoundError(f"File not found: {path}")
    265 return FileContents(
    266     path=path,
    267     start_thread=_should_start_thread(path),
    268 )

FileNotFoundError: File not found: [D:\lonboard_trails2\lonboard\lonboard\static\index.css](file:///D:/lonboard_trails2/lonboard/lonboard/static/index.css)

Thank you, working now.


ffmppeg ffmpy bug

had to revert to an earlier commit for it work.  see here: https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/8211

Sorry, I'm not using ffmpy or ffmpeg in this repo and don't know the solution.
Can you send me a list of other extensions?

This is because when you Send to txt2img in the OpenPose Editor, the pose file is also sent to ControlNet-M2M after commit 51e10e2d2afda45db00e6507d36678665bd75840.
The label "ControlNet-M2M" must be excluded.

这是因为当您在 OpenPose Editor 中发送到 txt2img 时，姿势文件也会在提交51e10e2后发送到 ControlNet-M2M 。 必须排除标签“ControlNet-M2M”。

good hope merge


进行一个杨宝的添加，附被截胡吃瘪语音

:tada: This PR is included in version 1.4.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Pager Dependency from 0.18.0 to 0.19.0

Is there q specific reason why you want the update? I already updated to version 22 just now.


Allow customisation of decorations bg/fg decoration colours

e.g background #00CC60, foreground #000000

Also customize font. The default is very small and hard to see.

+1 to that. Too small for me too

@svenax, @surfncode thanks for the feedback. I'll look into what's possible with the vscode extension API.

+1 for styling and font, on Mac OS consolas doesn't look very great and seems smaller =(

In fact, I'll even make a PR, if nobody minds. It will expose font family, font size, background-foreground colors

Sure, sounds good, I'd be happy for you to help out, thanks!

I'm still having times new roman font.
Any ideas why that could be?

I've tried with various font families and it's the same all the time


cmd/compile/internal/gc: check Fatalf calls (no need to repeat "internal error")

Fatalf already prints "internal compiler error". No need to repeat the "internal error" in the argument.
Also, there are a few log.Fatalf calls. Should use the usual gc mechanism there.

Not urgent but simple cleanup anyway.


UsbBus constructor implementations can cause MCU faults in --debug run mode

When constructing a new UsbBus with usb-device 0.2.9 (atsamd21g implementation running on a SAMD21G17D without compile-time optimizations) fatal CPU errors can arise on the target device.
Likely this is due to stack overflow issues as it occurs while allocating a largish chunk of memory and may be a change more for the atsamd-hal/thumbv6m code that implements the UsbBus, but should check.
Some error and stack trace info:
UsbBusATSAMD21G17DDebugInfo.txt

Both myself and another Matrix user noted that our projects seemed to freeze up when calling UsbDevice.freeze(). We both were able to resolve it by updating the HAL that we were using to the latest version, and we had the suspicion that this was related to new cortex-m critical-section functionalities. We haven't investigated further, but I wanted to leave this breadcrumb.
This was specifically for STM32F4xx devices


HoneyBadger tickets should be created by a bot account

It's weird to have them created as a user who set it up or however it picks.

Maybe related to how you auth to HoneyBadger (github vs. not auth?)


Stop DayPicker component support

Better to import DayPicker from https://react-day-picker.js.org/ for every product separately


test: delete ginkgo test "NodePort with L7 Policy from outside"

The test case was introduced to cover issue #21954, but it turned out the test is buggy and caused a number of CI flakes (#25119). Consequently, PR #25236 put the test case under quarantine.
This commit removes that problematic test, as the target scenario has been covered by connectivity test in cilium-cli
(https://github.com/cilium/cilium-cli/pull/1547).
Fixes: #25119

/test

The Jenkins CI jobs passed. Marking as ready-to-merge.


NREL mismatch losses model due to non-uniform irradiance of cells

Is your feature request related to a problem? Please describe.
Add a the model described here. Eq. 7 is the relevant one.
Describe the solution you'd like
A function with it's input "relative mean absolute error" in pvlib.pvsystem (other losses models live here). Documentation/example would add the extra mathematical layers since they can vary. In the upcoming PR I will show cases of this.
Describe alternatives you've considered
Including the RMAD calculation in pvlib.tools, but I think it doesn't make much sense to add such a mathematical function. In the example it can be supplied.
The proposed model could also have a place in pvlib.bifacial.
Additional context
I'm adding an example case with data from an HSAT mock-up my thesis tutors made.

See also #1541 (should we close this one as a duplicate?).  The cited reference there (Prog in PV) is probably better than the EU PVSEC proceedings.

Definitely. Thanks for the reference @kandersolar !


Add operator arctan2 with its test code

Description
Add operator arctan2 with its test code
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[x] Changes are complete (i.e. I finished coding on this PR)
[x] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[x] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Comments
-The test cases only cover float16, float32 and float64.
@haojin2

@tingying2020 Your rebase has messed up your commit history, please clean it up so that this PR only contains your own commits.


add a verbose flag

First time I tried deploy:assets, program hung on "Uploading assets..."

Having a --verbose option would be really cool. I'm just having a problem where I'm deploying ember deploy --environment staging but somehow it seems to build the project for the development environment although buildEnv is configured as "staging" - would be really helpful to see what's actually happening in order to track that down.

I just ran across this @marcoow in one of my projects.  It seems that buildEnv sets the target for ember-cli-deploy, but not for ember-cli-deploy-build.  The later bases its environment off of a build.environment key.  So in your staging config in config/deploy.js add:
buildEnv: 'staging',
build: {
  environment: 'staging'
},

Not very DRY I know, but it did the trick for us :)


runtime/pprof: Remove SIGPROF if all events are stopped.

Fixed a bug.
/cc @chabbimilind

 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.

Good catch. I am curious, how did you identify the bug?

Good catch. I am curious, how did you identify the bug?

I am very interested in this feature, so I read the source code and found it. 😄


HDFS-17701. [FGL] Fix some javadocs

Description of PR
HDFS-17701. [FGL] Fix some javadocs.

hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/RwLock.java:86: warning: no @throws for java.lang.InterruptedException

hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/util/RwLock.java:93: warning: no @throws for java.lang.InterruptedException

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
6m 48s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ HDFS-17384 Compile Tests _

+1 :green_heart:
mvninstall
24m 40s

HDFS-17384 passed

+1 :green_heart:
compile
0m 41s

HDFS-17384 passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
0m 40s

HDFS-17384 passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
checkstyle
0m 39s

HDFS-17384 passed

+1 :green_heart:
mvnsite
0m 43s

HDFS-17384 passed

+1 :green_heart:
javadoc
0m 44s

HDFS-17384 passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
1m  5s

HDFS-17384 passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m 46s

HDFS-17384 passed

+1 :green_heart:
shadedclient
20m 40s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 34s

the patch passed

+1 :green_heart:
compile
0m 39s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
0m 39s

the patch passed

+1 :green_heart:
compile
0m 32s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
javac
0m 32s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 27s

the patch passed

+1 :green_heart:
mvnsite
0m 38s

the patch passed

+1 :green_heart:
javadoc
0m 32s

hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 generated 0 new + 3113 unchanged - 4 fixed = 3113 total (was 3117)

+1 :green_heart:
javadoc
1m  0s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m 37s

the patch passed

+1 :green_heart:
shadedclient
19m 31s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
200m 12s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 30s

The patch does not generate ASF License warnings.

284m  9s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestDecommission

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7256/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/7256

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 3268a7982c21 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
HDFS-17384 / ca3f13c3fa8787d82d311f0045fe0291b3c3420a

Default Java
Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7256/1/testReport/

Max. process+thread count
4344 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7256/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@ZanderXu Thanks for contribution. Merged


Merge osc-debug onto master

Implements fixes to the ASTERIA Oscillation code. This changes the call of the vital function photonic_energy_per_vol. Additionally, the example mixing class USSRMixing utilizes wrapper functions to mix the neutrino spectra.
I suggest that SimpleMixing be re-written to use this convention (Wrapper functions).

This pull request partially addresses #40, however the problems causing the mismatch in hits extend beyond the oscillation code.


[DarkSky] GooglePlayServicesUtil: Google Play services out of date

Application Dark Sky (weather, https://play.google.com/store/apps/details?id=net.darksky.darksky) doesn't seem to run on microG.
I've Installed all the latest versions (first from f-droid, then I installed them from the main page of microG) yet after starting DarkSky I get
04-12 17:06:03.277 6619-6642/net.darksky.darksky W/GooglePlayServicesUtil: Google Play services out of date.  Requires 10260000 but found 9258259

I know there are a couple of other tickets with this but they were usually solved by installing latest microG version (which I do have). Possibly #448 will solve it, but I'm not sure. I'm reporting this also as "compatibility app" (it has problems with obtaining location)
Full log:
04-12 17:06:03.101 6619-6619/net.darksky.darksky I/art: Starting a blocking GC Xposed
04-12 17:06:03.179 6619-6619/net.darksky.darksky D/FirebaseApp: com.google.firebase.auth.FirebaseAuth is not linked. Skipping initialization.
04-12 17:06:03.209 3501-3695/system_process W/ActivityManager: Background start not allowed: service Intent { act=com.google.firebase.INSTANCE_ID_EVENT pkg=net.darksky.darksky cmp=net.darksky.darksky/com.google.firebase.iid.FirebaseInstanceIdService (has extras) } to net.darksky.darksky/com.google.firebase.iid.FirebaseInstanceIdService from pid=6619 uid=10127 pkg=net.darksky.darksky
04-12 17:06:03.210 6619-6619/net.darksky.darksky E/FirebaseInstanceId: Error while delivering the message: ServiceIntent not found.
04-12 17:06:03.211 6619-6619/net.darksky.darksky D/FirebaseApp: com.google.firebase.crash.FirebaseCrash is not linked. Skipping initialization.
04-12 17:06:03.212 5298-5326/org.fdroid.fdroid I/InstalledAppProviderSer: Marking com.android.cts.priv.ctsshim as installed
04-12 17:06:03.223 6619-6619/net.darksky.darksky I/FA: App measurement is starting up, version: 10260
    To enable debug logging run: adb shell setprop log.tag.FA VERBOSE
04-12 17:06:03.233 6619-6619/net.darksky.darksky I/FA: To enable faster debug mode event logging run:
      adb shell setprop debug.firebase.analytics.app net.darksky.darksky
04-12 17:06:03.237 6619-6619/net.darksky.darksky I/FirebaseInitProvider: FirebaseApp initialization successful
04-12 17:06:03.271 3501-3732/system_process I/Xposed: FakeGApps: returning fake signature to net.darksky.darksky
04-12 17:06:03.273 3501-3695/system_process I/Xposed: FakeGApps: returning fake signature to net.darksky.darksky
04-12 17:06:03.277 6619-6642/net.darksky.darksky W/GooglePlayServicesUtil: Google Play services out of date.  Requires 10260000 but found 9258259
04-12 17:06:03.342 6619-6619/net.darksky.darksky I/CrashlyticsCore: Initializing Crashlytics <IP_ADDRESS>
04-12 17:06:03.364 3501-3695/system_process W/ActivityManager: Background start not allowed: service Intent { dat=boot:darksky cmp=net.darksky.darksky/.services.DarkSkyService } to net.darksky.darksky/.services.DarkSkyService from pid=6619 uid=10127 pkg=net.darksky.darksky
04-12 17:06:03.366 6619-6619/net.darksky.darksky W/FA: Service connection failed: a{statusCode=SERVICE_VERSION_UPDATE_REQUIRED, resolution=null, message=null}
04-12 17:06:03.367 6619-6642/net.darksky.darksky E/FA: Discarding data. Failed to send app launch
04-12 17:06:03.369 3501-3732/system_process I/Xposed: FakeGApps: returning fake signature to net.darksky.darksky
04-12 17:06:03.371 3501-3732/system_process I/Xposed: FakeGApps: returning fake signature to net.darksky.darksky
04-12 17:06:03.373 6619-6657/net.darksky.darksky W/GooglePlayServicesUtil: Google Play services out of date.  Requires 10260000 but found 9258259
04-12 17:06:03.374 3501-3732/system_process I/Xposed: FakeGApps: returning fake signature to net.darksky.darksky

You aren't using the latest version of microG GmsCore, you can get it here using the drop-down menu.

Ah, that fixed the problem. Thanks.


Latest PostGIS JDBC driver needs "postgis-geometry" JAR too

I was having this issue https://github.com/dbeaver/dbeaver/issues/8781 (java.lang.NoClassDefFoundError: org/postgis/Geometry) with postgis-jdbc-2.5.0.jar.
I read there was a split in its last version: https://github.com/postgis/postgis-java/releases/tag/postgis-java-aggregator-2.5.0

Decoupled geometry and encoder/decoder from postgres-jdbc

Introduced postgis-geometry module which now contain geometry classes, parser, and encoder/decoder

To fix this, postgis-geometry-2.5.0.jar must be added too with the PostgreSQL drivers in DBeaver.

Links:

https://github.com/postgis/postgis-java/releases
https://mvnrepository.com/artifact/net.postgis/postgis-jdbc
https://mvnrepository.com/artifact/net.postgis/postgis-geometry

thanks for suggestion

postgis-geometry-2.5.0.jar is added


Issue with MultiRetrievalQAChain when using returnSourceDocuments option

Hi, Im trying to implement MultiRetrievalQAChain which works as expected without the option returnSourceDocuments but as I need source documents to further generate referral links or to analyse what has been retrieved, Im unable to do so because it seems passing this option is breaking some lc function that does not have info of passed parameter returnSourceDocuments
return MultiRetrievalQAChain.fromLLMAndRetrievers(chatGPT3Model, {
			retrieverNames,
			retrieverDescriptions,
			retrievers,
			retrievalQAChainOpts: {
			        // Enabling below breaks the chain and unable to produce output
			 	returnSourceDocuments: true,
			 },
		});

Actually, I got my answer below, thanks to bot! https://github.com/hwchase17/langchainjs/blob/main/langchain/src/chains/router/tests/multi_retrieval_qa.test.ts#L132


Thank you for this repository, it really helped me a lot!!! ^^

Thank you for this repository, it really helped me a lot!!! ^^

Thank you very much! Very glad to hear that :)


Fix upstream pytorch installation from nightly builds in the compile-pytorch-ipex script

When trying to install pinned upstream Pytorch, the IPEX version is installed:
scripts/compile-pytorch-ipex.sh --upstream-pytorch --pinned

@AshburnLee could you please validate changes for the all applicable use case scenarios and report back on the results in this issue and make the code suggestions in the linked PR if anything doesn't look right to you.

Working on it

@AshburnLee could you please validate changes for the all applicable use case scenarios and report back on the results in this issue and make the code suggestions in the linked PR if anything doesn't look right to you.

Check for all applicable use case scenarios:
https://github.com/intel/intel-xpu-backend-for-triton/pull/1950#issuecomment-2311645880

After swiching to newer PTDB(0.5.2->0.5.3) and Agama(914.32->950.13), test-triton.sh works fine for upstream-pytorch both from source & from pinned (on the latest llvm-target):
./scripts/compile-pytorch-ipex.sh --upstream-pytorch # default is pinned
intel_extension_for_pytorch 2.4.0+noop
torch 2.5.0a0+gitb7baa06 # pinned upstream pytorch
./scripts/compile-pytorch-ipex.sh --upstream-pytorch --source
intel_extension_for_pytorch 2.4.0+noop
torch 2.5.0a0+gitf33bcbe # source upstream pytorch


revert incorrect logo path in README

the logo isn't displaying in the README anymore, this should fix it.

You fixed it


question for SMAC

when i train smac_5m6m_mappo_config.py,smac_5m6m_masac_config.py,and smac_5m6m_madqn_config.py.how can i get the battle win rate of these methods?i dont get the battle win rate when i train these models,and in eval period,it also only have the boolean result for battle win or battle false.

The win rate is calculated by the average result of n_evaluator_episode games' boolean results (win/lose).
For example, if n_evaluator_episode=4, the win rate could be 0.75 when games' boolean results are [1, 0, 1, 1]

eval_episode_return [0.0, 1.0, 1.0, 1.0, 0.0, 1.0, 0.0, 1.0,
0.0, 0.0, 1.0, 1.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 1.0,
1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 0.0, 1.0, 0.0,
1.0, 1.0]                           this is the part of training log,so is it mean the win rate is calculate by eval_episode_return? 17/32=0.53125

eval_episode_return [0.0, 1.0, 1.0, 1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 0.0, 1.0, 1.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 1.0, 1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 0.0, 1.0, 0.0, 1.0, 1.0] this is the part of training log,so is it mean the win rate is calculate by eval_episode_return? 17/32=0.53125

Yes, the win rate is calculated by this rule and shown as eval_episode_return


Rollout wheels support across bridged providers

Part of https://github.com/pulumi/home/issues/2883 rollout.

https://github.com/pulumi/upgrade-provider/pull/139 need this published in upgrade-provider
new release of https://github.com/pulumi/pulumi-package-publisher

to use https://github.com/pulumi/pulumi-package-publisher/pull/15

script gofmt trick to edit resources.go (see below)

either a source migration in ci-mgmt
or part of upgrade-provider?

PRs for every provider that do the following steps

steps

update Makefiles - this can be done via ci-mgmt
update to new pulumi-package-publisher
happy the gofmt trick to edit resource.go
run upgrade-provider --kind bridge

perhaps can trigger https://github.com/pulumi/pulumi-aws/blob/master/.github/workflows/upgrade-bridge.yml#L40  en masse
the upgrade-provider is needed to Pulumi up to 3.81.0 or higher as a baseline
also the upgrade-provider is needed to make sure schema and SDKs are re-generated

verify Tier 1 bridged providers by hand

[ ] aws
[ ] gcp
[ ] azure
[ ] azuread

gofmt trick
gofmt -w -r '&tfbridge.PythonInfo{x} -> (func () *tfbridge.PythonInfo { i := &tfbridge.PythonInfo{x}; i.PyProject.Enabled = true; return i })()' resources.go

Closed via #606 🎉


a few pscis xings matched to modelled xings

Scripts fail to run with this update as each of these were already in the lookup (there is a unique constraint on the PSCIS id):
50095,,706880116,,
50090,,706879645,,
50110,,706872809,,

I'll have to take a look at the crossings to see what is going on.

I've fixed - the old matching was wrong.
Either I made a mistake in what data got retained or the reviewer made an error, I'm not sure.
But there may be more in ELKR where the lookup is forcing the match to the stream instead of the modelled crossing.

I did notice some instances  where there was a “crossing” looking point on the stream and not at a road stream intersection.

In ELKR there are 42 PSCIS crossings forced to match to a particular stream rather than a modelled crossing.
Worth reviewing.
select count(*) from bcfishpass.pscis_modelledcrossings_streams_xref where watershed_group_code = 'ELKR' and modelled_crossing_id is null and linear_feature_id is not null;
 count
-------
    42

interestante

Based on reviewing the first 3 I don't trust the data at all, they should all be revisited.

@smnorris - a couple workflow questions big guy.

i think you maybe sent me a link to a doc about how we do the csv edits but I can't seem to find it... Send again if it exists?
I have a situation for a couple of crossings where a reviewer has previously reviewed a couple crossings but I have updates that tie them to modelled crossings (see screenshot).  Wondering if maybe I should track that this has been reviewed before somehow (ex. put in the notes that "previously reviewed by XXX" or add a column called 'reviewer_previous1' or something and transfer reviewer initials there....)?

Basic csv edit guide for the pscis - model - stream matching is here: https://github.com/smnorris/bcfishpass/tree/main/01_prep/02_pscis
Since we have all changes in version control and now have individual users applying them I don't think we need to worry about tracking that the crossing has been reviewed before.
@njohanley is reviewing the crossings listed in #65 - we should coordinate efforts if you're reviewing in Elk.

Thanks! I am hoping to not look at the Elk anymore but would be good to know what comes of the NJO review.


Number stored as Text

So if I create a sheet from an array:
$sheet->fromArray($rows);

and I apply a number filter:
$sheet->setColumnFormat([
                    'D' => '0',
                ]);

The numbers as still stored as 'text' in Excel - and I cannot do any calculations on them.
I know the column format is working - because I can see in Excel the column is actually formatted as a 'number' - but it says the individual cells in the D column as being stored as text.
Any ideas how to fix this?

Excuse me @TheShiftExchange can you tell me how you get row number of excell sheet ? I have some specific validation per row , so if my error is on row 2 i should return number 2 ?
Can you tell me how to do that ?
Thanks Maja


Fix: Update README.md

Running through the base tutorial I discovered p.Run() was not a function,
this fixed it

program.Run is a new function is master that hasn't been part of a stable release yet. You can either depend bubbletea@master or switch to the docs of the last release, here: https://github.com/charmbracelet/bubbletea/tree/v0.22.1


Add share buttons

So user can share the page with their contacts. And we can show off the metadata set in each page

Moved to https://github.com/davidlj95/chrislb/discussions/327


Refactor for integration with IPC

Description

move base infrastructure to inmanta.agent.executor, this package doesn't depend on the agent itself
create LocalExecutor  to contain the local code
Move tests to own file

Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[ ] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )
[ ] If this PR fixes a race condition in the test suite, also push the fix to the relevant stable branche(s) (see test-fixes for more info)

Processing this pull request

Merged into branches master in 6bb5ebdfcc6d3b7eda35532a07b32964eacc6e0c


MimeDB

It allows you to search for MIME types, and the MIME type of extensions from a JSON database, along with creating custom ones.

oh no, not a merge conflict 😭

i swear i switched branches dang it

i am going to make a new one, this is 1. out of date with the main repo, and 2. it has a merge conflict


container-hook: replace iterator by alternative mechanism

bpf iterators are only available in Linux 5.8. Replace them by an alternative mechanism to support older kernels.
This is done without comparing a pid between userspace and ebpf because we don't know if Inspektor Gadget is running in a different namespace.
Fixes https://github.com/inspektor-gadget/inspektor-gadget/issues/1782

It seems to work at first:
$ kubectl logs -n gadget gadget-zndvs
OS detected: Ubuntu 20.04.5 LTS
Kernel detected: 5.4.0-131-generic
...
time="2023-06-26T19:55:15Z" level=info msg="GadgetTracerManager: hook mode: fanotify+ebpf (auto)"

$ sudo bpftool map dump id 23
[{
        "value": {
            ".rodata": [{
                    "max_args": 20
                },{
                    "tracer_group":<PHONE_NUMBER>6343083264

But it fails later:
time="2023-06-26T19:59:43Z" level=warning msg="error watching pid: stat /host/run/containerd/io.containerd.runtime.v2.task/k8s.io/764a3031700d1403a6c51d847de88e8f05afc11cea36405c19717d7f4a8dfbf5/init.pid: no such file or directory\n"
time="2023-06-26T19:59:44Z" level=warning msg="error watching pid: stat /host/run/containerd/io.containerd.runtime.v2.task/k8s.io/759043b53054eb2c991f732fb0b5d72e54d3e0310dddd7bd65ff9f6d2ae7d055/init.pid: no such file or directory\n"

Even though those two paths exists when I try to print them from the gadget pod.

Fixed by the second commit.

Also, I suppose using UnixRights is the simple way to get what is needed: (1) identity that the process calling is the gadget tracer manager (2) get the private data from the file, right?

Correct.

Should it call runtime.LockOSThread to avoid the (remote) possibility of another goroutine using unix.Sendmsg (...UnixRights())) at the same time and messing up with the data?

It is not necessary: the kprobe/__scm_send checks the inode of the unix socket via the socket_ino constant rewritten in userspace.
If another goroutine uses unix.Sendmsg (...UnixRights())), it is not going to be on the unix socket used by ReadPrivateDataFromFd because it is not exported to other packages. And both kprobe/__scm_send and kretprobe/fget_raw are executed in a single system call (sendmsg), so the thread is not going to change in between the two kprobes. Note that tracer_pid_tgid is only used as a temporary variable; it is not going to be used in userspace or in any other ebpf module.


Leveling-tracker not showing up

i might be daft, but i have tried everything  i can think of to get this working.
Re installed everything and followed every guide to the best of my abilites.
Please help.

Oh, I didn't get that you meant the settings tab, not the feature itself. I renamed the feature from "leveling tracker" to "act-tracker" a while ago, just to emphasize it's a campaign-related feature -- the old name could potentially be interpreted as a feature that keeps track of how fast you're leveling or something.
I hope you get well soon.

oooooh! Okey that makes a lot of sense! ill keep tinkering with the settings then.
Thanks again for the quick reply and well wishes!


Start using GitFlow

As we discussed here we want to start using GitFlow.
I think we could do it at the end of this milestone.

Using GitFlow would have more advantages than only the development process. As we discussed here we might need it anyway to define access to secrets.

I have added the develop branch.

This was done.


[multistage] adding async submission

Async query planning and return from dispatch directly once parsing finishes.

this PR attempts to address the async submission issue that are currently causing planMaker execution issue blocking the GRPC thread entirely.

This one is related to https://github.com/apache/pinot/pull/10114 but i think the fundamental framework of approach is different (one uses FutureStub one uses BlockingStub with deadline). i am not sure which one is better but we need to decide on a general direction.
The goal of this PR is for discussion and it is not ready to be merge.
CC @ankitsultana @61yao @agavra

I intended to split this PR into 2 and contribute the worker pool on QueryServer first. since regardless of the approach, we should make the ctx.fork async anyway.


README.md spits out source on GitHub page

The README.md file is spitting out its source instead of nicely formatting itself as it should on the GitHub home page.

@Codom please merge UI to master to fix this then close the issue.