Image flipped when detect image

The image got detected but flipped around 90 degrees when set in image view.

I have the same issue.

Can you give me a picture of the problem?


Entries and Date of last entry on Leadboard aren't correct

For example: for this participant, all submissions on leaderboard have "Entries" 11 and the same date

I don't think it is a bug:

Entries is the number of entries made by the participant
Date of last entry is the date of the last entry of the given participant

Maybe we could replace date of last entry by simply the date of the entry for more clarity and a more informative column.

Same discussion here:

#1231

Done:

#1292


Docker swarm doesn't work with latest 0.6.0 docker-machine.

After following the tutorial at https://docs.docker.com/swarm/install-w-machine/
here's the error,
$ eval $(docker-machine env swarm)
Host does not exist: "swarm"
Referred to bug https://github.com/docker/swarm/issues/1664 when i found my docker-machine version to be 0.5.6 and upgraded it. Still didn't solve the issue with latest 0.6.0

@himan-k sounds like the swarm VM isn't running/created?
Can you open VirtualBox and check all VMs that are running? Alternatively open command line and run $ VBoxManage list vms and report the output.

nope. VMs are fine,
$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS
agent1    -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0
agent2    -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0
default   -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0
manager   -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0

$ docker-machine ls NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER    ERRORS agent1    -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0 agent2    -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0 default   -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0 manager   -        virtualbox   Running   tcp://<IP_ADDRESS>:2376           v1.10.0

@himan-k no they're not. When you type the following command
$ eval $(docker-machine env swarm)

it points the Docker client to the machine (VM) named swarm. You don't have any called swarm. If you want to point to the manager machine, then instead use
$ eval $(docker-machine env manager)

I thought that too, but then just assumed that you could talk to the 'swarm' service like that too.
Can you tell me a way to verify swarm is working fine? I am at the stage in that document where it tried to connect to the 'swarm' (manager according to you).
I ran the docker hello-world too, but it didn't run on agent1 as the document says,
$ docker ps  -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                      PORTS                    NAMES
59f3c87df15f        hello-world         "/hello"                 18 seconds ago      Exited (0) 19 seconds ago                            sleepy_hypatia

Here's a way to check swarm status,
https://docs.docker.com/v1.6/swarm/
Here are node statuses; they say 'pending'. I don't think that is right.
$ docker -H tcp://<IP_ADDRESS>:2375 info
Containers: 0
Images: 0
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
 (unknown): <IP_ADDRESS>:2375
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: Cannot connect to the docker engine endpoint
   UpdatedAt: 2016-02-08T03:15:11Z
 (unknown): <IP_ADDRESS>:2375
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: Cannot connect to the docker engine endpoint
   UpdatedAt: 2016-02-08T03:16:11Z
Kernel Version: 4.1.17-boot2docker
Operating System: linux
CPUs: 0
Total Memory: 0 B
Name: 890b4b021fe1

@himan-k "swarm service" doesn't mean anything. If you followed the https://docs.docker.com/swarm/install-w-machine/ tutorial, then you started the swarm manager inside a Docker container using (something like) the following
$ eval $(docker-machine env manager)
$ docker run -d -p 2375:2375 -t swarm manage token://0ac50ef75c9739f5bfeeaf00503d4e6e

What this did was point your Docker client (on your host (Mac or Windows)) to the Docker engine running on the manager VM, and ran a container named swarm, which is actually running the Swarm manager code. Then when you run swarm join commands for the agents, they "join" the Swarm so that the manager can discover them.
Now, the command above
$ docker -H tcp://<IP_ADDRESS>:2375 info

is querying your Swarm manager (which is running in a Docker container on the VM called manager). This is good so far, but your Swarm manager is unable to connect to the Swarm agents. I suspect it's a port number issue. Can you run the swarm join commands with port 2376 instead? See below
$ docker run -d swarm join --addr=<IP_ADDRESS>:2376 token://0ac50ef75c9739f5bfeeaf00503d4e6e

cc @moxiegirl @dongluochen I think we might have to update port numbers on this tutorial https://docs.docker.com/swarm/install-w-machine/, since docker-machine exposes engines on port 2376, not 2375. I can submit a PR to do that if you agree.

I tried that as well yesterday, but it didn't work. I will try again now...

OK. This is what happens,
$ docker run -d -p 2376:2376 -t swarm manage token://<my token>
9ffac5db1db1d401617c0c0af6961b10e8cf8aedeea54d76d30cf7262bba577f
Error response from daemon: failed to create endpoint ecstatic_snyder on network bridge: Bind for <IP_ADDRESS>:2376 failed: port is already allocated

That's not what I was talking about. Please run
$ docker run -d swarm join --addr=<IP_ADDRESS>:2376 token://<my token>

and
$ docker run -d swarm join --addr=<IP_ADDRESS>:2376 token://<my token>

on your Swarm agents respectively, then check the output of
$ docker -H tcp://<IP_ADDRESS>:2375 info

It should be able to connect to the nodes.

The other service from my previous command also seems to be running. Let me know if that is screwing it up, but otherwise, it's still not resolved.
$ docker -H tcp://<IP_ADDRESS>:2375 info
Containers: 0
Images: 0
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 4
 (unknown): <IP_ADDRESS>:2376
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: (none)
   UpdatedAt: 2016-02-08T06:14:30Z
 (unknown): <IP_ADDRESS>:2376
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: (none)
   UpdatedAt: 2016-02-08T06:14:30Z
 (unknown): <IP_ADDRESS>:2375
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: Cannot connect to the docker engine endpoint
   UpdatedAt: 2016-02-08T03:15:11Z
 (unknown): <IP_ADDRESS>:2375
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: Cannot connect to the docker engine endpoint
   UpdatedAt: 2016-02-08T03:16:11Z
Kernel Version: 4.1.17-boot2docker
Operating System: linux
CPUs: 0
Total Memory: 0 B
Name: 890b4b021fe1

I appreciate the help, btw.

It seems like your engines are still unable to connect. If you don't mind, can you please remove all your Docker machines, and redo the tutorial (clean slate), but this time taking the above things into account?
You can remove a Docker machine using
$ docker-machine rm <machine-name>

I am afraid I haven't gotten past this issue,
$ docker -H tcp://<IP_ADDRESS>:2375 info
Containers: 0
Images: 0
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
 (unknown): <IP_ADDRESS>:2376
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: (none)
   UpdatedAt: 2016-02-08T07:38:06Z
 (unknown): <IP_ADDRESS>:2376
   Status: Pending
   Containers: 0
   Reserved CPUs: 0 / 0
   Reserved Memory: 0 B / 0 B
   Labels:
   Error: (none)
   UpdatedAt: 2016-02-08T07:39:06Z
Kernel Version: 4.1.17-boot2docker
Operating System: linux
CPUs: 0
Total Memory: 0 B
Name: 2a30a8a357ea

Here's a snippet of my command history,
docker run --rm swarm create --> got the token
docker-machine ls
docker run -d -p 2375:2375 -t swarm manage token://<my token>
eval $(docker-machine env agent1)
docker-machine ls
docker run -d swarm join --addr=<IP_ADDRESS>:2376 token://<my token>
eval $(docker-machine env agent2)
docker run -d swarm join --addr=<IP_ADDRESS>:2376 token://<my token>
eval $(docker-machine env agent1)
docker -H tcp://<IP_ADDRESS>:2375 info
unset DOCKER_TLS_VERIFY
docker -H tcp://<IP_ADDRESS>:2375 info

i think i have the same problem with docker-machine 0.6.0. i have already deleted the machines once and retraced all steps. this is what i'm running:
`#!/bin/bash
docker-machine restart manager
docker-machine restart agent1
docker-machine restart agent2
SWARM_TOKEN="$(docker -H $(docker-machine url manager) run --rm swarm create)"
AGENT1_IP="$(docker-machine ip agent1)"
AGENT2_IP="$(docker-machine ip agent2)"
MASTER_IP="$(docker-machine ip manager)"
AGENT1_PORT="2376"
AGENT2_PORT="2376"
MASTER_PORT="2375"
MASTER_PORT_EXT="2375"
echo "SWARM_TOKEN is ${SWARM_TOKEN}"
echo "launching swarm manager on ${MASTER_IP}:${MASTER_PORT_EXT}"
docker -H $(docker-machine url manager) run -d -p ${MASTER_PORT_EXT}:${MASTER_PORT} -t -debug swarm manage token://${SWARM_TOKEN}
docker -H $(docker-machine url agent1) run -d swarm join --addr=${AGENT1_IP}:${AGENT1_PORT} token://${SWARM_TOKEN}
docker -H $(docker-machine url agent2) run -d swarm join --addr=${AGENT2_IP}:${AGENT2_PORT} token://${SWARM_TOKEN}
echo "printing swarm nodes by talking to master IP docker-machine"
docker -H $(docker-machine url manager) run --rm swarm list token://${SWARM_TOKEN}
#echo "printing docker info by talking to swarm manage"
docker -H $(docker-machine url manager) info
`

symptoms: i can't see the swarm machine, it's not being created

@simonmittag @himan-k thanks for the updates, I think the docs need to be fixed, there has been an issue with TLS certs in the latest release. I'll do that today, and you can try running the tutorial again. Thanks!

@simonmittag @himan-k I've fixed this doc in a new PR #1775. Please try the tutorial again once that's merged, it should work. Sorry for the previous issues!

@nishanttotla thank you. Just to clarify the above. When I retrace the steps using the 2376 port on agent1 and agent2 and then run the info command on the manager, the output is:

there are no nodes visible in the info output.
docker-machine ls on the manager machine does not show the swarm machine

are you able to get a working swarm using these instructions with docker 1.10 and machine 0.6?

@simonmittag to remove any confusion, there is no swarm machine being created, so that was something incorrect in the docs. To connect to the manager, you have to either run $ docker -H <manager-ip>:<manager-port> info or set DOCKER_HOST=<manager-ip>:<manager-port> then run docker info.
The issue with the current doc was that TLS certs weren't being updated correctly for the manager. The PR fixes that. Does all this make sense?

@nishanttotla. not totally sure yet.
<IP_ADDRESS> is my manager machine IP

this does nothing. I assume that's correct it's not exposed.

docker -H tcp://<IP_ADDRESS>:2375 info
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

this is the existing docker-machine TCP socket for manager. it comes back with info for manager but i can't see the swarm inside.

docker -H tcp://<IP_ADDRESS>:2376 info
Containers: 2
 Running: 1
 Paused: 0
 Stopped: 1
Images: 1
Server Version: 1.10.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 12
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.1.17-boot2docker
Operating System: Boot2Docker 1.10.0 (TCL 6.4.1); master : b09ed60 - Thu Feb  4 20:16:08 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 996.2 MiB
Name: manager
ID: VRLL:THEQ:53EL:5TZF:FDMH:GF7B:5Z6Z:VSCI:R2J6:ACTS:F7KI:HWUM
Debug mode (server): true
 File Descriptors: 17
 Goroutines: 29
 System Time: 2016-02-09T01:30:45.204591964Z
 EventsListeners: 0
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Username: ***
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

This is the external port that was mapped by the manager app. It gives me a TLS related error.

docker -H tcp://<IP_ADDRESS>:5001 info
An error occurred trying to connect: Get https://<IP_ADDRESS>:5001/v1.22/info: tls: oversized record received with length 20527

which one of these do I want?

@simonmittag Can you wait for the new tutorial updates to be merged? That should fix all of these issues you're having.
To answer your questions above, (1) does nothing because port 2375 isn't exposed. (2) will only show info for the Docker engine on the manager machine, since 2376 is the port exposed by the Docker engine. Finally, assuming 5001 is your Swarm manager port, (3) is what you want to do. But you're getting TLS related errors, which you'll have to fix by mounting certs, as the updated doc will describe.

yes that clarifies,thank you @nishanttotla :)

@simonmittag @himan-k try out the updated doc here: https://github.com/docker/swarm/blob/master/docs/install-w-machine.md

@nishanttotla Here's what I get,
$ docker info
An error occurred trying to connect: Get https://<IP_ADDRESS>:3376/v1.21/info: dial tcp <IP_ADDRESS>:3376: ConnectEx tcp: No connection could be made because the target machine actively refused it.

eval $(docker-machine env manager)

docker run -d -p 5001:3376 -t -v /var/lib/boot2docker:/certs:ro swarm manage -H <IP_ADDRESS>:3376 --tlsverify --tlscacert=/certs/ca.pem --tlscert=/certs/server.pem --tlskey=/certs/server-key.pm token://7ba953a311e8e1ae38f9af634be67158
ba41c126f9abf41bee36a4aa8a1c70439ae90bd376d60d1a3230cf29b684d15d

docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

i can't get that image up and running, it shuts down immediately

docker run -i -p 3376:3376 -t -v /var/lib/boot2docker:/certs:ro swarm manage -H <IP_ADDRESS>:3376 --tlsverify --tlscacert=/certs/ca.pem --tlscert=/certs/server.pem --tlskey=/certs/server-key.pm token://07b4f2c13d79c18b4f5c807484259d25

FATA[0000] Couldn't load X509 key pair (/certs/server.pem, /certs/server-key.pm): open /certs/server-key.pm: no such file or directory. Key encrypted?

@simonmittag I think I made a typo in the PR. It should be --tlskey=/certs/server-key.pem. Sorry about that, I'll fix it.

@himan-k can you delete all machines and try afresh? The issue you're having seems unlikely to be a swarm/machine issue to me.

@himan-k I'm also running into this problem myself.
With my installation (made using Docker Toolbox), I don't have any certificates under /certs. I can find some certificates under /Users/<user>/.docker/machine/machines/<machine-name>.
So probably the issue is related to that.

@joaofnfernandes the /certs folder is being mounted into the container. The actual certs are in your VM, under the /var/lib/boot2docker folder. If you want to confirm, try ssh into the VM using docker-machine ssh manager and navigate to that folder.

@joaofnfernandes the /var/lib/boot2docker folder is in the docker-machine as per above.
@nishanttotla after fixing the typo (should've spotted that myself) it works fine and now using the swarm with the new instructions. Thanks again for fixing this.
(The most confusing part in the old instructions was the commands that incorrectly suggested that swarm should appear as a docker-machine that can be selected with docker-machine env)

@simonmittag great, glad to know it finally worked! The older docs worked fine, but we wanted to get rid of some docker-machine magic and make things more explicit. Hope everything is clear now!


FT/PT Application question for parent marital status

As an applicant
I want to provide my parent(s) marital status So That the correct parent information is requested*
Additional Context

This can replace the current question "How many parents do you live with?"

Acceptance Criteria

[ ] When parent information is required, the following application question is included:
**My parent(s) marital status is:

Single

Married/Remarried

Common-Law

Seperated/Divorced/Widowed**

[ ] Given (Single OR Seperated/Divorced/Widowed), When (application is submitted), Then (1 Parent Information Request is generated)

[ ] Given (Married/Remarried OR Common-Law), When (application is submitted), Then (2 Parent Information Request are generated)

duplicate, see #758


pageserver: fixes for creation operations overlapping with shutdown/startup

Problem
For #6423, creating a reproducer turned out to be very easy, as an extension to test_ondemand_activation.
However, before I had diagnosed the issue, I was starting with a more brute force approach of running creation API calls in the background while restarting a pageserver, and that shows up a bunch of other interesting issues.
In this PR:

Add the reproducer for #6423 by extending test_ondemand_activation (confirmed that this test fails if I revert the fix from https://github.com/neondatabase/neon/pull/6430)
In timeline creation, return 503 responses when we get an error and the tenant's cancellation token is set: this covers the cases where we get an anyhow::Error from something during timeline creation as a result of shutdown.
While waiting for tenants to become active during creation, don't .map_err() the result to a 500: instead let the From impl map the result to something appropriate (this includes mapping shutdown to 503)
During tenant creation, we were calling Tenant::load_local because no Preload object is provided.  This is usually harmless because the tenant dir is empty, but if there are some half-created timelines in there, bad things can happen.  Propagate the SpawnMode into Tenant::attach, so that it can properly skip any attempt to load timelines if creating.
When we call upsert_location, there's a SpawnMode that tells us whether to load from remote storage or not.  But if the operation is a retry and we already have the tenant, it is not correct to skip loading from remote storage: there might be a timeline there.  This isn't strictly a correctness issue as long as the caller behaves correctly (does not assume that any timelines are persistent until the creation is acked), but it's a more defensive position.
If we shut down while the task in Tenant::attach is running, it can end up spawning rogue tasks.  Fix this by holding a GateGuard through here, and in upsert_location shutting down a tenant after calling tenant_spawn if we can't insert it into tenants_map.  This fixes the expected behavior that after shutdown_all_tenants returns, no tenant tasks are running.
Add test_create_churn_during_restart, which runs tenant & timeline creations across pageserver restarts.
Update a couple of tests that covered cancellation, to reflect the cleaner errors we now return.

Summary of changes
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

Latest failure of test_tenant_delete_races_timeline_creation was due to https://github.com/neondatabase/neon/pull/6387.  Should re-run-this after that merges.

tests: update location_conf_churn: instead of doing last_state_ps[1] + 1 , we should insead get the generation number from tenant status (I added that to the API output recently). No guarantee that generation numbers are sequential.

That was my first instinct, but it's awkward: during tenant shutdown, flush_and_shutdown gets called before Timeline::shutdown is called, so the timeline doesn't really know it is shutting down  :-/

reject generations that go backward.
It bothers me that we had to implement this check in two places.
Not this PR's fault, it's just exposing a flaw.

Yep.  If we ultimately wanted to get this down to one location, it would require changing startup process to wait to be /location_conf'd (plausible change, in the mid-term).

test_create_churn_during_restart ; how about making this time-based instead of for _ in range(0, 10). I.e., do iterations until 30s have passed.

I'm kind of ambivalent.  Generally prefer a fixed number of iterations to something time based, so that we're not e.g. doing fewer iterations in debug mode.

avoid leaking Tenant : proposal for additional refactor: if slot_guard.upsert(new_slot) fails, it should return the new_slot that was passed in. Avoids the tenant cloning in the lines above.

The cloning was already there (it's used to return the Tenant from the function).
Originally I wanted to keep the error simpler, but later I added the distinct ShuttingDown case to carry the Completion: so yeah, it makes sense to carry the slot here too.

carry a GateGuard
// The attach task will carry a GateGuard, so that shutdown() reliably waits for it to drop out if
// we shut down while attaching.
let Ok(attach_gate_guard) = tenant.gate.enter() else {
how can we ever hit else, we just created that tenant object, it's not reachable from anywhere.

That's true -- I was just handling error out of habit.  Replaced this with unreachable!();

tests: update location_conf_churn: instead of doing last_state_ps[1] + 1 , we should insead get the generation number from tenant status (I added that to the API output recently). No guarantee that generation numbers are sequential.

Hmm, the only way the generation numbers jump by more than one in this context is if something goes wrong in /re-attach and the pageserver calls it again.
I've updated this to still just add 1, but also assert that the generation matches from the pageserver API: I don't want to just silently tolerate anything weird that's jumping the generation by more than one, but it's right that we also shouldn't assume the test code gets this right.

log freeze and flush errors at info!: strongly opposed to how it's done here. we should only log at info! level if it's during shutdown. Should have is_cancelled() / is_shutdown() method on the error type. If it's an anyhow::Error, I say we punt on this change for now and refactor freeze_and_flush first so it returns an error type that lets us differentiate cancellation from other error causes.
Also, consider using report_compact_sources , see recent discussion https://neondb.slack.com/archives/C033RQ5SPDH/p1706105202934999

I'm replacing this with a tolerance of the log in the test.

avoid giving 404 for tenants during shutdown: the comment that you added in tenant_map_peek_slot doesn't mention this is so that we don't return 404. Maybe it should?

Added a sentence.

allow list for #6385 : you put a TODO there, but, https://github.com/neondatabase/neon/issues/6385 is closed.

This is gone now

test: update .*: are these fixup commits to one of your earlier commits? If so, please git revise it.

Not sure which exact commits drove these without going back and re-testing each commit.

Last failures were "still waiting, taking longer than expected..." logs, which makes sense.  Since https://github.com/neondatabase/neon/pull/6451, we will sometimes wait longer for an initdb to finish (and that is what's happening in the logs from these failures).  Added a line to the test to tolerate that.

Yeah in #6451 I had to add allows for still waiting as well.


tagDatabase tag allows for duplicate tag values

Environment
Liquibase Version: 4.19.0
Liquibase Integration & Version: Gradle
Liquibase Extension(s) & Version: N/A
Database Vendor & Version: PostgreSQL 12
Operating System Type & Version: Mac OSX 13.1
Infrastructure Type/Provider: N/A
Description
The <tagDatabase> tag allows the same tag value to be created with different authors. We use <tagDatabase> at the start of a release. If two developers are concurrently making schema changes it's easy enough for both to inadvertently include their <tagDatabase> tags at commit/merge, resulting in multiple tags of the same version in databasechangelog. This muddies the waters around rollback via tag.
Steps To Reproduce
Example XML:
    <changeSet id="TAG-12.0" author="dev1">
        <tagDatabase tag="release/12.0"/>
    </changeSet>
    <changeSet id="TAG-12.0" author="dev2">
        <tagDatabase tag="release/12.0"/>
    </changeSet>

Actual Behavior
In this simple example LB creates the tag twice.
Running Changeset: db.changelog-v12.0.xml::TAG-12.0::dev1
[2023-02-01 11:12:35] INFO [liquibase.changelog] Tag 'release/12.0' applied to database
[2023-02-01 11:12:35] INFO [liquibase.changelog] ChangeSet db.changelog-v12.0.xml::TAG-12.0::dev1 ran successfully in 1ms
Running Changeset: db.changelog-v12.0.xml::TAG-12.0::dev2
[2023-02-01 11:12:35] INFO [liquibase.changelog] Tag 'release/12.0' applied to database
[2023-02-01 11:12:35] INFO [liquibase.changelog] ChangeSet db.changelog-v12.0.xml::TAG-12.0::dev2 ran successfully in 0ms
[2023-02-01 11:12:35] INFO [liquibase.lockservice] Successfully released change log lock
Liquibase command 'update' was executed successfully.
In a more complicated example, dev3 might have tagged the database, made other changes and then dev4 might have inadvertently added their own same tag and made their changes.
Expected/Desired Behavior
My feeling is that one shouldn't be able to tag the database with the same value, or minimally there should be some warning. I'm not sure what the value in allowing the current behavior would be.
Screenshots (if appropriate)
Example of a more complex scenario this could impact.

Additional Context
Thanks for your consideration.

@rdhzl We faced same issue, how it behaves with rollback?

This is a combination of a bug and feature request. If someone wanted to make a PR for one part or another, that would be great.
We probably can't actually add a unique constraint to the table due to trying to keep that table structure as simple and cross-database as possible, but if someone wanted to add a constraint to the table themselves there should be no times it fails.
Feature Request:
The ability to have re-use a tag is intentional, but a nice feature would be to have the ability to control that default behavior.
The functionality we are supporting with the ability to reuse a tag is something like:

Before every deployment, automation runs "liquibase tag --tag=last-release"
Runs liquibase update
If a failiure happens, can run "liquibase rollback --tag=last-release"
If a failure doesn't happen, they can still easily report on what's new since the last release

without having to come up with new tag names each time.
Bug 1
Implementation-wise, it's maybe just adding a new tag without clearing out the old ones, but that's accidental/bug if it's doing that. We don't intend to allow you to keep being able to roll back to previous versions of the tag, so it shouldn't need to be keeping the duplicate values. Updating the TagDatabaseGenerator to clear out old copies of the tag before setting a new tag would be a good thing to do.
Bug 2
The default TagDatabaseGenerator SQL just uses max(date_executed) to update the tag and changesets can run fast enough to have multiple changesets with the same date_executed. We have custom SQL for many common databases which use both date_executed and order_executed correctly, but the SQL for those get database-specific and there isn't a standard-sql version we've come up with so far. This doesn't cause a functional problem because on rollback, liquibase can pick the correct "last" one taking order_executed into account. But unless we can solve this, we can't truely assume there will be no duplicate records.


server: proxy: implement NLA fallback

This PR contains a feature we called "NLA Fallback", which means that if the proxy's client fails to connect with NLA, it then tries to connect without NLA (using only TlsSecurity). We need this because there's a domain policy that disables NTLM then there are some computers that the proxy can't connect to them (because it tries NLA and fails).

@freerdp-bot test

@akallabath can you please test again? :)

@freerdp-bot test

@akallabeth lets merge  :)


google auth invalid credentials

displaying error while logging in

The authentication requires Firebase project to be configured, as we are in pilot testing, how about we bypass login and navigate to HomeScreen directly?

Yes, we can do that for now.

looks good to me.

Fine, let's do that

This pull request closes the issue.


Add Abraham Agiri (@codeekage) as a CC observer and Member

Please add me to the community as an evangelist.

PR: https://github.com/mhdawson/create-node-meeting-artifacts/pull/10

PR landed, closing!


Feature: Deploy Python agnostic Sqlite extension

Describe what you are looking for
I need to use Sqlite extension but without dependency on python.
See discord communication: https://discord.com/channels/1063947616615923875/1212802427883880478/1212804112966619166
Can you contribute to the implementation?

[ ] I can contribute

Is your feature request specific to a certain interface?
Other
Contact Details
<EMAIL_ADDRESS>Is there an existing issue for this?

[X] I have searched the existing issues

Code of Conduct

[X] I agree to follow this project's Code of Conduct

:tada: This issue has been resolved in version 2.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Feature request + update

Any chance to update to 1.9.2?
Feature request:
Saving items in a file and giving them with /commander give "id" "playerName" "quantity"
Example file:
{
  "id": "test",
  "item": "minecraft:stone",
  "commands": /give @p minecraft:stone, /give @p minecraft:cobblestone, /give @p minecraft:diamond,
  "customName": {
    "text": "test",
    "color": "green"
  },
  "lore": [
    {
      "text": "line 1"
    },
    {
      "text": "line 2"
    }
  ]
}

It was done as a private commission, forgot to update the mod with it.
Done in e6500b923cbe83e3421feff1172b41cab2345e48.


Announce Keynote Speaker -  Mars Lee

Announcing Mars Lee as the final Keynote.
Tasks

[ ] Social Media Poster @iamaravindsekar
[ ] Social Media announcement @WatchfulHitman
[ ] Blog post announcement @Sc0rpi0n101
[ ] Mailing list announcement  @WatchfulHitman
[ ] Website update to display the keynote speaker. @bhansa

Timeline
Pre 4PM

[ ] Push a low resolution image to server to refer in website and blog @bhansa
[ ] Merge the blog post @Sc0rpi0n101
[ ] Draft the social media announcement @WatchfulHitman
[ ] Merge the website changes @bhansa

Post 5PM

[ ] Deploy the blog and the website @bhansa
[ ] Send the social media announcements out @WatchfulHitman
[ ] Announce on mailing list @WatchfulHitman

Communication Channel

[ ] Mailing List
[ ] Social Media

Mars Lee is a Technical Illustrator that makes byte-sized comics that explain technical topics! She uses art, an under-represented skill set in open source, to get people excited about contributing. Her most recent works are the ‘How to Contribute to NumPy’ comics and ‘How to Write Alt Text for Scientific Diagrams and Documentation’ comic.
Outside of conferences, you can find her making zines and rollerskating across NYC. You can connect with her on Twitter/X and LinkedIn.

Shall I have the Bio as Technical Instructor ?

Shall I have the Bio as Technical Instructor ?

Mailing list

Finally, the cherry on the top of the cake, our final keynote speaker - Mars Lee!
If you've ever been into comic books in your life, then this is only going to double your excitement. And if you haven't been into them, well this is probably your calling.
Mars Lee is a Technical Illustrator who makes byte-sized comics that explain technical topics! She uses art, an under-represented skill set in open source, to get people excited about contributing. Her most recent works are the "How to Contribute to NumPy" [0] and "How to Write Alt Text for Scientific Diagrams and Documentation" [1] comics.
Outside of conferences, you can find her making zines and rollerskating across NYC. Get to know more about her on both Twitter/X [2] and LinkedIn [3].
A uniquely talented individual, we are happy to have her at this year's conference to share her experiences with you and for you folks to learn from.
[0] https://heyzine.com/flip-book/3e66a13901.html
[1] https://heyzine.com/flip-book/f3c7f85cdc.html
[2] https://x.com/marsbarlee
[3] https://www.linkedin.com/in/mars-lee/
Twitter
Finally, the final keynote speaker announcement that all of you (and us) were waiting for - Mars Lee! She is a Technical Illustrator and a passionate programmer.  Get to know more about her at our blog: <blog_lin>
See you folks at the conf!
Other SM
Wrapping up our keynote announcements, we have our final keynote announcement to make - Mars Lee!
She'll be at PyCon India 2024 showcasing her illustrative genius in the world of technology where she makes it more creative and even more fun. For those among you having had comic books close to your hearts, you really don't want to miss this opportunity. And if this is your first time reading comics, her skill will make sure you fall in love with it.
Get to know more about her at our blog: <blog_link>
See y'all at PyCon India!


Local development workflow unexplained/error

For a contributor to this Github project, it's unclear how exactly to test code locally.
I also believe there's a bug somewhere that could be quite confusing to folks.
Problem:
Contributors need to pull this code down, test locally, and then submit a PR for features. Some functionality works when installing through the package (like by npx … commands) but do not work locally when running node index.js mydirectory.
I am seeing this error:
Uncaught (in promise) Error: Querying call/dev-1582068317359/welcome failed: wasm execution failed with error: FunctionCallError(HostError(GuestPanic("Value with Key: account_id is not a string or null, filename: \"nearFile\" line: 345 col: 2"))).
{
  "block_height": 571940,
  "error": "wasm execution failed with error: FunctionCallError(HostError(GuestPanic(\"Value with Key: account_id is not a string or null, filename: \\\"nearFile\\\" line: 345 col: 2\")))",
  "logs": []
}
    at JsonRpcProvider.query (json-rpc-provider.js:36)
    at async Account.viewFunction (account.js:160)

when I try to run locally.
However, I am able to test code locally after doing an npm pack command. This is very strange and should certainly be documented or fixed.
Steps to reproduce problem:
git clone git@github.com:nearprotocol/create-near-app.git
cd create-near-app
npm i
node index.js myaccountid
cd myaccountid
npm i
near login
npm run start
Try logging in, you'll see the error above.
Steps to reproduce odd workflow that works:
git clone git@github.com:nearprotocol/create-near-app.git
cd create-near-app
npm pack
look for tarball, put that somewhere else, extract it…
npm i
node index.js myaccountid
cd myaccountid
npm i
near login
npm run start
Try logging in, and it works.

The development workflow has been greatly improved with the merge of #386 (and addendum 9f29c9cdbe73442af0c05550da08812323647d74)


Typo

Updated https://go.deta.dev/deploy?repo=your-repo-url to https://go.deta.dev/deploy. Because I got error while I pasting previous one and  after changing to go.deta.dev/deploy it worked!. (ps: I changed repo query to my repo's url. But it didn't work)

hi @divrk thanks for the PR!
https://go.deta.dev/deploy?repo=your-repo-url is working, an example: https://go.deta.dev/deploy?repo=https://github.com/deta/deploy-to-deta-button-example
your-repo-url is only a placeholder for your public git repository url, can you please provide the url for which it didn't work?

It worked. I misspelled value on deta.json😅😬

It worked. I misspelled value on deta.json😅😬

ah ok, sorry yeah we should document the behavior in case the deta.json file or the repository is bad
closing this PR though, thanks for the input.


Upload problems - inexplicable naming conflict

Hi,
Describe the bug
I'm trying to upload a package to PyPI through GitHub Actions using Poetry and the PyPI API token. I tried it with two names, PyWLK and wlkipy. In both cases, I got the same issue: HTTP Error 400: The name '...' is too similar to an existing project.
Expected behavior
I'd expect the upload to be no problem or at least to know which other package caused the problem.
To Reproduce
As it's GitHub Actions, you can inspect everything here.
My Platform
Standard GitHub Actions environment where I create a mamba environment, install poetry, build and upload it.
Additional context
The pipeline for uploading seems a bit complex, but for conda uploads, it works. I'd like to use poetry for uploading and an automated way to upload the package to reduce the workload.
Thank you for any help, Roman

In the meantime, I tried to upload the package from my commandline, but I'm unable as poetry keeps telling me, my credentials are invalid:
HTTP Error 403: Invalid or non-existent authentication information. See https://pypi.org/help/#invalid-auth for more information. | b'\n \n  <title>403 Invalid or non-existent authentication information. See https://pypi.org/help/#invalid-auth for more information.\n \n \n
403 Invalid or non-existent authentication information. See https://pypi.org/help/#invalid-auth for more information.\n  Access was denied to this resource.

\nInvalid or non-existent authentication information. See https://pypi.org/help/#invalid-auth for more information.\n\n\n \n'
Does someone has an idea how to fix this?

Now, I also tried it following the official PyPI guidelines: https://packaging.python.org/en/latest/tutorials/packaging-projects/
Doesn't change, I'm not allowed to upload a package.


💡 Create Privacy Policy & Support URL & Terms Of Service

🥴 What do you want to do?

I want to create privacy policy, support URL and terms of service
I want to add them to my app

🐌 Purpose

for getting acceptance from App Store

🎩 Images
Nothing

🌋 TODOs

[x] create privacy policy
[x] create support form (google form)
[x] create terms of service
[x] add them to my app (at user modal and sign up page)

LG   TM


virtcontainers: add a kata specific appendix to host cgroups path

append a kata specific string to oci cgroup path to form a different cgroup path, thus cAdvisor couldn't find kata containers cgroup path on host to prevent it from grabbing the stats data.
Fixes:#1488
Signed-off-by: lifupan<EMAIL_ADDRESS>

/test

/test

/test

/test

@egernst  If we accept the fix, we should change the test cases for cgroup test.

I think this is the best option right now for fixing.   Let's get the tests updated!
Thanks @lifupan

/cc @devimc @mcastelino @krsna1729

@mocolic  does this change works for you?  (I don't think so) :thinking:

@devimc - can you clarify their assumptions on cgroups? How do they use our cgroups?

@devimc
If this change doesn't honor the cgroup name we passed to kata, it will break the behavior, so won't work for us. Our resource governance implementation relies on honoring cgroup, as resource limits are set on cgroup level and expectation is that kata creates and activates a container inside this cgroup.
However, recent tests have shown another problem with this check-in - https://github.com/kata-containers/runtime/pull/1189
Please let me know if I should open a new issue for this and we can continue there.
I believe the problem is this code snippet in virtcontainers/cgroups.go - as this will govern containers even though they do not have constraints - which is not expected.
    // use a default constraint for sandboxes without cpu constraints
if period == uint64(0) && quota == int64(0) {
	// set a quota and period equal to the default number of vcpus
	quota = int64(s.config.HypervisorConfig.NumVCPUs) * 100000
	period = 100000
}

In our clusters default number of vcpus is -1 (entire machine) and as parent cgroup can’t have stricter limits than in child cgroup, container activation fails with this error:
"Could not update cgroup /fabric/SingleInstance_0_App1:myCpuServicePkg@3016e3dc-60b9-8746-a897-4f1bb73dd80a@0c665905-47af-8147-b616-8a0c099ca7a5/crio-5e4f661e9035b89d190a34bcec617a75ac0006b47b784dab207f02bda98736d1: write /sys/fs/cgroup/cpu/fabric/SingleInstance_0_App1:myCpuServicePkg<EMAIL_ADDRESS>invalid argument"
Without the code snippet above, our resource governance would have worked out of the box.

@mocolic

If this change doesn't honor the cgroup name we passed to kata, it will break the behavior, so won't work for us. Our resource governance implementation relies on honoring cgroup, as resource limits are set on cgroup level and expectation is that kata creates and activates a container inside this cgroup.

yes, with this change the cgroup path won't be honoured (again)

However, recent tests have shown another problem with this check-in - #1189
Please let me know if I should open a new issue for this and we can continue there.

good finding, please file an issue

@devimc

However, recent tests have shown another problem with this check-in - #1189
Please let me know if I should open a new issue for this and we can continue there.

good finding, please file an issue

Thanks, opened https://github.com/kata-containers/runtime/issues/1521

This forces a pretty tight coupling. As a data point; in Kubernetes, the node level part of the orchestrator/manager (kubelet) will create a cgroups under which it will place containers (in this specific instance, a pod cgroup). Kubelet is able to then go ahead and modify and restrict/enforce by modifying the cgroup that it created.
In the other scenario (@mocolic), the upper layer relies on Kata creating container  cgroups which the upper layer can then go and modify. This makes a bit of a tight coupling, as can be seen in this scenario.
I’m not sure what the right solution is yet, but the coupling isn’t ideal.

In the other scenario (@mocolic), the upper layer relies on Kata creating container cgroups which the upper layer can then go and modify. This makes a bit of a tight coupling, as can be seen in this scenario.

So, we create our cgroup and change limits on that level, we do not modify kata child cgroups. The only what we rely on is that container will be created in this cgroup. Also, all other container runtimes(docker/clear containers) work in this way.
On the other hand, with this solution, there is no way to create a container that is ungoverned, right? It is implicitly governed on the whole machine, even if the customer don't want that.

can you provide a complete hierarchy example @mocolic?
It sounds like the name of the cgroup we create doesn't matter, so long as we place it in the correct place in the hierarchy, correct?

can you provide a complete hierarchy example @mocolic?
It sounds like the name of the cgroup we create doesn't matter, so long as we place it in the correct place in the hierarchy, correct?

Correct.
If we pass cgroup name to kata, for example fabric, the hierarchy should look like:
└── fabric
├── crio-89e60b84 # Sandbox cgroupsPath=/fabric/crio-89e60b84
├── crio-2a95e0f8 # Container A cgroupsPath=/fabric/crio-2a95e0f8
└── crio-d037bce7 # Container B cgroupsPath=/fabric/crio-d037bce7
The hierarchy if parent cgroup is not provided, I expect something like this:
/sys/fs/cgroup/cpu,cpuacct
├── crio-89e60b84 # Sandbox cgroupsPath=/crio-89e60b84
├── crio-2a95e0f8 # Container A cgroupsPath=/crio-2a95e0f8
└── crio-d037bce7 # Container B cgroupsPath=/crio-d037bce7
One of the examples for the problem:
We set limits on fabric cgroup (for example 1.3 cores which translates to cpu.cfs_quota_us = 130000). Let's say that machine has 2 cores (and as in our configuration default_vcpus=-1), the code snippet above will try to set limits of cpu.cfs_quota_us = 200000 on child cgroup fabric/crio-d037bce7. Linux doesn't allow this, so container activation fails.

@mocolic

One of the examples for the problem:
We set limits on fabric cgroup (for example 1.3 cores which translates to cpu.cfs_quota_us = 130000). Let's say that machine has 2 cores (and as in our configuration default_vcpus=-1), the code snippet above will try to set limits of cpu.cfs_quota_us = 200000 on child cgroup fabric/crio-d037bce7. Linux doesn't allow this, so container activation fails.

then the constraint for the container should be -1 (no constraint) right?

@mocolic

One of the examples for the problem:
We set limits on fabric cgroup (for example 1.3 cores which translates to cpu.cfs_quota_us = 130000). Let's say that machine has 2 cores (and as in our configuration default_vcpus=-1), the code snippet above will try to set limits of cpu.cfs_quota_us = 200000 on child cgroup fabric/crio-d037bce7. Linux doesn't allow this, so container activation fails.

then the constraint for the container should be -1 (no constraint) right?

When I checked the configuration.toml file, it says this:
#< 0                             --> will be set to the actual number of physical cores
If I understood correctly, this means that you would internally change this to the entire core machine (to 2), right? Also, when I created a container that requires whole machine (2 cores are set on fabric cgroup), the container activation was successful.

@mocolic

If I understood correctly, this means that you would internally change this to the entire core machine (to 2), right?

yes, currently it's now working because we try to set a constraint equal to the number of physical resources (in this case 2), but that won't be possible if the parent cgroup is smaller (for example 1.3), so we shouldn't apply a constraint

@mocolic as Kata really does not (and cannot really) impose container level cgroups unless CPU Sets are used can you expand a little bit on what your container level cgroups is expected to have. We will place the kata-shim in this cgroup, but the actual workloads will be in what we will designate as the pod cgroup. So any stats or constraints you apply on the container cgroup will apply to the shim and not the actual workload. Do you place anything else in the container cgroup?
└── fabric
├── crio-89e60b84 # Sandbox cgroupsPath=/sys/fs/cgroup/cpu,cpuacct/fabric/crio-89e60b84
├── crio-2a95e0f8 # Container A cgroupsPath=/sys/fs/cgroup/cpu,cpuacct/fabric/crio-2a95e0f8
└── crio-d037bce7 # Container B cgroupsPath=/sys/fs/cgroup/cpu,cpuacct/fabric/crio-d037bce7

@fupan approach looks good. Preprend would be better than append imo. Let’s fry the tests fixed.

@fupan approach looks good. Preprend would be better than append imo. Let’s fry the tests fixed.

Got it, I'll change it to prepend and then change the testcases

The changes for tests is here: https://github.com/kata-containers/tests/pull/1462
Let merge it first then trigger the tests for  this PR.

/test

@chavafg can we have a test case for this using something along the lines of a pod such as
apiVersion: v1
kind: Pod
metadata:
  name: test-metrics
spec:
  runtimeClassName: kata
  containers:
  - name: cont-2cpu-400m
    image: busybox
    resources:
      limits:
        cpu: 2
        memory: "400Mi"
    command: ["md5sum"]
    args: ["/dev/urandom"]
  - name: cont-3cpu-200m
    image: busybox
    resources:
      limits:
        cpu: 3
        memory: "200Mi"
    command: ["md5sum"]
    args: ["/dev/urandom"]

And then check the actual results viakubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/default/pods/test-metrics"
which should yeild pretty high CPU utilization
along the lines of
  "containers": [
    {
      "name": "cont-3cpu-200m",
      "usage": {
        "cpu": "398739040n",
        "memory": "744Ki"
      }
    },
    {
      "name": "cont-2cpu-400m",
      "usage": {
        "cpu": "200848120n",
        "memory": "852Ki"
      }
    }


Add options to contents function

Please modify docs and see if you can add a test?

I'm not sure what docs do you mean.

I updated the docs and added a test but not quite sure if it is good enough


Conflicting line length rule with scalafmt

So far this plugin works really nice :slightly_smiling_face: . I only encountered the following issue. I have an import statement as follows:
import sttp.client.{
  DeserializationError,
  HttpError,
  NothingT,
  Response,
  ResponseAs,
  ResponseError,
  SttpBackend,
  basicRequest
}

scalafix-organize-imports tries to rewrite it to
import sttp.client.{DeserializationError, HttpError, NothingT, Response, ResponseAs, ResponseError, SttpBackend, basicRequest}

while scalafmt insists on the original formatting. My .scalafmt.conf:
version = "2.4.1"

align = more
maxColumn = 100
rewrite {
  rules = [
    SortModifiers,
    RedundantBraces,
    PreferCurlyFors
  ]

  redundantBraces.stringInterpolation = true
}

and .scalafix.conf:
rules = [
  NoAutoTupling,
  DisableSyntax,
  LeakingImplicitClassVal,
  NoValInForComprehension,
  ProcedureSyntax,
  OrganizeImports
]

OrganizeImports {
  groupedImports = Merge
}

Hey @arjun-1, thanks for trying it out and reporting!
This is a known limitation of the OrganizeImports rule. For rules making surgical changes, e.g., the Scalafix built-in NoAutoTupling and ProcedureSyntax rules, it's relatively easy to respect the original formatting convention. However, OrganizeImports shuffles a lot more text, and it's harder to meet that requirement.

Another patch for inserting the organized imports as a big trunk of string to the original location.
This patch is generated by pretty-printing transformed AST nodes, so it's pretty hard to keep the original format.

One straightforward workflow to avoid this issue is to run Scalafix with OrganizeImports first and then run Scalafmt to reformat your code base. The former performs semantic rewriting while the latter performs syntactic rewriting. Let's just have the right tool to do the right job!

Thanks for the clarification. We enforce linting in our CI pipelines (using both scalafix --check and scalafmtCheckAll). I guess the best way to go about this would be to to exclude OrganizeImports from the scalafix rules list, while maybe adding ;scalafix OrganizeImports; test:scalafix OrganizeImports; to the linting command alias

@arjun-1, although right now it seems to be obvious, I didn't realize that you were talking about linting, which is a legitimate use case OrganizeImports should support well.
In the scope of linting, it is much easier to implement, since what we need to do is simply leaving an import untouched if it's already organized.

PR #44 should fix this issue.

Hi @liancheng , thanks for the quick reply  :slightly_smiling_face: . I tried your fix with the snapshot version, but strangely enough it did not make a difference with 0.3.0. (Given that it seems to work for the given input/output of https://github.com/liancheng/scalafix-organize-imports/pull/44 , I really wonder whether something went wrong on my side of the configuration :thinking: ).
In any case I made a minimal example which reproduces the issue:
https://github.com/arjun-1/failing-scalafix-organize-imports-lint
Just run scalafmtAll and scalafix, and the imports will be rewritten to a single line.

@arjun-1, thank you so much for the minimal reproduction! I figured out why it didn't work for you. It's because you are using Scala 2.13 while OrganizeImports is built using Scala 2.12.
OrganizeImports calls importer.syntax to pretty-print an import expression. Internally, the syntax method accepts an implicit scala.meta.Dialect parameter. While pretty-printing, the syntax method checks two things:

Whether this AST node originates directly from the parser.
Whether the Scala dialect of the original source being parsed comforms to the implicit dialect.

When both conditions are true, it simply returns the original source text being parsed. Otherwise, it pretty-prints the AST node using the implicit dialect.
OrganizeImports is built using Scala 2.12, so at runtime, this implicit dialect is by default Scala 2.12. Therefore, condition 2 doesn't hold.
Instead, we can simply replace the importer.syntax with importer.toString. The latter doesn't check condition 2. Instead, it always uses Scala 2.11 dialect, which is good enough for pretty-printing import statements.

@arjun-1, let's see whether the snapshot release 0.3.0+5-98c374f1-SNAPSHOT fixes your issue.

Excellent! Indeed the issue is resolved with 0.3.0+5-98c374f1-SNAPSHOT :smiley:


fix: Amend syntax in conda-meta/history to prevent conda.history.History.parse() error

https://github.com/prefix-dev/pixi/pull/995 introduced a Pixi-generated conda-meta/history. Sadly, # is a special character in the history file, which ends up breaking the conda.history.History.parse() function:
$ python -c "from conda.history import History as H; print(H('.pixi/envs/default').parse())"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/jrodriguez/devel/conda-pip/.pixi/envs/default/lib/python3.10/site-packages/conda/history.py", line 138, in parse
    res[-1][2].append(line)
IndexError: list index out of range

// does work without issues.

Thanks!


Problems when Install cumulus dependencies

Cannot uninstall 'six'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
I tried install HPCCloud with this repo, but when I run "vagrant up" the error above occours and stop the ansible script.
Anyone can help me?

I run into the same issue. Has anyone got this basic PyFR tutorial to work?

I am guessing an upstream package has changed. I will try to take a look this week.

So I have tracked down some issues with Girder ansible role and have push a PR upstream girder/girder#2771, once this is resolve I should be able update things here.

@hdutra Yes, there are still some issue with the cumulus dependencies, I need to test and push a PR. Just so you know we are plan of revamping the whole deployment process sometime in the near future. Probably moving to a containerize solution.

Hi @cjh1 , thanks for your help so far. I note that you mention you still need to test and push a new PR. I have some questions/comments on this:

At the moment, as you know, the 'vagrant up' installation fails at the 'Install cumulus dependencies' stage. For me, it complains that it 'Cannot uninstall 'urllib3. It is a distutils installed project...' etc.

At some point in the installation, the ./ansible/roles/girder directory is created on the host machine by downloading from "https://github.com/girder/ansible-role-girder/archive/v0.1.tar.gz". I realise the v0.1 release does not contain the updated pip.yml file (with the "Force install of..." update), but just so you know, even after manually copying the updated pip.yml file onto my local machine, I still experience the same error as in point 1.

Would it be possible for you to let me know when you think these issues might be resolved by? We would like to see if we can develop an application using HPCCloud, but we have been unable to give it a try so far due to these issues with the deployment repository. Thank you.

In your previous comment, you mentioned that the team is looking at moving to a containerized solution for deployment in the near future. Would it be possible for you to estimate when that might happen?

Thank you.

@nandangokhale I just merged #122 which should resolve the issues we are seeing.

At the moment, as you know, the 'vagrant up' installation fails at the 'Install cumulus dependencies' stage. For me, it complains that it 'Cannot uninstall 'urllib3. It is a distutils installed project...' etc.
At some point in the installation, the ./ansible/roles/girder directory is created on the host machine by downloading from "https://github.com/girder/ansible-role-girder/archive/v0.1.tar.gz". I realise the v0.1 release does not contain the updated pip.yml file (with the "Force install of..." update), but just so you know, even after manually copying the updated pip.yml file onto my local machine, I still experience the same error as in point 1.

I would remove /ansible/roles/girder before trying vagrant up again.

Would it be possible for you to let me know when you think these issues might be resolved by? We would like to see if we can develop an application using HPCCloud, but we have been unable to give it a try so far due to these issues with the deployment repository. Thank you.

Should be resolve

In your previous comment, you mentioned that the team is looking at moving to a containerized solution for deployment in the near future. Would it be possible for you to estimate when that might happen?
Probably towards the end of the year.


Update index.html

Hi @CHETANYA20, if you want to modify the theme for your own use you can simply clone it and make the necessary changes on your end itself. There's no need for a PR here :)


fix(#1496): Restrict dropdown width to parent container

Issue
In scenarios where dropdown width is set to be more than the parent container the dropdown should respect the parent container width. This applies when there isn't enough screen real-estate.
The videos show how the below piece of React code is rendered before and after this change
      <GoADropdown name="colors" value={"red"} onChange={onChange} width="700px">
        <GoADropdownItem value="red" label="Red" />
        <GoADropdownItem value="green" label="Green" />
        <GoADropdownItem value="blue" label="Blue" />
      </GoADropdown>

Note
The issue still persists when the screen size is changed. This only computes the parent container width on initial render.
Before
https://github.com/GovAlta/ui-components/assets/119442489/84a1bc1c-6d40-4dba-ae71-2247e350fd33
After
https://github.com/GovAlta/ui-components/assets/119442489/2094bcd8-5289-41a4-a21e-3be7ba468d99

Issue is verified on chrome, edge and firefox

:tada: This PR is included in version 1.17.0-alpha.13 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.17.0-alpha.13 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-alpha.4 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


adding some badges to the readme to make it look more visually appealing

I would like to work on this issue. Can you please assign this issue to me.

Hey @1Shubham7 , Could you please add Gssoc label for this issue

@1Shubham7 Please add the level label for the issue

@1Shubham7 Please add level badge (like level 2 or level 3).
Then only gssoc will consider points


test data?

Hi! First of all, thanks for developing this tool, I'm excited to test it out!
Would it be possible to include some test data? I'm having a hard time figuring out what needs to be in my working directory.
Thanks!

Test data is uploaded.
The working directory should contain the AF models and the corresponding .json files. There is nothing else that needs to be in the working directory, but you can have other files and the model should just skip over them.  Let me know if you have any more questions!


Deep TabNine (autocompletion with deep learning)

Does tabnine-sublime support Deep TabNine (autocompletion with deep learning)?
https://tabnine.com/blog/deep

Yep, you need a beta key but once you activate it it will work with any TabNine client.


release 0.10.4

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (f1b9179) 95.78% compared to head (17ce5d2) 95.78%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #53   +/-   ##
=======================================
  Coverage   95.78%   95.78%
=======================================
  Files          47       47
  Lines        3515     3515
=======================================
  Hits         3367     3367
  Misses        148      148

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Casting from buffer to raw pointers is broken

For a reproducer, see: https://github.com/asoffer/Icarus/blob/8675cfd824646f61b17fc6f594c8ceb085323008/examples/regressions.ic#L3-L6
Observed error:
[139935698491208 compiler/emit/common.cc:689 EmitCast] Unreachable code-path.
([*](i64),  to , *(i64))
*** SIGABRT received at time=1642356344 on cpu 5 ***
PC: @     0x7f4551a38808  (unknown)  pthread_kill
    @          0x15e53a0         64  absl::WriteFailureInfo()
    @          0x15e5084        224  absl::AbslFailureSignalHandler()
    @     0x7f45519e4520  (unknown)  (unknown)
Aborted (core dumped)

This is fixed now.


Failed to install 'phonegap-plugin-push':Error: pod: fatal: Not a git repository

On my ionic 1 project, I'm trying to fetch phonegap-plugin-push plugin version 1.11.1
My config.xml has the following code:
<plugin name="phonegap-plugin-push" spec="1.11.1"> 		<variable name="SENDER_ID" value="207258139553"/> 	</plugin>
But I when I do
Cordova platform add ios
I get the following error:
Failed to install 'phonegap-plugin-push':Error: pod: Command failed with exit code 1 Error output: fatal: Not a git repository (or any of the parent directories): .git   fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git     at ChildProcess.whenDone (/Users/folder/Proyectos/project/platforms/ios/cordova/node_modules/cordova-common/src/superspawn.js:169:23)     at emitTwo (events.js:126:13)     at ChildProcess.emit (events.js:214:7)     at maybeClose (internal/child_process.js:925:16)     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
So I can't release my app because it produces this error:

'GoogleCloudMessaging.h' file not found

I think the error is related with cocoapods.
If I do
cd platforms/ios

and then
pod setup

Ionic version: 2.2.2
Cordova version 6.5.0
Thanks

@fgagneten I think this issue is related to Google deprecated GCM libraries and servers.
https://developers.google.com/cloud-messaging/android/android-migrate-fcm#update_server_endpoints
I'm using the version 1.10.6 and I got this error on registration

Didn't find class "com.google.android.gms.common.util.zzv"

I don't know why but it automatically fixed. May be was a temporary error


Error With DynamX Mod

When you have the mod on and drive in the mod DynamX car the head sometimes becomes invisible which looks very weird


Use NPM v5+ for project package management

What are your thoughts on using Yarn for package management in this project?
Goal
Decide whether to use Yarn to manage this project's dependencies. Start using Yarn, if it is deemed desirable.

It may be worth waiting until npm5 is released, which should match yarn for performance, without having some of the cross-platform issues.

Agreed with @MikeRalphson the task should be use node 8 and npm 5 😄

Just a note that npm5 is in fact compatible with all versions of Node from 4.x - I am using it with Node 6.10 without issues so far. Only setting up continuous integration jobs might require extra work.

Alright, I will change the title of this task to 'use NPM v5+ for project package management'.

Good idea, @MikeRalphson . I created #118 to keep that in mind.


Add bind timeout to config schema

Refs: https://github.com/metarhia/impress/issues/1523

[x] tests and linter show no problems (npm t)
[x] code is properly formatted (npm run fmt)

Landed in https://github.com/metarhia/impress/commit/54cf61c5c819a008208220826be2a0a3c0a63191


[WICKET-7080] 1) make default events delivery machinery pluggable 2) …

make default events delivery machinery plug-gable
allow to disabled sending events
defines a reflection based machinery to deliver events

This PR still needs some more work and care

I have added more tests and allow to use more that one eventType

https://github.com/wicketstuff/core/tree/master/annotationeventdispatcher-parent

https://github.com/wicketstuff/core/tree/master/annotationeventdispatcher-parent

@martin-g I'm aware of that work. This PR is 2 things

Make "default" event delivery plug-able. This means replacing it by something else (or disabling it)
Some simple event annotation based events delivery. Where you can get protected or private or public methods injected with an event,

@OnEvent(XXX.class)
protected onXXX(IEvent<XXX>  event) {
}

This allows to still work with event and programmatically cancel it.
or
@OnEvent(XXX.class)
protected onXXX(XXX  payload) {
}

will both work. No restrictions on XXX are imposed.
IMHO, 1. would be nice to have in wicket. As for 2. I can understand can be implemented in many different ways.

This approach does not require a component listener and only marked classes are scanned (by annotation or implementing an interface)

@martin-g My last commits adds caching

Ok, I have reverted the part related to adding a reflection based machinery. What remains is:

Allow to plug your own default "event  handler"
As a side effect it is possible to disable events delivery


remove access validation from get zone by name service

The terraform provider doesn't support batch change so users need to make records in shared zones through the recordset API endpoint. The recordset endpoint requires a zone ID, so terraform clients need to be able to get a zone by name to find out the zone id.
This is a read-only endpoint so there's not a need for access validations based on zone ownership or system administration. There's also already initial validations at the routing endpoint to ensure locked users and users without access to the system cannot make the request.
Changes in this pull request:

remove access validation from getZoneByName method in the Zone Service

For record keeping purposes, this is the corresponnding terraform-provider-vinyldns issue:
https://github.com/vinyldns/terraform-provider-vinyldns/issues/60


Normalize output format handling (-t) to match input (-f)

Fixes #5.
There were a couple logic problems.

The results of processing the --to argument were getting clobbered by file name guessing
There were two variables being held with the target format, args.to and output_format. They were used in different places and it was possible for them to be out of sync, causing unexpected results.

This normalizes the whole mess on one variable (args.to_format) and handles setting it just like --from instead of ... differently. The only place other variables are used is in passing arguments to panflute, which apparently wants named arguments in a slightly different format.
I have not been able to test this very exhaustively with all the backends and situations that might be affected. Please proceed with caution on this one, and if something needs fixing I'd be happy to do it.
Depending on what order you merge this or #11 might need to be rebased before merging. Feel free to do ether one and I'll update the PR for the other.

Pull Request Test Coverage Report for Build 42

20 of 23 (86.96%)  changed or added relevant lines in 2 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-1.9%) to 87.547%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pancritic/main.py
14
17
82.35%

Files with Coverage Reduction
New Missed Lines
%

pancritic/main.py
1
86.73%

Totals

Change from base Build 36:
-1.9%

Covered Lines:
184

Relevant Lines:
205

💛  - Coveralls

I'm not familiar with testing frameworks in python and am not sure what, if anything, needs to be done about the coverage issue.

Rebased to resolve merge conflict...

Travis failure appears to be related to #13 again. I think this is working as expected.


Ability to override just "some" of default TextStyle attributes in CupertinoTextThemeData

CupertinoTextThemeData's TextStyle should maintain default values when setting some attributes.
Example:
If you just want to change the default text color throughout the app:
return CupertinoApp(
        title: 'Test App',
        theme: const CupertinoThemeData(
            textTheme: CupertinoTextThemeData(
                primaryColor: CupertinoColors.black,
                textStyle: TextStyle(
                  color: CupertinoColors.darkBackgroundGray, /// here
                ))),
...

This will result change in fontSize across the whole app which is not intended behavior. There should be some way to adjust only a selection of TextStyle attributes, like text color, keeping other TextStyle's default values, like fontSize untouched.
Thank you for all the great work.

Hi @ramtinq, this seems like a bug, can you provide a complete minimal reproducible code sample along with the output of flutter doctor -v?
Thank you


Fix bug #133

fix #133

add "ignore" flag to Failures
mark ignored failures during collection of failures in Job class
update unit tests

/ok-to-test

Label ok-to-test is not a predefined one, will not be added / removed.
Available labels:

hold
verified
wip
lgtm

pre-commit.ci run

/verified


Bugfixes and new Version Tag

This is very promising tool and library, that seems to have compelled in progress.
The latest version 1.0.3 from 2013 (!) has some flaws that can be fixed. Anybody interested in this besides the author?

@maximebf Maybe creating a Organization for this project might revive development?
http://fabien.potencier.org/article/75/about-personal-github-accounts

Moved the repo to its own organization


Debian/Ubuntu packaging of calico-felix for arm64/ppel64

Hello,
Here is packaging adapation I made for my own use:
diff -Nur felix-3.15.1.orig/debian/calico-felix.install felix-3.15.1/debian/calico-felix.install
--- felix-3.15.1.orig/debian/calico-felix.install	2020-07-07 18:01:24.000000000 +0200
+++ felix-3.15.1/debian/calico-felix.install	2020-07-29 13:35:22.393733175 +0200
@@ -1,3 +1,2 @@
 usr/bin/calico-felix usr/bin
-usr/lib/calico/bpf/* usr/lib/calico/bpf
 usr/etc/calico/felix.cfg.example etc/calico
diff -Nur felix-3.15.1.orig/debian/calico-felix.install.amd64 felix-3.15.1/debian/calico-felix.install.amd64
--- felix-3.15.1.orig/debian/calico-felix.install.amd64	1970-01-01 01:00:00.000000000 +0100
+++ felix-3.15.1/debian/calico-felix.install.amd64	2020-07-29 13:35:12.633827720 +0200
@@ -0,0 +1,3 @@
+usr/bin/calico-felix usr/bin
+usr/lib/calico/bpf/* usr/lib/calico/bpf
+usr/etc/calico/felix.cfg.example etc/calico
diff -Nur felix-3.15.1.orig/debian/changelog felix-3.15.1/debian/changelog
--- felix-3.15.1.orig/debian/changelog	2020-07-07 18:02:00.000000000 +0200
+++ felix-3.15.1/debian/changelog	2020-07-29 13:21:10.209867771 +0200
@@ -1,4 +1,4 @@
-felix (3.15.1-bionic) bionic; urgency=low
+felix (3.15.1-1) unstable; urgency=low

   * Felix v3.15.1 (from Git commit 75f7e6a).

diff -Nur felix-3.15.1.orig/debian/control felix-3.15.1/debian/control
--- felix-3.15.1.orig/debian/control	2020-07-07 18:01:24.000000000 +0200
+++ felix-3.15.1/debian/control	2020-07-29 13:27:43.386109746 +0200
@@ -2,7 +2,9 @@
 Section: net
 Priority: optional
 Maintainer: Project Calico Maintainers<EMAIL_ADDRESS>-Build-Depends: debhelper (>= 8.0.0), dh-systemd
+Build-Depends: debhelper (>= 8.0.0), dh-systemd,
+# To download binaries from GitHub
+ curl, ca-certificates,
 Standards-Version: 3.9.4

 Package: calico-common
@@ -21,7 +23,7 @@
  This package provides common files.

 Package: calico-felix
-Architecture: amd64 ppc64el
+Architecture: any
 Depends:
  calico-common (= ${binary:Version}),
  conntrack,
diff -Nur felix-3.15.1.orig/debian/files felix-3.15.1/debian/files
--- felix-3.15.1.orig/debian/files	1970-01-01 01:00:00.000000000 +0100
+++ felix-3.15.1/debian/files	2020-07-29 13:35:36.061594070 +0200
@@ -0,0 +1 @@
+felix_3.15.1-1_source.buildinfo net optional
diff -Nur felix-3.15.1.orig/debian/rules felix-3.15.1/debian/rules
--- felix-3.15.1.orig/debian/rules	2020-07-07 18:01:24.000000000 +0200
+++ felix-3.15.1/debian/rules	2020-07-29 13:20:43.458124073 +0200
@@ -3,6 +3,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1

+# Cannot use /usr/share/dpkg/pkg-info.mk here because upstream use a native package and dash in versionning
+UPSTREAM_VERSION := $(shell dpkg-parsechangelog -SVersion | sed -e 's/^\([0-9]:\)\?\([0-9\.]\+\).*/\2/')
+
 %:
 	dh $@  --with systemd

@@ -10,7 +13,10 @@
 	# Don't clean, because that would delete bin/calico-felix.

 override_dh_auto_build:
-	# No building required.
+	# Can only "build" with arch matching GitHub binary releases
+ifeq (,$(filter $(DEB_BUILD_ARCH),amd64 arm64 ppc64el))
+	$(error Only supported on amd64, arm64 and ppc64el)
+endif

 override_dh_auto_test:
 	# No testing required.
@@ -21,9 +27,13 @@
 	install -d debian/tmp/usr/share/calico/bird
 	install -m 644 etc/bird/*.template debian/tmp/usr/share/calico/bird
 	install -d debian/tmp/usr/bin
-	install -m 755 bin/* etc/calico-diags etc/*.sh debian/tmp/usr/bin/
+	curl -L https://github.com/projectcalico/felix/releases/download/v$(UPSTREAM_VERSION)/calico-felix-$(DEB_BUILD_ARCH) \
+	  -o debian/tmp/usr/bin/calico-felix
+	install -m 755 etc/calico-diags etc/*.sh debian/tmp/usr/bin/
+ifeq ($(DEB_BUILD_ARCH),amd64)
 	install -d debian/tmp/usr/lib/calico/bpf
 	install -m 644 bpf-apache/bin/*.o bpf-gpl/bin/*.o debian/tmp/usr/lib/calico/bpf/
+endif
 	dh_install

 # strip fails on some of our binaries, disable it.
diff -Nur felix-3.15.1.orig/debian/source/format felix-3.15.1/debian/source/format
--- felix-3.15.1.orig/debian/source/format	2020-07-07 18:01:24.000000000 +0200
+++ felix-3.15.1/debian/source/format	2020-07-29 13:22:25.553146432 +0200
@@ -1 +1 @@
-3.0 (native)
+3.0 (quilt)

Hunks related to .install files are because I strongly suspect bpf files to be arch specific, so I remove them from non-amd64 packages.
Changelog and source/format hunks are here to produce a non-native package (usually limited to Debian/Ubuntu internal tooling). This will generate different tarballs for sources and debian packaging.
If I understood correctly, CI is building the package so you may want to wrap this in a new ifeq statement, that could match "git" pattern in $UPSTREAM_VERSION to have different behavior for release and daily builds.
Some additional remarks:

Binary amd64 embedded in deb package is different from the one from GitHub release page, you should consider checking https://reproducible-builds.org/ to avoid this
Ubuntu PPA should be also modified to handle arm64 and ppc64el archs
Using a "-" in upstream version (like x.y.z-bionic) make it incompatible with Debian, this is a reserved char for splitting upstream and distribution parts, I'm not sure this can be modified but this might fix itself if moving from native package to regular one
Is it possible to provide Debian stable (would suggest stretch + buster) packages on PPA? I'm not sure
Calicoctl is not available as a Debian package, but I think it should be, I'll hack around and open another ticket for that.

Regards, Adam.

@eLvErDe we can't accept patches in issue comments because we need the CLA to be signed (and it's a lot of work); if you want to contribute to felix, please reach out on our slack in the #contributors channel and submit PRs to the felix repo.


Link to relevant guidelines for event-driven architecture

I hope I got the relative links right.

Learn Build status updates of commit 942590d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

well-architected/mission-critical/mission-critical-application-design.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@calcof
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Learn Build status updates of commit 9e3232f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

well-architected/mission-critical/mission-critical-application-design.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#sign-off

Is this stuck?

@msimecek
Thanks for your review. In the public repo, pull requests should be approved by the author, another member of the content team, or a PM.
@CalCof
Could you take a look? Thanks!

Friendly reminder that this is still waiting...

@PageWriter-MSFT
Would you be able to review and approve the changes in this PR?
Thanks.

Wonderful! Thanks so much for helping get this across the finish line.


FIX: Assign conducting plate bug

Close #4689

@sshbsshb

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 75.58%. Comparing base (cc5fb48) to head (5242bd2).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4695      +/-   ##
==========================================
- Coverage   80.48%   75.58%   -4.91%
==========================================
  Files         122      121       -1
  Lines       54964    54904      -60
==========================================
- Hits        44240    41500    -2740
- Misses      10724    13404    +2680


Proper Cocoapods support

I'm trying to use the pushy-react-native to my existing native project (brown field). Since We use cocoapods as dependency manager and as I can see pushy also have a podspec file, thought it will be a easy integration. But I end up having some issues. The experience was not as easy as other popular react native community projects.
To make it even better support for cocoapods. I would like to propose the below changes.

Move the PushyRN.podspec to root directory
Mention correct version string (Probably someone has to update manually every time there is a new release Or we could automate it by getting version string from package.json)
Mention correct source file link for s.source_files

By above changes it will be easy for brown field app developer to integrate the SDK.(also, if you watch React Native team plan closely - lean core - one of the action item was to support cocoapods to link IOS libraries, So we would be ready before it happens)
Happy to send PR!

To make a note, it won't break the existing functionalities. a.k.a with react-native link ***

Hi @rizwankce,
Thanks so much for these suggestions!
It would be great if we could support native Cocoapods as well without relying on npm/RN link.
A PR for these would be greatly appreciated, as long as it doesn't break the current npm install and react-native link install procedure in our docs.
Cheers! 🎉

@pushy-me Let me work on the PR and probably create a sample projects just to make sure it won't break existing functionalities.


Fix few bugs and bump to v1.3.9

Fix weblogo dependancy
Fix unit test
Migrate python2 to python3

Hi @gabrielctn :wave:
Could you explain if this PR preserve or breaks back compatibility with Python 2?
All tests in CI failed because of
The command "sh -e /etc/init.d/xvfb start" failed and exited with 127 during .

It may worth we move to GitHub actions. @HubLot could you please help us with this?

Hi @gabrielctn :wave:
Could you explain if this PR preserve or breaks back compatibility with Python 2?
All tests in CI failed because of
The command "sh -e /etc/init.d/xvfb start" failed and exited with 127 during .

It may worth we move to GitHub actions. @HubLot could you please help us with this?

Hi,
Thanks for this PR ! It's great to have some improvements.
I agree with @pierrepo  we should move to actions! I gonna look into it. I prefer to not merge this until this is done.
I'm not a big fan of having merge commits from a fork into the original repo but it's not a big deal either. Maybe, for the next time, you can propose PR directly here. All of us will be happy to merge :)
If it breaks python 2 compatibility (which I don't mind), the new version should be 2.0.0 or at least 1.4.0.

Hi,
Thanks for this PR ! It's great to have some improvements.
I agree with @pierrepo  we should move to actions! I gonna look into it. I prefer to not merge this until this is done.
I'm not a big fan of having merge commits from a fork into the original repo but it's not a big deal either. Maybe, for the next time, you can propose PR directly here. All of us will be happy to merge :)
If it breaks python 2 compatibility (which I don't mind), the new version should be 2.0.0 or at least 1.4.0.

Thanks @HubLot for your input.
I don't mind either if we break the Python 2 compatibility but we indeed must state it clearly (version 1.4.0 sounds good).
If we move forward, I'll add in the Citation section of the README.md that version 1.3.8 corresponds to the paper and will link to Zenodo and Sofware Heritage warehouses.

Thanks @HubLot for your input.
I don't mind either if we break the Python 2 compatibility but we indeed must state it clearly (version 1.4.0 sounds good).
If we move forward, I'll add in the Citation section of the README.md that version 1.3.8 corresponds to the paper and will link to Zenodo and Sofware Heritage warehouses.

I updated the CI to GitHub Actions in PR #176.
Besides the issue with Weblogo import name, it's working but with the lost of Python 2.7 and 3.4
So, I suggest to first merge this PR (once question raised solved) and after mine.

I updated the CI to GitHub Actions in PR #176.
Besides the issue with Weblogo import name, it's working but with the lost of Python 2.7 and 3.4
So, I suggest to first merge this PR (once question raised solved) and after mine.

Thanks @gabrielctn  for the new commits.
From what I see, here is what remains to be done:

Change bump version from 1.3.9  to 1.4.0
Update setup.py to precise the version of Weblogo
Update README to remove Python 3.4 support and add Python >=3.6
Update `docs/source/installation.rst with the above changes.

Thanks @gabrielctn  for the new commits.
From what I see, here is what remains to be done:

Change bump version from 1.3.9  to 1.4.0
Update setup.py to precise the version of Weblogo
Update README to remove Python 3.4 support and add Python >=3.6
Update `docs/source/installation.rst with the above changes.

It is not only the README that needs to be made aware of the python that are supported. If we want to play it modern, then we need to tell setup.py as well: https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires

It is not only the README that needs to be made aware of the python that are supported. If we want to play it modern, then we need to tell setup.py as well: https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires

Thank you for your reviewing !
All tests are passing on my side, if you see something missing please tell me, otherwise we're good to merge.

Thank you for your reviewing !
All tests are passing on my side, if you see something missing please tell me, otherwise we're good to merge.

Good to me too!

Good to me too!

Looks very good to me too. Maybe I should merge #176 first.

Looks very good to me too. Maybe I should merge #176 first.

Readthedocs still has the previous version. I don't know if we need to trigger it or if it's done automatically. @pierrepo could you look into it ? Don't forger also to update the CITATION section :)

Readthedocs still has the previous version. I don't know if we need to trigger it or if it's done automatically. @pierrepo could you look into it ? Don't forger also to update the CITATION section :)

Readthedocs still has the previous version. I don't know if we need to trigger it or if it's done automatically. @pierrepo could you look into it ?

For some unknown raisons, I had to create the build of the doc manualy :astonished:  The doc is now up-to-date!

Don't forger also to update the CITATION section :)

On my way.

Readthedocs still has the previous version. I don't know if we need to trigger it or if it's done automatically. @pierrepo could you look into it ?

For some unknown raisons, I had to create the build of the doc manualy :astonished:  The doc is now up-to-date!

Don't forger also to update the CITATION section :)

On my way.


Suggested Fixes

Major enhancement to MapRoulette to allow 'Suggested Fixes': MapRoulette offers a ready-to-go changeset that the mapper only needs to validate to add it to OSM directly.
Needs a lot of thinking and discussion
Some use cases and discussion here

For now we will not cover geometries, only tag adding / merging.

When will tag merging be possible  @mvexel ?

This would be really neat, a while back I wrote a basic tool to find matches between OSM and an import data source, it showed tag changes for a human to review and then used the JOSM RemoteControl API to send those changes to JOSM for upload.
However it was not conductive of letting multiple people work on the import or tracking progress, something that MR does very well at.

I wrote up some more workflow and UI considerations including Achavi examples in the paper doc


Solve the problem of non-standard statefulset creation mode

@laik I modified the apiversion match logical. Thanks for the contribution!


Add new eslint rule which removes the need to have React in scope

Description
As of React 17, the need to have React in scope is no longer necessary. JSX Transform was introduced and it takes care of injecting react for us. This ESLint rule removes the warning you would normally get when React is not in scope.
I've also changed all the existing files to remove React as well.
For more information on this subject, be sure to check the blog on JSX Transform.
Comment on the PR if you have any questions.
Motivation and Context
This change will bring the repo to use the new tech available!
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works

pull latest changes from master


(https://github.com/DonovanDMC/ProjectExpansion/issues/120)https://github.com/DonovanDMC/ProjectExpansion/issues/120
"""/give @p minecraft:iron_ingot{display:{Name:'{"text":"ingot"}'}} 64"""
put this item in ae

https://github.com/DonovanDMC/ProjectExpansion/assets/73775469/a1a04a5f-846d-4c29-83b1-acb04ef378c2


Bump to new 3.8.x Quarkus.io

Fixes #

Proposed Changes

bump to 3.8x

Release Note

Docs

/retest


Rewrote parser

Codecov Report
Patch coverage: 85.47% and project coverage change: -1.25 :warning:

Comparison is base (105ad08) 88.95% compared to head (6a619b9) 87.70%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #12      +/-   ##
==========================================
- Coverage   88.95%   87.70%   -1.25%
==========================================
  Files          13       15       +2
  Lines         362      496     +134
  Branches       34       73      +39
==========================================
+ Hits          322      435     +113
- Misses         33       39       +6
- Partials        7       22      +15

Impacted Files
Coverage Δ

bulk_mv/cli.py
0.00% <0.00%> (ø)

bulk_mv/operations.py
83.87% <80.00%> (-2.34%)
:arrow_down:

bulk_mv/file_tree.py
89.85% <81.25%> (ø)

bulk_mv/bmv_parser.py
86.70% <86.70%> (-11.34%)
:arrow_down:

bulk_mv/__init__.py
100.00% <100.00%> (ø)

bulk_mv/bmv_generator.py
100.00% <100.00%> (ø)

bulk_mv/tests/test_bmv_generator.py
100.00% <100.00%> (ø)

bulk_mv/tests/test_bmv_parser.py
100.00% <100.00%> (+6.25%)
:arrow_up:

bulk_mv/tests/test_file_tree.py
100.00% <100.00%> (ø)

bulk_mv/tests/test_operations.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[Epic]: Update underlying software

Codemod
Strategies
Minor changes as soon as possible --> implement process
sort this list

[ ] Remix
[ ] Prisma (Upgrade Prisma)
[ ] Supabase (Upgrade Guide v2)
[ ] React
[ ] Nodejs
[ ] TypeScript
[ ] ...

Major changes (process)

validate
PoC

Infrastructure
reached limit image proxy?
Check limits and TTLs' on our servers (cache, upload limits, jwt expiry, etc...)


Output of keys list doesn't match docs

What is the current behavior?
https://developers.deepgram.com/sdks-tools/sdks/node-sdk/keys/#list-project-keys-example-request
These docs suggest this output when I list API keys for a project
{
  api_keys: [
    {
      api_key_id: string,
      comment: string,
      created: string,
      scopes: Array<string>
    },
  ];
}

but i get this output
{
  api_keys: [
    {
      member: {
        member_id: '...',
        email: '...
      },
      api_key: {
        api_key_id: '...',
        comment: '...',
        scopes: [...],
        created: '...'
      }
    },
    ...
  ]
}

it looks like the typing is correct to the docs, but what is returned doesn't respect the types?

This is an issue both with the types on the SDK and the SDK docs. They do not match the API Reference


Form Validation on text-help

Documentation says that .text-help will have styling applied when parent element has .has-warning, .has-error, or .has-success. However this isn't happening. Looks like the styling is applied to V3s .help-block instead. Docs also say that 'No official help text classes exist in Bootstrap 4 (previously we had .help-block in v3),'

CC: @mdo

@mdo Ping.

Fixed with #18089.


Build error with Microsoft.ReactNative, 'Mso::MustBeNoExceptVoidFunctor: not a noexcept callable functor returning void'

Problem Description
5>------ Build started: Project: Microsoft.ReactNative, Configuration: Debug x64 ------
5>C:\Users\chrisg.NTDEV\source\repos\react-native-xaml\node_modules\react-native-windows\Mso\dispatchQueue\dispatchQueue.h(728,17): error C2338: static_assert failed: 'Mso::MustBeNoExceptVoidFunctor: not a noexcept callable functor returning void'
5>C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\XamlCompiler\Microsoft.Windows.UI.Xaml.Common.targets(486,5): error MSB4181: The "CompileXaml" task returned false but did not log an error.
Steps To Reproduce

clone the repo, follow the directions to enable building (run yarn, etc.)
open the example\windows\example.sln
choose debug/x64 configuration
project.build

this is compiling pch\pch.cpp
I found (by accident) that removing this line from pch.h fixes this problem.
using namespace winrt::Windows::Foundation;
Note, I upgraded the toolset to v143, but I saw the same error when I tried to build with v140 so don't think this is specific to the toolset.
Should I prepare a PR to remove that using namespace?
Expected Results
build works
Environment
npx react-native info
Get-ChildItem : Cannot find path 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise C:\Program Files
(x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\Extensions\' because it does not exist.
At C:\Users\chrisg.NTDEV\source\repos\react-native-xaml\node_modules\react-native-windows\Scripts\rnw-dependencies.ps1:
174 char:19
+ ...   $natvis = Get-ChildItem "$vsPath\Common7\IDE\Extensions\cppwinrt.na ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Program File...IDE\Extensions\:String) [Get-ChildItem], ItemNotFound
   Exception
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.22621
    CPU: (12) x64 Intel(R) Xeon(R) W-2133 CPU @ 3.60GHz
    Memory: 8.94 GB / 31.73 GB
  Binaries:
    Node: 16.14.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.3.1 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
      Versions: 10.0.18362.0, 10.0.19041.0
  IDEs:
    Android Studio: Not Found
    Visual Studio: 17.3.32929.385 (Visual Studio Enterprise 2022), 16.11.32929.386 (Visual Studio Enterprise 2019)
  Languages:
    Java: Not Found
  npmPackages:
    @react-native-community/cli: Not Found
    react: Not Found
    react-native: Not Found
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

this is an RNW bug that has already been fixed https://github.com/microsoft/react-native-windows/issues/9559
so the project needs to update to a newer version of RNW

@asklar thanks! how do I update to the newer RNW? is that something I should try?

I updated the title. this is in the example in this project. example/windows/example.sln


result redaction

Please add a summary of your change
This PR adds a new feature - live result redaction. If there's something in the immutable audit log that shouldn't be exposed, you can supply a regex to the API pod as the environment variable REDACT_REGEX. Then when returning an event, the supplied regex is run against every field of the event, and any matches are replaced with the sha256sum of the match.

this needs to be held while we discuss the product functionality and timing.

Going to add this PR to the current SC ticket for tracking.

This is a good idea but can probably be rethought as RBAC/ACL and masking instead.


Just some documentation updates

It looks like this may be pulling in your hotfix commit too as if it didn't get pushed to develop.

@genebean Looks good, thanks for catching these! I'm not sure why the hotfix commit is showing up, it looks fine from the history on master and develop branches. Anyways, I'll do a release later today.


[Question] Default language without translation file

Hi,
Our default template language is English and it feels troublesome to have translation from EN to EN (it might be needed for some installation that wishes to change default translations). Any way to inform gettext about default translation language so that it does not attempts to find translation?
Or in such case you would just turn off debug and that's it?

Just turn debug of. We have a project where we do exactly that: allow customisation of user interface strings by allowing users to edit the English texts. For 99% of the strings the translation is empty, so it falls back to the default string.

Thanks for comment.


nctalk: Format rich object strings

Currently nctalk mentions show up as {mention-user1}, {mention-user2}, ... on bridged platforms,
with this they show up as @somename.

👍


Log producer should have qualifier

Codecov Report

Merging #4 into master will not change coverage.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master       #4   +/-   ##
=========================================
  Coverage     92.26%   92.26%
  Complexity       88       88
=========================================
  Files            15       15
  Lines           194      194
  Branches         18       18
=========================================
  Hits            179      179
  Misses            9        9
  Partials          6        6

Impacted Files
Coverage Δ
Complexity Δ

.../java/org/djr/cdi/properties/PropertyResolver.java
88.57% <ø> (ø)
16 <0> (ø)
:arrow_down:

src/main/java/org/djr/cdi/logs/LoggerProducer.java
100% <100%> (ø)
2 <1> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 35

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.361%

Totals

Change from base Build 25:
0.0%

Covered Lines:
185

Relevant Lines:
194

💛  - Coveralls