Want to add Sign Up and Log In page.

Is your feature request related to a problem? Please describe.
We should add Sign Up and Log In Page in this project for better user interaction.

Describe the solution you'd like
I have a very good design of sign up and log in page in react.js.
Describe alternatives you've considered
No response
Additional context
No response
Code of Conduct

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

pls assign me this work. I want to contribute in your project.

Hey @Nikita110602 , login and signup page are already integrated.

@amanjaiman1 where can we can see those pages?


使用HWPanModalContentView的时候怎么关闭ViewController的侧滑返回

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

这个需要你自己关闭去控制
比较简单的是使用FDFullscreenPopGesture

这个需要你自己关闭去控制
比较简单的是使用FDFullscreenPopGesture

thanks


add new locations model

We're moving towards a location model that is focussed on the question "Where/how can I access this?".
Having three different Locations seems to cover the bases, and removing the DigitalLocation and PhysicalLocation as they aren't useful. If we found a use for them they would be a property of the Location e.g.
trait LocationType
object LocationType {
  case object Physical
  case object Digital
}
trait Location
case class OpenShelves() extends Location { type Format: LocationType.Physical }
case class DigitalResource() extends Location { type Format: LocationType.Digital }

This will then allow for ?items.locations.type=OpenShelves,DigitalResource and to be able to facet on that. As we're not storing the label of an item in ES, I might have to have a think about how those are constructed.
The spacing is all a bit strange, thanks scalafmt.

Did this refer to https://github.com/wellcomecollection/docs/tree/master/rfcs/020-locations_requesting? From what I can see it's similar but not necessarily identical

@jamieparkinson as the thinking has progressed, this supersedes that.

Is it worth RFCing this? It's quite a far-reaching change and it would be good to have more context

It felt like a small enough change that the discussions could happen over PRs. Happy to, but personally feel it's overkill.

I definitely agree that the current model is lacking. Feel like it's a significant-ish change just because it's to our "core" model, and even though it's small it's a breaking change for the API, the API consumers (including for images), the transformers, the merger, the inference manager and the ingestors.

Possibly stupid question: where do these now go? https://github.com/wellcomecollection/catalogue/blob/master/common/internal_model/src/main/resources/location-types.csv

I don't think setting the standard for every core model change we need an RFC.
This change is not really changing anything that is used (we use the iiif-image,iiif-presentation filter, but we know that's wrong) - but rather it's implementing the first phase of something we can use.
This model was never actually put into practise and now that is has been, we have a much better understanding of where to start.

Possibly stupid question: where do these now go? https://github.com/wellcomecollection/catalogue/blob/master/common/internal_model/src/main/resources/location-types.csv

These will be removed as we will read the data from other fields and map that to the new types.

@warrd We're deprecating the old Location model.
We need to support the frontend from any downtime with this breaking change, to do this we will:

add a new property to the model called work.items.locations2. This will only be returned if we have an include=location2
we can then build the the frontend for this behind a feature toggle
once we're happy with the model and the frontend, we will make the frontend read from locations2 by default
we will then move this model over to the work.items.locations property
then we update the frontend to read from ☝
remove the locations2 from the API

We will be indexing both for a period of time.
It's slightly long winded process, but it's simple and without down time.

We have to store / index both so that the frontend keeps working.
Yea, I could have a go at renaming the old one to LegacyLocation but can't see how there would be less swapping?

Were you thinking of having a single model that could serialise to both display models?

Add new Location model and rename old one as LegacyLocation
Rename the original internal model field to legacyLocation and add location field for the new one
Add a qurey parameter legacyLocation which defaults to true
Switch over front end to not use legacy location
Remove legacy location model, field and API functionality

Were you thinking of having a single model that could serialise to both display models?

Yes that was my original idea, failing that my other suggestion is above :point_up:

Were you thinking of having a single model that could serialise to both display models?

Yes that was my original idea, failing that my other suggestion is above ☝

The transformation rules are all different and we want to ultimately not use the sierra fields that we're using to create these locations.
Which has made me think I need to have a thinking about the items.locations.locationType filter too.

but can't see how there would be less swapping?

Your idea involves running a reindex for location2 and an additional reindex once its renamed. My one you just have a single reindex with location as the new model and legacyLocation as the old model

I would still run a new reindex to remove the legacyLocation property as a tidy up.

I want to avoid the V2 tidy up extravaganza we had before (and still have bits laying about in the code for).
Saying that is has made me think being able to run a new version of the API here would be handy...

Not strictly necessary, you can just wait until someone else needs to reindex for another reason. I guess also don't like the naming Location2 very much

you can just wait until someone else needs to reindex

I'd like to clean it up as a matter of finishing the work.

Well it's not really necessary once you have cleaned up the code, there is no harm the data sitting there for a few weeks as will clean up itself

But the naming thing is the main issue for me. If you are keen on doing things your way round then go for it, but maybe a better name for Location2? UpcomingLocation? It seems to me renaming the other one as legacy most matches the state of the models imo though.

(I accept we are probably in the bikeshed right now btw, especially as these names are only temporary)

Again, the naming is temporary so no-one is going to have to look at it beside me for a bit.
Saying that I do like the idea of deprecating the old model first, albeit we haven't given anyone anything to use as an alternative, but.. 🤷 🦐

@warrd I've pulled in the deprecated fix. How's this?


Roberts-SC phocomelia syndrome/ESCO2

Preferred gene-related syndrome label
Roberts-SC phocomelia syndrome
Synonyms
Roberts syndrome
SC phocomelia syndrome
Parent term (use OLS, or your favorite ontology browser)
Roberts syndrome (MONDO:0009997)
Definition
Any Roberts syndrome or SC phocomelia in which the cause of the disease is a mutation in the ESCO2 gene.
**Definition source (Please give PubMed ID, if applicable, in format PMID:#######)
PMID:18411254
Children terms (if applicable)
Your nano-attribution (ORCID) or URL for a working group

@nicolevasilevsky This request is coming from the ClinGen Syndromic Disorders GCEP. We were hoping to merge Roberts syndrome with SC phocomelia syndrome as Roberts-SC phocomelia syndrome. Currently, SC phocomelia syndrome (MONDO:0010009) is organized under Roberts syndrome (MONDO:0009997) as a mild variant of Roberts syndrome. Please don't hesitate to reach out to me for any additional information. Thank you so much.

@nicolevasilevsky This request is coming from the ClinGen Syndromic Disorders GCEP. We were hoping to merge Roberts syndrome with SC phocomelia syndrome as Roberts-SC phocomelia syndrome. Currently, SC phocomelia syndrome (MONDO:0010009) is organized under Roberts syndrome (MONDO:0009997) as a mild variant of Roberts syndrome. Please don't hesitate to reach out to me for any additional information. Thank you so much.

@mbalzotti There is an exact synonym on SC phocomelia syndrome that is Roberts-SC phocomelia syndrome (see NCIT).
I'm not sure I understand how your proposed term is different?
Thanks!

@mbalzotti There is an exact synonym on SC phocomelia syndrome that is Roberts-SC phocomelia syndrome (see NCIT).
I'm not sure I understand how your proposed term is different?
Thanks!

@mbalzotti I am unsure of the best approach here for Mondo, I need to ask @cmungall for advise.
Note:
Mondo currently has two separate classes. But both of these classes have an exact synonym of Roberts-SC phocomelia syndrome.
It's problematic that there are duplicate exact synonyms on both terms.

@ahamosh can we run this by you? This is our proposed solution:
create a grouping class:
New term: Roberts-SC phocomelia syndrome
children:
-MONDO_0009997 'Roberts syndrome' (OMIM:268300)
-MONDO_0010009 'SC phocomelia syndrome' (OMIM:269000)
(as siblings)
per Mondo call 2021-02-19
cc @pnrobinson @cmungall

note to self - consider making a design pattern for this

Hi All,  Sorry for the delay. OMIM will call this Roberts SC phocomelia syndrome and combine the entries.  I will get the number back to you shortly (it will be merged into one of the existing entries).    Although the outcome for this query, making a parent with two children as siblings is the way that I would deal with many of the requests coming from ClinGen, but let's continue to discuss on a case by case (each one seems to be unique!)

FYI we will combine these 2 in 268300.
Thanks!

Great, thank you @ahamosh. I'll do the same in Mondo.


feat(cli): accept extra args for seed and migrate

This feature adds the ability to pass extra arguments to the seed and migrate commands, after a terminator (--). For example:
# prisma/seed.ts
prisma db seed --preview-feature -- --compiler-options '{\"module\":\"CommonJS\"}'
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Running ts-node --compiler-options {\"module\":\"CommonJS\"} "/Users/christian/Projects/Next/editorial/prisma/seed.ts" ...

This is useful for cases where you run Prisma CLI in a project with its own tsconfig.json that isn't compatible with ts-node, for example in a Next.js app.
Request for comment
This feature also works for other script files (seed.sh, seed.go and seed.js) but the difference is that args are passed after the file, making it possible for the file to read those arguments. For TypeScript files the args are passed before, in order for ts-node to correctly pick them up.
I'm not sure I like the current implementation as it could be abused in one way or another and cause some confusion.
One solution to this is, while still allowing passing extra args to the seed script by this approach, we should accept extra args as part of the migrate and seed commands that can be passed to ts-node exclusively.
Another is to only allow extra arguments for ts-node and not allow seed scripts to handle extra args.
Let me know what you think.
Related issues/comments

https://github.com/prisma/prisma/issues/5161#issuecomment-780872852
https://github.com/prisma/prisma/issues/5161#issuecomment-772328239
More comments from https://github.com/prisma/prisma/issues/5161

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

Not sure why it breaks the DbMigrate test:
Hello from generated seed
/tmp/76145844016f3c0d9297e367c5f61014/prisma/seed.js:1
BROKENCODE;;;;;
^

ReferenceError: BROKENCODE is not defined

Any clues?

Note: ReferenceError: BROKENCODE is not defined is intentional, it's for testing what happens when the seed errors.


H2 backports 2.4.58

Merge 1907696,1907697 from trunk:

  *) mod_http2: new directive 'H2MaxDataFrameLen n' to limit the maximum
     amount of response body bytes put into a single HTTP/2 DATA frame.
     Setting this to 0 places no limit (but the max size allowed by the
     protocol is observed).
     The module, by default, tries to use the maximum size possible, which is
     somewhat around 16KB. This sets the maximum. When less response data is
     available, smaller frames will be sent.

Merge r1909769 from trunk (plus sync mod_http2.xml)

  *) mod_http2: v2.0.15 with the following fixes and improvements
     - New directive 'H2EarlyHint name value' to add headers to a response,
       picked up already when a "103 Early Hints" response is sent. 'name' and
       'value' must comply to the HTTP field restrictions.
       This directive can be repeated several times and header fields of the
       same names add. Sending a 'Link' header with 'preload' relation will
       also cause a HTTP/2 PUSH if enabled and supported by the client.
     - Fixed an issue where requests were not logged and accounted in a timely
       fashion when the connection returns to "keepalive" handling, e.g. when
       the request served was the last outstanding one.
       This led to late appearance in access logs with wrong duration times
       reported.
     - Accurately report the bytes sent for a request in the '%O' Log format.
       This addresses #203, a long outstanding issue where mod_h2 has reported
       numbers over-eagerly from internal buffering and not what has actually
       been placed on the connection.
       The numbers are now the same with and without H2CopyFiles enabled.

Merge r1910157 from trunk

 * mod_proxy_http2: fixed using the wrong "bucket_alloc" from the backend
   connection when sending data on the frontend one. This caused crashes
   or infinite loops in rare situations.
 * mod_proxy_http2: fixed a bug in retry/response handling that could lead
   to wrong status codes or HTTP messages send at the end of response bodies
   exceeding the announced content-length.
 * mod_proxy_http2: fix retry handling to not leak temporary errors.
   On detecting that that an existing connection was shutdown by the other
   side, a 503 response leaked even though the request was retried on a
   fresh connection.
 * mod_http2: fixed a bug that did cleanup of consumed and pending buckets in
   the wrong order when a bucket_beam was destroyed.

Merge of 1910331,1910386,1910441 from trunk

  *) mod_http2: fixed a bug in flushing pending data on an already closed
     connection that could lead to a busy loop, preventing the HTTP/2 session
     to close down successfully. Fixed PR 66624.
     Fixed a bug that could lead to a crash in main connection
     output handling. This occured only when the last request on a HTTP/2
     connection had been processed and the session decided to shut down.
     This could lead to an attempt to send a final GOAWAY while the previous
     write was still in progress. See PR 66646.

Merged into 2.4.x as r1910699.


[fix](prepare statement) Not supported such prepared statement if pre…

…pare a forward master sql (#26512)
Proposed changes
The master PR: https://github.com/apache/doris/pull/26512

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


zgui: Dependency loop compile error

Seems to be the same bug as #282. Should the same workaround be applied to user_callback here until the compiler bug is fixed?
https://github.com/michal-z/zig-gamedev/blob/e31e3c280e0e00d3a15f56a4364a506169a5ebe5/libs/zgui/src/gui.zig#L3414-L3424

Hey this seems to be fixed now (using Zig 0.12.0-dev.1871+e426ae43a). Can you confirm that it's working for you?

Yep, it seems to work :+1:

Thanks!


Sort integers properly before verifying match

Oopsie.
Usually I use lodash or similar, but since it wasn't already a dependency, I opted to shoot myself in the leg instead. For clarity, Array.prototype.sort() uses alphabetical sorting by default, even on numbers.
This is a quick fix that I had to do for our tournament tomorrow. 😅

Ah, default lexicographical sort. Classic. Thanks a lot.

It's in<EMAIL_ADDRESS>

I love your response time on everything. Thanks a lot.
In case you're curious - this is the event we're using this on this weekend! https://www.facebook.com/events/1905511586437343/

NP. Always easy to do when there are tests included that demonstrate the failure clearly.
DDR looks like a cool use for ffa, individual scores collected into match scores, and progressively fewer players per match, leading to a classical 1v1 final :+1:
Always imagined it'd be most useful for a game where all players were in the same FFA match like Q3 or Mario Kart, but this is a nice twist. People too often use group stages leading to duel elim for this.
Have fun!


Texture pack compatibility

Version of Advanced Rocketry
[AdvancedRocketry-1.12.2-1.4.1-104-universal]
Have you verified this is an issue in the latest unstable build
Y
Version of LibVulpes
[LibVulpes-1.12.2-0.2.8-39-universal]
Version of Minecraft
[1.12.2]
Description of the problem

[space helmet not compatible with texture packs (resource pack : conquest) see screenshots above]

yes i have other mods installed but normally they aren't the problems since in vanila texture it works fine

Some mods DO modify texture loading and can cause incompatibilities with texture packs even when vanilla textures work fine.  So I wouldn't nessessarily make that assumption.  I'll look into it though

Cannot replicate with AR and libvulpes alone.


Move ApplicantQuestion inner classes to upper classes

Description

This PR does change the behavior of these classes - it simply refactors the old inner classes of ApplicantQuestion to be their own upper classes, and puts all of these classes in a new services.applicant.question package.
But it also adds new and more extensive tests! Now we thoroughly test the validation logic of the applicant question type classes.

Checklist

[x] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Issue(s)
Fixes #489.

FYI I will be working on this while Natalie is OOO


Rework calculation of external angles

New workflow:
Start with Hubbard tree
Node -> Node[]
Identify regions and boundary
Node -> region
Label the accesses of each node by its neighbors
Node -> region[]
Identify the characteristic set, the preimages of which form the whole tree
for each characteristic point calculate the binary expansion of its accesses.
If we use forward orbits we can get the binary expansions of the forward orbits of these accesses. How can we use preimages to get the binary expansions of the preperiodic branch points?

Question: If we first calculate the binary expansion of the critical point, can we then determine the angles of the branch points using solely the angle and not the hubbard tree?

This is in a better state. The boundary stuff needs to be rethought. Check the external angles of the alpha fixed point of 3/11 for failure, and look in Teichmuller vol 2 for the answer.


Terra's sprites

Description:
Terra's sprite has to be implemented.
Additional notes:
Commit reference:
d14bbbd5fad9f20151a22c3409082de1f3aa4289

Implemented and functional.


Keep getting "request to convert CR from an invalid group/version: cert-manager.io/v1alpha2" when upgrading cert-manager

Hi,
I've been struggling with this issue for a couple of weeks now.
To give some background to the error, one of out AKS clusters was upgraded from 1.19.11 to 1.22.6.  I know that support for v1alpha2 has been removed from this version of AKS but unfortunately, the cluster was upgraded before Cert-Manager was.  Before the upgrade, the cluster was running v0.13.0 of cert-manager (a very old version, I know).
I've tried removing all the Cert-Manager resources using the instructions for Helm in the Cert-Manager documentation; this seems to clean everything up ok.
I installed a newer version of cert manager using
helm upgrade --install cert-manager --namespace cert-manager --create-namespace --set installCRDs=true --set extraArgs='{--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=x.x.x.x:53}' --version v1.7.1 jetstack/cert-manager
The message I get back indicates that cert-manage has been installed successfully
Release "cert-manager" does not exist. Installing it now.
NAME: cert-manager
LAST DEPLOYED: Thu Feb 24 16:56:00 2022
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.7.1 has been deployed successfully!
In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
More information on the different types of issuers and how to configure them
can be found in our documentation:
https://cert-manager.io/docs/configuration/
For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the ingress-shim
documentation:
https://cert-manager.io/docs/usage/ingress/
But when I go to look at the cluster issuer I get the following error

I have tried creating a new cluster issuer using the following code
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email<EMAIL_ADDRESS>privateKeySecretRef:
name: sisca-challenge
solvers:
- selector: {}
dns01:
rfc2136:
nameserver: x.x.x.x:53
tsigKeyName: aks-apicluster-11114349-vmss-mkpv-grp-dnssv1.somewhere.com.
tsigAlgorithm: HMACMD5
tsigSecretSecretRef:
name: tsig-secret
key: tsig-secret-key
Again I get an error related to cert-manager.io/v1alpha2

Any help would be greatly appreciated.

In cert-manager v1.7 we removed support for alpha and beta cert-manager API versions.
From the error message it looks like you probably have some cert-manager resources stored in etcd at v1alpha2.
Did you follow our instructions how to upgrade cert-manager resources in v1.7 release notes https://github.com/cert-manager/cert-manager/releases/tag/v1.7.0?
If you haven't done that, a solution now might be to install an older cert-manager version that still understands those API versions and is compatible with your Kuberentes version (i.e v1.5.4), ensure you've follwed the resource upgrade instructions and then you should be able to upgrade to v1.7.1. (I haven't tried this path, but I think it should work- let us know if there are any issues).

Ok so I ran into this recently upgrading a cluster. I can probably give someone some help here if they run into this... Its easier to use the cmctl than running the curl command back to the api to update the underlying crd's. It looks like the cmctl upgrade migrate-api-version also upgrades the underlying objects along with the crd's. Here's a workplan I followed(I use reckoner currently which runs helm3 under the hood).
Cert-manager upgrade from 0.16 -> 1.5.5 -> 1.7.1.
The reason to go from 0.16 to 1.5.5 is because the cert-manager.io/v1alpha2 was fully removed in 1.6 and the etcd data must reflect the newer api version of cert-manager.io/v1 before you can then upgrade to 1.6 or higher.
Upgrade step 0.16 -> 1.5.5
Before upgrading in a stable environment renew the vault certificate first so if something unexpected happens and breaks we have time to fix it without certificates expiring... Check the verifications steps section for renewal steps.
BEFORE running this, ensure you backup these two objects below at the very least. https://cert-manager.io/docs/tutorials/backup/
> kc get clusterissuers <issuers> -o yaml > clusterissuers-backup.yaml
 > kc get certificates <cert> -o yaml -n blah > cert-backup.yaml

Change the apiVersion in the clusters/*/crds files from cert-manager.io/v1alpha2 to cert-manager.io/v1
Change the versions in the reckoner.yaml to 1.5.5 then:
$ reckoner plot --dry-run reckoner.yaml --heading cert-manager

➜ reckoner plot reckoner.yaml --heading cert-manager

Verification steps
Download cmctl:
OS=$(go env GOOS); ARCH=$(go env GOARCH); curl -sSL -o cmctl.tar.gz https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cmctl-$OS-$ARCH.tar.gz
tar xzf cmctl.tar.gz
sudo mv cmctl /usr/local/bin

Ensure that all the certificate-manager pods within the cert-manager namespace are up and running correctly. Check the logs for further verification.
Use cmctl to renew certificate manually.

➜ kubectl get certificate -n hashicorp

NAME                             READY   SECRET                           AGE
vault-service-cluster-zone-tls   True    vault-service-cluster-zone-tls   686d

➜ cmctl renew vault-service-cluster-zone-tls -n hashicorp

➜ kubectl get certificaterequest -n hashicorp
NAME                              READY   AGE
vault-service-cluster-zone-tls         False    10s

Upgrade step 1.5.5 -> 1.7.1
Before running reckoner plot you must upgrade the apiVersion in the status.storedVersions.
BEFORE running this, ensure you backup these two objects below at the very least. https://cert-manager.io/docs/tutorials/backup/
> kc get clusterissuers <issuers> -o yaml > clusterissuers-backup.yaml
 > kc get certificates <cert> -o yaml -n blah > cert-backup.yaml

On your local machine run the below command to upgrade the apiVersions stored:
cmctl upgrade migrate-api-version --qps 5 --burst 10

A successful run of the migrate command looks like:
cmctl upgrade migrate-api-version --qps 5 --burst 10
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Found 6 resource types that require migration:
 - certificates.cert-manager.io (Certificate)
 - certificaterequests.cert-manager.io (CertificateRequest)
 - issuers.cert-manager.io (Issuer)
 - clusterissuers.cert-manager.io (ClusterIssuer)
 - orders.acme.cert-manager.io (Order)
 - challenges.acme.cert-manager.io (Challenge)
Migrating "Certificate" objects in group "cert-manager.io" - this may take a while (started at 21:36:14)...
 2 resources to migrate...
 Successfully migrated 2 Certificate objects in 1s
Migrating "CertificateRequest" objects in group "cert-manager.io" - this may take a while (started at 21:36:15)...
 8 resources to migrate...
 Successfully migrated 8 CertificateRequest objects in 4s
Migrating "Issuer" objects in group "cert-manager.io" - this may take a while (started at 21:36:18)...
 1 resources to migrate...
 Successfully migrated 1 Issuer objects in 1s
Migrating "ClusterIssuer" objects in group "cert-manager.io" - this may take a while (started at 21:36:18)...
 1 resources to migrate...
 Successfully migrated 1 ClusterIssuer objects in 1s
Migrating "Order" objects in group "acme.cert-manager.io" - this may take a while (started at 21:36:19)...
 7 resources to migrate...
 Successfully migrated 7 Order objects in 2s
Migrating "Challenge" objects in group "acme.cert-manager.io" - this may take a while (started at 21:36:20)...
 0 resources to migrate...
 Successfully migrated 0 Challenge objects in 1s
Patching CRD resources to set "status.storedVersions" to "v1"...
Successfully migrated all cert-manager resource types. It is now safe to upgrade to cert-manager v1.7.

Please check to see if you get this type of error when you do a kubectl get orders or kubectl get certificaterequests. Search for whatever k8s objects you would need to access for your functional use of cert-manager.
Error from server: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

We may need to run what we call a kubectl patch shown below:
kubectl patch crd/certificaterequests.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl patch crd/orders.acme.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge

Now run:
$ reckoner plot reckoner.yaml --heading cert-manager

PLEASE go back through the Verification Step Section!!!!

I seem to be experiencing the same or a similar issue. I had to upgrade to the new ingress-nginx (coming from the old version which has no upgrade path except for simply deleting the old one and installing the new one), and noticed that my equally outdated cert-manager seemed to rely ingress-nginx. So I went for a clean slate (or so I thought) and fully removed both ingress-nginx and cert-manager (deleted all resources, CRDs, RBAC resources, and its namespace before proceeding). Except I now find myself unable to issue LetsEncrypt certificates and upon troubleshooting I run into this;

➜  ~ kubectl get challenge

Error from server: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

Would this mean that despite having deleted all CRDs and even the entire namespace there is still some resource, somewhere, that somehow is hanging around without a resource definition? If so, any idea as to how I can even get rid of these resources anymore, especially since they apparently didn't show up back when I purged the 2019 cert-manager installation from my cluster...? :sweat_smile:

Did you try patching the finalizers?

kubectl patch crd/certificaterequests.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl patch crd/orders.acme.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge

Obviously yours would be with the challenges not the orders/certificaterequests

...

Did you try patching the finalizers?

kubectl patch crd/certificaterequests.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl patch crd/orders.acme.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge

Obviously yours would be with the challenges not the orders/certificaterequests

The issue is not that I wasn't able to delete the resources, because they were gone according to the API (otherwise it would not have allowed me to delete the associated CRDs, either). The issue is that now I'm running a newer version of cert-manager and it is somehow still encountering v1alpha2 resources in my cluster even though they were all removed before proceeding with installing the new version of cert-manager.
Re-installing cert-manager 0.11 is also not an option, as Kubernetes 1.22 does not supply most of the APIs anymore that were used for cert-manager 0.11's resources.

Re-installing cert-manager 0.11 is also not an option, as Kubernetes 1.22 does not supply most of the APIs anymore that were used for cert-manager 0.11's resources.

You don't need cert-manager v0.11 to re-instate v1alpha2 API.
I'd suggest that you re-install cert-manager v1.5 that still understands v1alpha2 API, re-run the upgrade instructions as per the docs and re-attempt the upgrade

Re-installing cert-manager 0.11 is also not an option, as Kubernetes 1.22 does not supply most of the APIs anymore that were used for cert-manager 0.11's resources.

You don't need cert-manager v0.11 to re-instate v1alpha2 API.
I'd suggest that you re-install cert-manager v1.5 that still understands v1alpha2 API, re-run the upgrade instructions as per the docs and re-attempt the upgrade then.

Yup the cmctl upgrade... that I posted previously in my first comment should upgrade the underlying resources after moving back to 1.5.x. If it says that there are no resources to upgrade that means that you previously upgraded the api version but it could be possible some of the underlying objects(not the crds) were not upgraded properly. Which would cause you to likely have to run some kind of patch command to get the object in the correct state...

but it could be possible some of the underlying objects(not the crds) were not upgraded properly.

For the CRDs the cmctl upgrade command only removes the deprecated versions from the CRD statuses. If for some reason those versions weren't removed it wouldn't have been possible to upgrade at all as the v1.7 CRD specs don't contain the v1alpha2 versions- the upgrade command would fail (assuming that the CRDs too are being upgraded).
We've asked folks who work on kube apimachinery about the API deprecation and removal process and have been told that writing all cert-manger CRs to v1 to ensure any resources in etcd are stored at v1 + removing the deprecated API versions from CRD statuses is sufficient, so this is what cmctl upgrade command does and at the moment that is the recommended process to follow before upgrading to v1.7 . If there are any known edge cases, where extra commands need to be run, that would be good to know to either add to our release notes or incorporate into cmctl upgrade.

Re-installing cert-manager 0.11 is also not an option, as Kubernetes 1.22 does not supply most of the APIs anymore that were used for cert-manager 0.11's resources.

You don't need cert-manager v0.11 to re-instate v1alpha2 API. I'd suggest that you re-install cert-manager v1.5 that still understands v1alpha2 API, re-run the upgrade instructions as per the docs and re-attempt the upgrade then.

Thanks for that suggestion. I uninstalled cert-manager 1.7 via Helm and removed its namespace, and installed cert-manager 1.5.
➜  ~ kubectl get challenge
Error from server: conversion webhook for acme.cert-manager.io/v1alpha2, Kind=Challenge failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": x509: certificate signed by unknown authority
➜  ~ kubectl get challenge --insecure-skip-tls-verify
Error from server: conversion webhook for acme.cert-manager.io/v1alpha2, Kind=Challenge failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": x509: certificate signed by unknown authority
➜  ~ cmctl upgrade migrate-api-version
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

And upon uninstalling 1.5 and installing 1.7 again I am once again greeted with the familiar
➜  ~ kubectl get challenge
Error from server: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

@RobinJ1995 did you find a solution to your problem? I'm also struggling with the exact same issue.

My issue is not yet resolved as none of the suggested solutions worked,
unfortunately. How did you manage to clean up this dangling challenge?
On Thu 31 Mar 2022, 9:31 AM mwhaubold, @.***> wrote:

@RobinJ1995 https://github.com/RobinJ1995 if you get back here I wanted
to share what our problem was.  After cleaning that one up cert-manager is
working.
—
Reply to this email directly, view it on GitHub
https://github.com/cert-manager/cert-manager/issues/4900#issuecomment-1084200348,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXSJF5BLGX2HCRSBRCW43TVCVID7ANCNFSM5PIALCEA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @RobinJ1995 in the cert-manager logs we recognized references to a namespace which was not listed under kubectl get ns. So we went on creating this "empty" namespace. In this "empty" namespace we created an issuer (the name must match the one referenced in the dangling challenge), which then created the challenge. Then we could finally list and delete that challenge. After that the whole process from certificate --> certificate request --> order --> challenge went smoothly for our other namespaces. It feels like this one dangling challenge, which could not be created, blocked the creation of new challenges.
We needed to have the cert-manager version 1.5.5 running to understand the old apiVersion of that dangling challenge.
I hope that helps!

So in the end I ended up installing 1.5.5 which did end up just working immediately, and I can confirm that there are actually no dangling resources to be seen...
➜  ~ kubectl get challenge --all-namespaces
No resources found

So at this stage, I'm out of ideas, but I have a working setup, just with cert-manager 1.5 instead of 1.7. I can only assume that there is actually a bug in 1.7 that is causing this, as 1.5 works and does not indicate any dangling resources what so ever, yet 1.7 does not.
I also ran cmctl again just to confirm that it still says there is no upgrade work to be performed;
➜  ~ cmctl upgrade migrate-api-version
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

I'd like to upgrade to newer cert-manager versions at some stage, but right now this doesn't seem possible.

So in the end I ended up installing 1.5.5 which did end up just working immediately, and I can confirm that there are actually no dangling resources to be seen...

➜  ~ kubectl get challenge --all-namespaces

No resources found

So at this stage, I'm out of ideas, but I have a working setup, just with cert-manager 1.5 instead of 1.7. I can only assume that there is actually a bug in 1.7 that is causing this, as 1.5 works and does not indicate any dangling resources what so ever, yet 1.7 does not.
I also ran cmctl again just to confirm that it still says there is no upgrade work to be performed;

➜  ~ cmctl upgrade migrate-api-version

Checking all CustomResourceDefinitions have storage version set to "v1"

All CustomResourceDefinitions have "v1" configured as the storage version.

Looking for CRDs that contain resources that require migrating to "v1"...

Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

I'd like to upgrade to newer cert-manager versions at some stage, but right now this doesn't seem possible.
Also thank you @mwhaubold for sharing the solution that worked for you, it's appreciated :)

Did you see my replies earlier about patching finalizers of the resource its complaining about when you go to 1.7?

In case it helps someone else. I hit this even though I ran the migrate steps. It turns out there were some certificate requests and orders left out there which still had the old version. The fix was to roll back to 1.5, delete the certificate requests and orders (which forces them to upgrade when they are regenerated), then roll forward again.

I think we might need to investigate this 👀

PROBLEM
In case this helps anyone, we were seeing the following in the cert-manager logs after upgrading (1.5.3 -> 1.8.0):
failed to list *v1.Order: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2
Failed to watch *v1.Order: failed to list *v1.Order: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

Running cmctl upgrade migrate-api-version --qps 5 --burst 10 showed that everything was fine:
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

Running the finalizer patches below also made no changes:
kubectl patch crd/certificaterequests.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl patch crd/orders.acme.cert-manager.io -p '{"metadata":{"finalizers":[]}}' --type=merge

CAUSE
Turns out we had a ton of leftover/old certificate requests that had the following in them as found with kubectl describe certificaterequests -A (Many that did not have "Approved" as True.):
 Owner References:
    API Version:           cert-manager.io/v1alpha2

And also kubectl describe orders -A resulted in the same amount of orders that had the same v1alpha2 in them.
RESOLUTION
We resolved the issue by:

Downgrade to cert-manager 1.5.5 (we use the Helm chart)
Run cmctl upgrade migrate-api-version --qps 5 --burst 10
Delete all the old certificaterequest and order records with kubectl delete certificaterequest -n NAMESPACE ID1 ID2 and kubectl delete order -n NAMESPACE ID1 ID2 (We deleted anything over 90 days or that had v1alpha2.)
Install cert-manager 1.8.0
Check logs

So in the end I ended up installing 1.5.5 which did end up just working immediately, and I can confirm that there are actually no dangling resources to be seen...
➜  ~ kubectl get challenge --all-namespaces
No resources found

So at this stage, I'm out of ideas, but I have a working setup, just with cert-manager 1.5 instead of 1.7. I can only assume that there is actually a bug in 1.7 that is causing this, as 1.5 works and does not indicate any dangling resources what so ever, yet 1.7 does not.
I also ran cmctl again just to confirm that it still says there is no upgrade work to be performed;
➜  ~ cmctl upgrade migrate-api-version
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

I'd like to upgrade to newer cert-manager versions at some stage, but right now this doesn't seem possible.
Also thank you @mwhaubold for sharing the solution that worked for you, it's appreciated :)

I faced the same issue @RobinJ1995 .
We upgrade to 1.8. and weren't able to issue new certificates.
I tried to patch the CRDs and run the cmctl upgrade like mentioned.
After downgrading to 1.5 and running cmctl upgrade migrate-api-version it prompted with Nothing to do, as well as patching the CRDs. I still faced the conversion from acme.cert-manager.io/v1alpha2 issue.
I figured based on the conversation above we had an issue on one dangling challenge too.  There were no challenges displayed even though we had some open certificate requests and orders.
In our case I knew which namespace was problematic, as I wasn't able to list the challenges in the particular namespace.
The same convert problem with v1alpha2 was prompted also on --all-namespace.
In my case, I knew which namespace was problematic so this might not apply to the issue you are facing Robin.
After running
kubectl get challenge -n <namespace>

> failed to list *v1.Challenge: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

I was able to resolve this by installing the old CRDs (from v1.4.0) while being on Version 1.5 of cert-manager  via crds-managed-separately.
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.4.0/cert-manager.crds.yaml

After installing the old CRDs the dangling challenge was finally displayed (it was pretty old... 🙄).
And I was able to  remove it simply via
kubectl  delete challenge <challange-name> -n <namespace>

After the old challenges was removed new challenges were immediatly issued, which now also use the correct v1 CRDs.
I hope the upgrade will now work for us smoothly.
Maybe this will helps someone.
Cheers guys for the help so far 💚

So in the end I ended up installing 1.5.5 which did end up just working immediately, and I can confirm that there are actually no dangling resources to be seen...
➜  ~ kubectl get challenge --all-namespaces
No resources found

So at this stage, I'm out of ideas, but I have a working setup, just with cert-manager 1.5 instead of 1.7. I can only assume that there is actually a bug in 1.7 that is causing this, as 1.5 works and does not indicate any dangling resources what so ever, yet 1.7 does not.
I also ran cmctl again just to confirm that it still says there is no upgrade work to be performed;
➜  ~ cmctl upgrade migrate-api-version
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

I'd like to upgrade to newer cert-manager versions at some stage, but right now this doesn't seem possible.
Also thank you @mwhaubold for sharing the solution that worked for you, it's appreciated :)

I faced the same issue @RobinJ1995 .
We upgrade to 1.8. and weren't able to issue new certificates.
I tried to patch the CRDs and run the cmctl upgrade like mentioned. After downgrading to 1.5 and running cmctl upgrade migrate-api-version it prompted with Nothing to do, as well as patching the CRDs. I still faced the conversion from acme.cert-manager.io/v1alpha2 issue.
I figured based on the conversation above we had an issue on one dangling challenge too. There were no challenges displayed even though we had some open certificate requests and orders.
In our case I knew which namespace was problematic, as I wasn't able to list the challenges in the particular namespace. The same convert problem with v1alpha2 was prompted also on --all-namespace. In my case, I knew which namespace was problematic so this might not apply to the issue you are facing Robin.
After running
kubectl get challenge -n <namespace>

> failed to list *v1.Challenge: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

I was able to resolve this by installing the old CRDs (from v1.4.0) while being on Version 1.5 of cert-manager via crds-managed-separately.
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.4.0/cert-manager.crds.yaml

After installing the old CRDs the dangling challenge was finally displayed (it was pretty old... roll_eyes). And I was able to remove it simply via
kubectl  delete challenge <challange-name> -n <namespace>

After the old challenges was removed new challenges were immediatly issued, which now also use the correct v1 CRDs. I hope the upgrade will now work for us smoothly.
Maybe this will helps someone. Cheers guys for the help so far green_heart

This one helped me. Thanks @MarkWarneke

Hi @MarkWarneke

I also downgrade the cert-managet to v1.5.5 and then again downgrade by installing old CRD's (from v1.4.0) while being on Version 1.5 of cert-manager via crds-managed-separately.
The output of applying CRD's of v1.4.0
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.4.0/cert-manager.crds.yaml
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io configured
Warning: Detected changes to resource clusterissuers.cert-manager.io which is currently being deleted.
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io configured
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io configured

and when trying to list old dangling clusterissuers resources. I am getting below error
kubectl get clusterissuers -A
Error from server: conversion webhook for cert-manager.io/v1alpha2, Kind=ClusterIssuer failed: Post "https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s": x509: certificate signed by unknown authority

So in the end I ended up installing 1.5.5 which did end up just working immediately, and I can confirm that there are actually no dangling resources to be seen...
➜  ~ kubectl get challenge --all-namespaces
No resources found

So at this stage, I'm out of ideas, but I have a working setup, just with cert-manager 1.5 instead of 1.7. I can only assume that there is actually a bug in 1.7 that is causing this, as 1.5 works and does not indicate any dangling resources what so ever, yet 1.7 does not.
I also ran cmctl again just to confirm that it still says there is no upgrade work to be performed;
➜  ~ cmctl upgrade migrate-api-version
Checking all CustomResourceDefinitions have storage version set to "v1"
All CustomResourceDefinitions have "v1" configured as the storage version.
Looking for CRDs that contain resources that require migrating to "v1"...
Nothing to do. cert-manager CRDs do not have "status.storedVersions" containing old API versions. You may proceed to upgrade to cert-manager v1.7.

I'd like to upgrade to newer cert-manager versions at some stage, but right now this doesn't seem possible.
Also thank you @mwhaubold for sharing the solution that worked for you, it's appreciated :)

I faced the same issue @RobinJ1995 .
We upgrade to 1.8. and weren't able to issue new certificates.
I tried to patch the CRDs and run the cmctl upgrade like mentioned. After downgrading to 1.5 and running cmctl upgrade migrate-api-version it prompted with Nothing to do, as well as patching the CRDs. I still faced the conversion from acme.cert-manager.io/v1alpha2 issue.
I figured based on the conversation above we had an issue on one dangling challenge too. There were no challenges displayed even though we had some open certificate requests and orders.
In our case I knew which namespace was problematic, as I wasn't able to list the challenges in the particular namespace. The same convert problem with v1alpha2 was prompted also on --all-namespace. In my case, I knew which namespace was problematic so this might not apply to the issue you are facing Robin.
After running
kubectl get challenge -n <namespace>

> failed to list *v1.Challenge: request to convert CR from an invalid group/version: acme.cert-manager.io/v1alpha2

I was able to resolve this by installing the old CRDs (from v1.4.0) while being on Version 1.5 of cert-manager via crds-managed-separately.
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.4.0/cert-manager.crds.yaml

After installing the old CRDs the dangling challenge was finally displayed (it was pretty old... 🙄). And I was able to remove it simply via
kubectl  delete challenge <challange-name> -n <namespace>

After the old challenges was removed new challenges were immediatly issued, which now also use the correct v1 CRDs. I hope the upgrade will now work for us smoothly.
Maybe this will helps someone. Cheers guys for the help so far 💚


[REQUEST] Testing other Network Adapters eg. ASIX

The DUB-E100 can be hard to find in the correct revision, particularly in Australia.
As such I went hunting for other alternatives. In the log files copied off the unit in green screen I saw reference to the other ethernet drivers and the usblauncher tool in charge of associating drivers to USB devices.
I'd recently updated my firmware to 1367 so still had the firmware pack for that. A grep on the entire SD card revealed usblauncher was in the efs-system.img files. I didn't have much luck finding any way to mound this file as a loop filesystem, however eventually figured I could just look at it with a hex editor. It's pretty easy to manually extract files, just search for \x00\x00 and there it is in plain text after a bit of hex muck (presuably file modes etc). Copy-paste out the right bit and there's the file:
usblauncher.lua
--[[
-- usblauncher replaces: mcd for mounting filesystems on USB devices;
-- enum-devices and enum-usb for starting USB drivers;
-- usbpub for publishing device, driver, and mount PPS objects
os.execute'slay mcd'
os.execute'slay enum-devices'
os.execute'slay enum-usb'
os.execute'slay usbpub'
--]]

--[[
Host_Stack = {
	cmd  = 'io-usb -cvvv  -domap4430-mg ioport=0x4a0ab000,irq=124,verbose';
	path = '/dev/otg/io-usb';
 }

Device_Stack = {
	cmd  = 'io-usb-dcd -vvv -d usbumass-omap4430-musbmhdrc ioport=0x4a0ab000,irq=124,verbose';
	path = '/dev/otg/io-usb-dcd';
}
--]]
--[[
MirrorLink = {
	version = 0x0101;
	vendor_id = 0xABAB;
	blacklist = {
		{ vid = 0x0781; did = 0x74e0 }; -- SanDisk Sansa Fuze+
		{ vid = 0x0951; did = 0x1624 }; -- Kingston DataTraveler G2
		{ vid = 0x05ac;              }; -- any Apple device
	};
	timeout = 2000;
	ignore  = false;
	stall_reset = false;
}
--]]

------------------------------------------------------------------------------

-- D-Link DUB-E100 USB Dongles
device(0x2001, 0x3c05) {
    driver"/etc/scripts/extnet.sh -oname=en,lan=0,busnum=$(busno),devnum=$(devno),phy_88772=0,phy_check,wait=60,speed=100,duplex=1,ign_remove,path=$(USB_PATH) /lib/dll/devnp-asix.so /dev/io-net/en0";
    removal"ifconfig en0 destroy";
};

device(0x2001, 0x1a02) {
    driver"/etc/scripts/extnet.sh -oname=en,lan=0,busnum=$(busno),devnum=$(devno),phy_88772=0,phy_check,wait=60,speed=100,duplex=1,ign_remove,path=$(USB_PATH) /lib/dll/devnp-asix.so /dev/io-net/en0";
    removal"ifconfig en0 destroy";
};

-- SMSC9500
device(0x0424, 0x9500) {
	-- the extnet.sh script does an exec dhcp.client at the bottom, then usblauncher can slay the dhcp.client when the dongle is removed
	driver"/etc/scripts/extnet.sh -olan=0,busnum=$(busno),devnum=$(devno),path=$(USB_PATH) /lib/dll/devn-smsc9500.so /dev/io-net/en0";
	removal"ifconfig en0 destroy";
};

-- Germaneers LAN9514
device(0x2721, 0xec00) {
        -- the extnet.sh script does an exec dhcp.client at the bottom, then usblauncher can slay the dhcp.client when the dongle is removed
        driver"/etc/scripts/extnet.sh -olan=0,busnum=$(busno),devnum=$(devno),path=$(USB_PATH) /lib/dll/devn-smsc9500.so /dev/io-net/en0";
        removal"ifconfig en0 destroy";
};

-- ASIX AX88178
device(0x0b95, 0x1780) {
    driver"/etc/scripts/extnet.sh -oname=en,lan=0,busnum=$(busno),devnum=$(devno),wait=60,ign_remove,path=$(USB_PATH) /lib/dll/devnp-asix.so /dev/io-net/en0";
    removal"ifconfig en0 destroy";
};

-- ASIX AX88179
device(0x0b95, 0x1790) {
    driver"/etc/scripts/extnet.sh -oname=en,lan=0,busnum=$(busno),devnum=$(devno),wait=60,ign_remove,path=$(USB_PATH) /lib/dll/devnp-asix.so /dev/io-net/en0";
    removal"ifconfig en0 destroy";
};

Looks to me that ASIX AX88178 and AX88179 should both be equivalent to the DUB-E100, they run the same script and target the same en0 interface - they're also a lot easier to buy. I picked up a AX88179 on amazon with 2 day shipping for only ~ $20, it turned up with the correct chip vid/pid ( https://www.amazon.com.au/gp/product/B00MYTSN18/ref=ppx_yo_dt_b_asin_title_o02_s00 ).
Plugging it into the unit, I can see it appears to be enumerated correctly in the logs copied off from green screen. Also, under green menu mmx_prod/ip-setting_prod it appears as en0 with the expected ip address - <IP_ADDRESS>
I tried connecting it my my laptop which is using a different ASIX usb/ethernet device (AX88179). With my laptop set to dhcp I don't get any ip address. With my laptop set to the suggested ip address <IP_ADDRESS> I cannot ping or telnet to <IP_ADDRESS>
In that same ip address green screen I selected the option to enable dhcp mode and connected the car to a router instead to provide it an ip address - the car's ip address then only ever shows <IP_ADDRESS> - it's not getting an ip address at all. I tried multiple tested ethernet cables, no change.
The lights on the AX88179 show it's connected, has a couple of blinks to show activity, but not getting any throughput.
Plugging the AX88179 into my desktop and using the same adapter on laptop, it works fine - manually set ip addresses on both ends and it pings just fine - so it looks like the usb ethernet does work, just not with the car.
Have you ever seen anything like this with a DUB-E100?

Good news: AX88179 adapters work
Hunting through my cupboard I found an old USB hub / Ethernet adaptor that just happened to also be a AX88179. Tried it on the car, with my other AX88179 adapter on the laptop, set the laptop to static IP and straight away the ping <IP_ADDRESS> went through! The telnet to 123 also works :-)
Note: make sure the car ignition is on, but engine not running. I think on some/most previous attempts I just turned the screen on manually, but didn't turn the car on.
I just used a normal Ethernet cable directly between the two USB Ethernet adaptors, they did not need a cross-over cable.
Once it was working, I swapped the two USB Ethernets over again, so the old one on my laptop and the new one I got from Amazon connected to car - this also worked fine now.
So the failure I saw in the top post might have been from the other USB ethernet I previously used on my laptop, or simply from not having the car ignition on.
AX88179 adapters have become common online as they're natively supported on Nintendo switch, so many/most usb3 adapters advertised as supporting the switch should be this chip. Either way, the Amazon link I noted in the top post explicitly listed this chip was in use.

Good news: AX88179 adapters work
Hunting through my cupboard I found an old USB hub / Ethernet adaptor that just happened to also be a AX88179. Tried it on the car, with my other AX88179 adapter on the laptop, set the laptop to static IP and straight away the ping <IP_ADDRESS> went through! The telnet to 123 also works :-)
Note: make sure the car ignition is on, but engine not running. I think on some/most previous attempts I just turned the screen on manually, but didn't turn the car on.
I just used a normal Ethernet cable directly between the two USB Ethernet adaptors, they did not need a cross-over cable.
Once it was working, I swapped the two USB Ethernets over again, so the old one on my laptop and the new one I got from Amazon connected to car - this also worked fine now.
So the failure I saw in the top post might have been from the other USB ethernet I previously used on my laptop, or simply from not having the car ignition on.
AX88179 adapters have become common online as they're natively supported on Nintendo switch, so many/most usb3 adapters advertised as supporting the switch should be this chip. Either way, the Amazon link I noted in the top post explicitly listed this chip was in use.

My boy has a Nintendo switch adaptor, 🤔 but I don’t have the password to 913, so doubt I could tell you if it works or not

My boy has a Nintendo switch adaptor, 🤔 but I don’t have the password to 913, so doubt I could tell you if it works or not

Tried my boys official switch adaptor, telnet said couldn’t connect

Tried my boys official switch adaptor, telnet said couldn’t connect

Tried my boys official switch adaptor, telnet said couldn’t connect

It would be worth checking the adapter on computer / device manager to see what USB vid/pid it is.

Tried my boys official switch adaptor, telnet said couldn’t connect

It would be worth checking the adapter on computer / device manager to see what USB vid/pid it is.

It says it’s an AX88772A if that’s what you mean, but I couldn’t find a driver for it (only have a windows 7 pc available to me at the mo)

It says it’s an AX88772A if that’s what you mean, but I couldn’t find a driver for it (only have a windows 7 pc available to me at the mo)

Ah, AX88772A is the older chipset not directly supported by the firmware - however this is the same chip as the DUB-E100 meaning this adapter can often have its vid/pid changed to match the DUB-E100 which will then work. I'm not sure if it'll still work on the Switch with the changed vid/pid though...
https://www.digital-eliteboard.com/threads/how-to-changing-usb-to-ethernet-adapter-vid-pid-to-match-d-link-dub-e100.496271/

Ah, AX88772A is the older chipset not directly supported by the firmware - however this is the same chip as the DUB-E100 meaning this adapter can often have its vid/pid changed to match the DUB-E100 which will then work. I'm not sure if it'll still work on the Switch with the changed vid/pid though...
https://www.digital-eliteboard.com/threads/how-to-changing-usb-to-ethernet-adapter-vid-pid-to-match-d-link-dub-e100.496271/

I've checked (with grep) all the firmware packs I've got access to - it looks like all current MMX2 firmware should support these two ASIX ethernet adapters:

Firmware
ASIX

Audi (A3) MHI2_ER_AU37x_P5089 MU1326 MMX2
yes

Audi (A3) MHI2_ER_AU37x_P5089 MU1326 MMX2
yes

Audi (A4-A5-Q5-Q7) MHI2_ER_AUG22_K3346 MU1438 MMX2
yes

Audi (A4-A5-Q5-Q7) MHI2_ER_AUG22_K3346 MU1438 MMX2
yes

Audi (A6-A7) MHI2_ER_AU57x_K3663 MU1425 MMX2
yes

Audi (A6-A7) MHI2_ER_AU57x_K3663 MU1425 MMX2
yes

Audi (Q2) MHI2_ER_AU276_P5088 MU1325 MMX2
yes

Audi (Q2) MHI2_ER_AU276_P5088 MU1325 MMX2
yes

Audi (R8) MHI2_ER_AU62x_P5099 MU1340 MMX2
yes

Audi (R8) MHI2_ER_AU62x_P5099 MU1340 MMX2
yes

Audi (TT) MHI2_ER_AU43x_P5098 MU1339 MMX2
yes

Audi (TT) MHI2_ER_AU43x_P5098 MU1339 MMX2
yes

Seat MHI2_ER_SEG11_P4708 MU1409 MMX2
yes

Seat MHI2_ER_SEG11_P4708 MU1409 MMX2
yes

Skoda MHI2_ER_SKG11_K3343 MU1433 MMX2
yes

Skoda MHI2_ER_SKG11_K3343 MU1433 MMX2
yes

Skoda MHI2_ER_SKG13_P4526 MU1440 MMX2
yes

Skoda MHI2_ER_SKG13_P4526 MU1440 MMX2
yes

VW MHI2_ER_VWG11_K3332 MU1187 MMX2
yes

VW MHI2_ER_VWG11_K3332 MU1187 MMX2
yes

VW MHI2_ER_VWG11_K3342 MU1427 MMX2
yes

VW MHI2_ER_VWG11_K3342 MU1427 MMX2
yes

VW MHI2_ER_VWG13_P4521 MU1367 mmx2
yes

VW MHI2_ER_VWG13_P4521 MU1367 mmx2
yes

The only firmware packs I have that don't support it are MMX1 - looking manually at these it appears they literally only support the two versions of D-Link DUB-E100 (ven=2001, dev=3c05 or ven=2001, dev=1a02).

Firmware
ASIX

Audi (A3) MHIG_EU_AU_K1549 MU0404 MMX1
no

Audi (A3) MHIG_EU_AU_K1549 MU0404 MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/EU MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/EU MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/RW MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/RW MMX1
no

VW MHIG_EU_VW_K1550 MU0407 MMX1
no

VW MHIG_EU_VW_K1550 MU0407 MMX1
no

I've checked (with grep) all the firmware packs I've got access to - it looks like all current MMX2 firmware should support these two ASIX ethernet adapters:

Firmware
ASIX

Audi (A3) MHI2_ER_AU37x_P5089 MU1326 MMX2
yes

Audi (A3) MHI2_ER_AU37x_P5089 MU1326 MMX2
yes

Audi (A4-A5-Q5-Q7) MHI2_ER_AUG22_K3346 MU1438 MMX2
yes

Audi (A4-A5-Q5-Q7) MHI2_ER_AUG22_K3346 MU1438 MMX2
yes

Audi (A6-A7) MHI2_ER_AU57x_K3663 MU1425 MMX2
yes

Audi (A6-A7) MHI2_ER_AU57x_K3663 MU1425 MMX2
yes

Audi (Q2) MHI2_ER_AU276_P5088 MU1325 MMX2
yes

Audi (Q2) MHI2_ER_AU276_P5088 MU1325 MMX2
yes

Audi (R8) MHI2_ER_AU62x_P5099 MU1340 MMX2
yes

Audi (R8) MHI2_ER_AU62x_P5099 MU1340 MMX2
yes

Audi (TT) MHI2_ER_AU43x_P5098 MU1339 MMX2
yes

Audi (TT) MHI2_ER_AU43x_P5098 MU1339 MMX2
yes

Seat MHI2_ER_SEG11_P4708 MU1409 MMX2
yes

Seat MHI2_ER_SEG11_P4708 MU1409 MMX2
yes

Skoda MHI2_ER_SKG11_K3343 MU1433 MMX2
yes

Skoda MHI2_ER_SKG11_K3343 MU1433 MMX2
yes

Skoda MHI2_ER_SKG13_P4526 MU1440 MMX2
yes

Skoda MHI2_ER_SKG13_P4526 MU1440 MMX2
yes

VW MHI2_ER_VWG11_K3332 MU1187 MMX2
yes

VW MHI2_ER_VWG11_K3332 MU1187 MMX2
yes

VW MHI2_ER_VWG11_K3342 MU1427 MMX2
yes

VW MHI2_ER_VWG11_K3342 MU1427 MMX2
yes

VW MHI2_ER_VWG13_P4521 MU1367 mmx2
yes

VW MHI2_ER_VWG13_P4521 MU1367 mmx2
yes

The only firmware packs I have that don't support it are MMX1 - looking manually at these it appears they literally only support the two versions of D-Link DUB-E100 (ven=2001, dev=3c05 or ven=2001, dev=1a02).

Firmware
ASIX

Audi (A3) MHIG_EU_AU_K1549 MU0404 MMX1
no

Audi (A3) MHIG_EU_AU_K1549 MU0404 MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/EU MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/EU MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/RW MMX1
no

Skoda MHIG_EU_SK_K1552 MU0411/RW MMX1
no

VW MHIG_EU_VW_K1550 MU0407 MMX1
no

VW MHIG_EU_VW_K1550 MU0407 MMX1
no

Should we merge this info into a Wiki page or FAQ?

Should we merge this info into a Wiki page or FAQ?

I was wondering about how much usb-eth documentation we should add. We don't have login details to share with people anyway so there's only so much we can provide...

I was wondering about how much usb-eth documentation we should add. We don't have login details to share with people anyway so there's only so much we can provide...

We could take the list of possible interfaces to show alternatives maybe. Or we just put this into Wiki -> Research.

We could take the list of possible interfaces to show alternatives maybe. Or we just put this into Wiki -> Research.

Yeah for sure, the ASIX details would be worth listing alongside the DUB

Yeah for sure, the ASIX details would be worth listing alongside the DUB

Investigation is no in Wiki: Alternative network adapters


Add support for Font Awesome pro icons

Description
This was suggested by @flowdee on Twitter, it would be nice to be able to support Font Awesome icons for Pro users.
I currently don't use Font Awesome pro so I wouldn't be able to test this. Also, the Font Awesome licence states that the icons shouldn't be included in open source (although they are looking into how this could be possible).
Possible implementation
I'm not really sure how this would work as it needs to include the icons in the package somehow. 🤔

What would it take to make this happen? Would it be possible to stub it out so that we could drop in the FontAwesome Pro SVG icon folders (like "light") into the View folder and reference them from a published config? It appears we would also need to add  fill="currentColor" to all of the icons as well.

Apologies for the delayed reply, I'm currently on holiday and not checking notifications much.
I've just bought a Font Awesome Pro licence so that I can try and add support to this in a future version of Blade Font Awesome. :+1:
I agree that some sort of stubbed format would be best. Personally I was thinking of basically adding a command that allows you to download the latest version of Pro using your licence key and add it to your storage/app directory. But I'm open for opinions on this. 👌🏻
Something such as:
php artisan blade-fontawesome:update-pro [key]

I honestly think that it shouldn't sit in storage/app since it's a resource and would better fit in resources/. You can make it resources/vendor/[your-package-name] as it is actively being used by Horizon, Telescope, etc.
There would be the only clean way (i know when dealing with paid stuff) a command that'd add the pro icons locally in the project. 🤷

Yes, it should be in resources @rennokki. Thanks for the heads up. :+1: I will work on this when I'm back from holiday (the end of this week).

Right, I've looked into the GraphQL and it looks like we can't do it through that. 😬 I was hoping that we could generate a token via https://api.fontawesome.com/token, and then append it to the following download URL:
https://downloads.fontawesome.com/releases/v5.14.0/fontawesome-pro-5.14.0-desktop.zip?token=${token}
However, it looks like that doesn't work (probably because the token doesn't have that scope).

The only other way I can see to do it is to basically make 2 calls as follows:

Call to https://fontawesome.com/api/sessions with username and password
Call to https://fontawesome.com/releases/5.14.0/desktop/download with the cookie returned by the first call

However, I'm not really a fan of keeping the username and password in the .env or environment, so perhaps it would be better to use flags for the command? 🤔

Any thoughts by people would be welcome. 👍🏻

@owenvoke I have researched it a bit too and found out we got a way to do this using a bearer token, but somehow the download link is not available via the GraphQL API.
To explain it to anyone coming here, you can get a bearer token from the Font Awesome account page: https://fontawesome.com/account#api-tokens (as described here: https://fontawesome.com/how-to-use/graphql-api/auth/token-endpoint)
When trying to make an authorized request, you can do so as it is described here:
$ curl -H "Content-Type: application/json" \
-H "Authorization: Bearer 123.abc.467def" \
-d '{ "query": "{ me { kits { name } } }" }' \
https://api.fontawesome.com

From the Release endpoint, you can then get the download object: https://fontawesome.com/how-to-use/graphql-api/objects/release, but I assume the object does not have a download link.
Proposal
Using symfony/process to initiate an NPM process and run the npm install (without --save) to download the package, then copy the icons from node_modules accordingly.

Unless Font Awesome have a way to retrieve the URL, I think the command with username and password might be easiest. Using symfony/process to pass off to npm seems a bit weird and also would require npm to be installed (albeit most Laravel developers do have it anyway).
However, if there is an API way, then I'd definitely rather that. Both for security, and ease of use. It's a shame you can't just generate a token and use that (as far as I can tell), but oh well. 🤷🏻

How about copy the icons from node_modules/@fortawesome/fontawesome-pro/svgs?
There could be a command like artisan blade-icons:font-awesome:upgrade-pro {directory?} that copies the SVGs from the node_modules into the vendor dir.
This command could be part of deployment after yarn install.
I think that's the easiest way. The dev can use the FA package like normal and use the default npm auth. And this package only copies Icons from the node modules into it's own directories or somewhere in the storage or even resources directory.

@owenvoke Good job on this! I think that the path name should contain the package name. 🤷

Just bumped into this, I'd love to use Font Awesome Pro with Blade Icons! :)

@Gummibeer, that is a possibility. I've created an example of this here:
https://gist.github.com/owenvoke/869178250e7b823cd18cd70b4393fa78

That's my point - I'm longer tied to this package version and can use my default behavior and also use the FA if needed with class.

Sounds good 👍🏻 I'll implement that in a PR later.

Right, the PR is live. I'm just planning on rewriting the bin/compile.sh as a PHP action that can be run on the pro directories as well. But going to do that when I have some free time tomorrow. 👍🏻 Hope that works for everyone?

Perfect solution, can't see any drawback 👍
Thanks for that!

Released in v1.4.0 🥳

Thanks @owenvoke!
I noticed the Duotone icons are not working as expected. They are displayed but they don't have the different colors that actually make them 'duotone'. Do we need to define our own classes .fa-primary and .fa-secondary?

@adddz, yes, there isn't any styling by default and due to the way they work, they don't seem to work that great (I'd never used duotone icons before). 😬
Looks like you'd need to apply some sort of style like <x-fad-fill-drip class="custom-class"/> and then specify the .custom-class .fa-primary / .custom-class .fa-secondary styles. sigh
If you can think of a better way of implementing this, let me know. 👍🏻

@owenvoke Hey Owen, I just spent hours debugging my Laravel app because the loading time of an empty route was very slow, around 600-700ms. I just couldn't understand why. I started copy pasting the folders to a fresh laravel project, one by one and finally found out the issue.
When I copied the resources folder of my app into the fresh app, the fresh app became slow as well.
Guess what my friend, it was the icons folder, with the thousands of FontAwesome Pro icons inside.
To be honest I have no idea why that's actually slowing down everything. Does the framework load the content of the resources folder on startup? I had to remove it. The loading time went down to ~50ms without the icons folder.
Hopefully you'll shed a light on this. :)

Hi @adddz, this is a performance issue with the underlying Blade Icons package. There's an issue open addressing the concerns, and how it could be resolved with a cache command (I think there is a PR open too).
https://github.com/blade-ui-kit/blade-icons/issues/71

Thank you so much @owenvoke. I really spent hours fixing this so I thought it could help someone. Hopefully it'll be fixed because it's almost unusable like this. Hopefully it'll get fixed soon. Thanks Owen! 😊

@owenvoke great job with the package! Made my buy Font Awesome! I noticed that @driesvints added option to enable/disable caching 2 days ago: https://github.com/blade-ui-kit/blade-icons/commit/3f6a0475a4b8b7009f8f238e52634577e6f41869
Thanks!

@aurawindsurfing here's the PR for that: https://github.com/blade-ui-kit/blade-icons/pull/118. Not that this is for disabling components, not caching. I'm still planning to add caching, probably with the cache command PR that's open atm.


Some Improvement Suggestions

Recommendations for Improvement

Using the ternary operator for s_arch_sys_d is unnecessary; it can be directly linked with apb4.pwdata, considering that enable port in the u_arch_sys_dfferc module is already connected (there're some similar issues).
https://github.com/oscc-ip/archinfo/blob/8ffae9bcc837e2db1810751154ad2c707e6dd292/rtl/apb4_archinfo.sv#L33-L41

It is recommended to use clock-edge style to avoid critical path issue. Additionally, it's advised not to always pull the pready signal high.
https://github.com/oscc-ip/archinfo/blob/8ffae9bcc837e2db1810751154ad2c707e6dd292/rtl/apb4_archinfo.sv#L63-L73
Below is an example from a Xilinx project.
https://github.com/Xilinx/systemctlm-cosim-demo/blob/3b1501c21487d265c3275a45d468a65b5d4f1989/apb_timer.v#L61-L92

Thanks for your issue! I will fix these clock gate enable signals issues in all IP repos in the next few days.


OCPBUGS-20564: CARRY: Add DOWNSTREAM_OWNERS

This should allow us to remove the carry and avoid merge conflicts on upstream OWNERS.

/cherry-pick release-4.14

/cherry-pick release-4.13

/cherry-pick release-4.12

/cherry-pick release-4.11

/jira cherry-pick release-4.14

/jira cherrypick release-4.14

/jira cherrypick OCPBUGS-20564

/jira cherrypick OCPBUGS-20564


Full mingw-w64 build

The remaining issue is the linkage with gtest.

https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gtest/PKGBUILD


refactor: moved css value tokenizer to new package

We are moving this to a different location. all PR note are fixed and committed there


oldtweetdeck locks my account after time

I'm using on Microsoft Edge Browser (123.0.2420.81 64bit) and I'm logged in on tweetdeck with two accounts. (Main is private, and other is public)
Yesterday my account(private one) has been locked, they says "Abnormal activity was detected so your account has been locked."
To unlock my account, I had to do a Arkose thing to prove I'm a human, not a robot.
and today it happend again a few minutes ago.
When this happened I left my browser logged in, disabled the window and used other applications (such as games) for a long time, maybe for 4 hours?
Maybe I should stop using tweetdeck for some days, until the reason of account lock is clarified or resolved.
If possible, please take care of this issue. Thank you for your great work.

check this: https://github.com/dimdenGD/OldTweetDeck/issues/213

I just re-checked the content. As some people assumed over there, I left one search tab open without realizing it and that might be the reason. I'll remove the search tab and try it as usual and if the same thing happens, I'll follow up with this post and report it.
If a search tab is almost certain to cause the account lockout, it may help many people by letting users to know it in Tweetdeck or automatically disabling it after a certain period of time...


[Fix bug 1119510] Fix search results going beyond scope CSS issue

Coverage remained the same at 93.0% when pulling c0a019015245fa0bf0eb2bf5e4617984cba35ea1 on akasantony:fix-search-css into 4a747df5f7a73bf7f1c95a8cf1efc2aa07ba4d29 on mozilla:master.


Increased build number to rerun

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

conda-forge-admin, please rerender

conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender


Parse error on type level multiplication

Here we go again... :)
I get this with HEAD of hlint.
Interestingly I'm not able to replicate this parse error with haskell-src-exts-1.17.1. Is it possible to hlint to report a parse error without haskell-src-exts failing?
This parses correctly:
{-# language TypeOperators #-}
type A = B - B

However this does not, I assume because of some confusion between the kind * and the multiplication operator.
{-# language TypeOperators #-}
type A = B * B

This also parses without a problem
{-# language TypeOperators #-}
type A = B Prelude.* B

Please can you explain what the bug is in HSE? I'm confused about where the actual problem is because of this sentence.

Interestingly I'm not able to replicate this parse error with haskell-src-exts-1.17.1. Is it possible to hlint to report a parse error without haskell-src-exts failing?

You can workaround the bug by passing -XHaskell98 which disables all extensions, and then just enables the ones you explicitly declare. For HSE, the issue is that the following file fails to parse:
{-# language TypeOperators, KindSignatures #-}
type A = B * B

But GHC seems to be able to parse it. Since -XNoKindSignatures alone doesn't solve it I guess there are other extensions that also enable kind signatures. @mpickering, does that look like an HSE issue?

If there is a file which GHC parses but HSE doesn't then it is an issue.

Raised upstream at https://github.com/haskell-suite/haskell-src-exts/issues/298.

Fixed in hlint-2.0.15.

Thanks!
On Tue, 12 Dec 2017, 14:25 Neil Mitchell<EMAIL_ADDRESS>wrote:

Closed #227 https://github.com/ndmitchell/hlint/issues/227.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ndmitchell/hlint/issues/227#event-1383632407, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA0U3O-jVyq5PnKnuAV7hgYvGByUadS-ks5s_oy5gaJpZM4HwAdW
.


[DH-490] Add ID to audit log entries

Added the ID of the new version to each entry in the audit log view responses.

Codecov Report

Merging #408 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #408   +/-   ##
========================================
  Coverage    95.94%   95.94%
========================================
  Files           79       79
  Lines         2835     2835
  Branches       244      244
========================================
  Hits          2720     2720
- Misses          80       81    +1
+ Partials        35       34    -1

Impacted Files
Coverage Δ

datahub/core/serializers.py
96.05% <ø> (ø)
:arrow_up:

datahub/company/admin.py
89.47% <0%> (ø)
:arrow_up:

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 ed27f8d...2076ffd. Read the comment docs.


replace the  uv random noise

Hi, if I take this input uv and replace the random noise with a texture that is locally close to the 3D template model, what other parameters do I need to change to make the result more robust?

Hi, thanks for your interest in our work.
As far as I understand, you want to query the template UV texture rather than the random noise that we used as the U-Net input. Is this correct?
Since our DC-PBR (U-Net part) borrows the principle of Deep Image Prior, I think using random noise rather than some structured input would help achieve better results.
Please let us know if you have more questions.
Thanks

Yes, I am now trying to replace the random noise with the texture map corresponding to the input mesh, for example, I now want to recover the dog texture, so I input the pre-prepared dog mesh and texture, and I found that the actual effect is that some of them will be better, and some of them will not be better. Another problem is that I found that the oversaturation is a bit serious now, many samples are better at 700 iterations than at 1500 iterations. By the way, I feel that the texture effect is hard to be utilized in practice, and it seems that there is a big gap between the effect I recovered and the result shown in your paper, I don't know what causes it!

Regarding oversaturation, you may need to find the number of iterations that produce the best quality texture maps, depending on your target meshes. Also, note that the resolution of the meshes (i.e., the number of vertices) or the quality of UV texture mapping matters when synthesizing PBR texture maps.

Please reopen this issue if you need more help regarding this.


ASTGen: An assortment of strides and improvements

This pull request focuses on declaration translation, extrapolating preparatory work to the rest of the module for consistency and testing.

Nice!

@swift-ci please smoke test

@swift-ci please smoke test macOS

@swift-ci please smoke test macOS

Just a quick comment: I’d like to review the PR but won’t get to it until Monday/Tuesday. I’d appreciate if you could leave it open until then.

I’d like to review the PR but won’t get to it until Monday/Tuesday. I’d appreciate if you could leave it open until then.

No problem! I would hate to land this without a review from you.

@swift-ci please smoke test macOS

I added a new issue label for the improvements that I think we should make to ASTGen: https://github.com/apple/swift/labels/ASTGen

https://github.com/apple/swift/labels/ASTGen

Much appreciated!

@swift-ci please smoke test

@ahoppen We have a problem with swift_name on Windows. I thought we were using the just-built clang to compile the Swift compiler, but apparently not.

@swift-ci please test Windows

I take it the conditional def works because we skip the early swift-syntax on Windows. Is this an OK workaround?

I take it the conditional def works because we skip the early swift-syntax on Windows. Is this an OK workaround?

That's not going to be true very soon, but regardless the conditional def seems fine to me - it isn't needed when compiling C++, only when importing into Swift (in which case, it will be defined). Unless I'm misunderstanding something crucial here?

@swift-ci Please test

it isn't needed when compiling C++, only when importing into Swift (in which case, it will be defined). Unless I'm misunderstanding something crucial here?

Nah, actually, thank you, I had a brain fart. I just realized the importer invokes clang to parse headers (so of course it will be defined when importing into Swift). For some reason I had this silly impression that it was C compiler-agnostic even though I knew the importer reads clang ASTs 🙃

@ahoppen @DougGregor @bnbarham @hamishknight Thank you so much for weighing in!

Woo, it's in! Thanks for all the work here @AnthonyLatsis!

Thank you for doing all this work! 🙏🏽


Faker::Time.between produces times out of range

it seam that Faker::Time.between method does not take in consideration the time only the day...
using 1.7.3 with rails 5.0.2.
random_backward_time = Faker::Time.backward(Date.today.day - 1)
random_time = Faker::Time.between(random_backward_time, random_backward_time.end_of_day, :all)
# debug
[random_backward_time, random_time, random_backward_time.end_of_day]

what i'm doing wrong ?

ok after viewing source there is a fix but no doc... sorry


DSD-485: Chakra TextInput

Fixes JIRA ticket DSD-485
This PR does the following:

Updates the DS TextInput component to internally use Chakra's Input and Textarea components.

How has this been tested?
Locally and in Storybook.
Checklist:

[ ] I have updated the Storybook documentation accordingly.
[ ] All new and existing tests passed.

Front End Review:

[ ] View the example in Storybook

Tugboat has finished building the preview for this pull request!
Link:

https://pr684-zhrv67ezx0absohglvsdjo68o8qjzxix.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/61450f1bd7000a185944efcd

Tugboat has finished building the preview for this pull request!
Link:

https://pr684-zhrv67ezx0absohglvsdjo68o8qjzxix.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/61450f1bd7000a185944efcd

Tugboat has finished building the preview for this pull request!
Link:

https://pr684-zhrv67ezx0absohglvsdjo68o8qjzxix.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/61450f1bd7000a185944efcd

Tugboat has finished building the preview for this pull request!
Link:

https://pr684-zhrv67ezx0absohglvsdjo68o8qjzxix.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/61450f1bd7000a185944efcd

Tugboat has finished building the preview for this pull request!
Link:

https://pr684-zhrv67ezx0absohglvsdjo68o8qjzxix.tugboat.qa

Dashboard:

https://dashboard.tugboat.qa/61450f1bd7000a185944efcd


KINDLY won't run

Expected behavior
New install of k9 won't run. Crashes when try to open.
Clue: previous install may have used SD card for storage. Now there's no SD card.
But I uninstalled and reinstalled k9. Maybe old Config....
Actual behavior
Tell us what happens instead
Steps to reproduce

Environment
K-9 Mail version:
Android version:
Account type (IMAP, POP3, WebDAV/Exchange):

Please use the issue template.

New phone and latest K9, not seeing this issue.
thx


calibrate.update_pointing on HMI map?

In GitLab by @jacobdparker on Feb 23, 2021, 10:15
I am attempting to run an HMI map through an hmi_prep.pro equivalent process.  I see in the code that calibrate.register also takes a sunpy.map.Map of HMI data, but calibrate.update_pointing does not.  Is this step not needed for HMI prep?  If there is a relevant tutorial I am missing please let me know.

In GitLab by @markcheung on Feb 23, 2021, 10:29
I'm not aware of HMI pointing keywords requiring updates. Perhaps it's because limb fits are performed on individual images anyway before science level data products are produced. @mbobra would know much more about this.

In GitLab by @mbobra on Feb 23, 2021, 10:45
Yep, that's correct -- HMI pointing keywords don't require updates. And the SunPy map object takes care of the rest, e.g. any necessary rotating from CROTA2.
So you should be able to go straight to your analysis once the HMI data is in the SunPy Map. Let me know if you have any issues using the HMI data; I'm happy to help.

In GitLab by @jacobdparker on Feb 23, 2021, 10:46
Awesome!  Thanks so much for the quick responses @markcheung and @mbobra .


NPM Package Not Found

Describe the bug
The documentation/Readme has "npm install ng-vfor-lib" but NPM returns a notfound for ng-vfor-lib. When installing "ngvforlib" it comes down as a tgz file with a package json.
To Reproduce
Steps to reproduce the behavior:

run "npm install ng-vfor-lib"
See error

Expected behavior
Package should return a series of folders/files containing library.
Desktop (please complete the following information):

OS: MacOS High Sierra

same here, it appears to be under the name 'ngvforlib' rather than, 'ng-vfor-lib' problem is after installing the library i get the following  ERROR in Couldn't resolve original symbol for ./lib/core/directives/ng-vFor-container.directive from /Users/XXXXXXX/Desktop/starter-kit/node_modules/ngvforlib/package/ng-vfor-lib.d.ts

I can not even resolve the module after install

same here, it appears to be under the name 'ngvforlib' rather than, 'ng-vfor-lib' problem is after installing the library i get the following ERROR in Couldn't resolve original symbol for ./lib/core/directives/ng-vFor-container.directive from /Users/XXXXXXX/Desktop/starter-kit/node_modules/ngvforlib/package/ng-vfor-lib.d.ts

Hum, I used the new Angular 6 packgr, currently it means that it needs angular 6 to work. I was thinking of redoing with a @+2.0 and also the @+6.0 versions of angular.
Which version of angular are you guys using ?

Thanks... 6 is fine with me

The problem is that when you do an install with npm i ngvforlib the files that are actually installed are the following:

ng-vfor-lib-0.0.5.tgz
package.json
README.md

It appears there is a problem with the package from NPM.  I was hoping to use this module and give it a go in our large Angular project but no dice.

Yeah they published a zipped package. It may be possible to extract it and use it.

+1 still getting this error
I used :
npm install ngvforlib
import { NgGUDCoreModule } from 'ng-vfor-lib';
and using angular 7
Im getting ERROR : "cannot find module ng-vfor-lib"
and I dont have ng-vfor-lib directory under node_modules only ngvforlib directory which only contains three files:   ng-vfor-lib-0.0.9.tgz, readme.md and package.json

+1 still getting this error
I used :
npm install ngvforlib
import { NgGUDCoreModule } from 'ng-vfor-lib';
and using angular 7
Im getting ERROR : "cannot find module ng-vfor-lib"
and I dont have ng-vfor-lib directory under node_modules only ngvforlib directory which only contains three files: ng-vfor-lib-0.0.9.tgz, readme.md and package.json

Same happens for me.  This package doesn't install correctly which makes the application useless.  It will fail on a build server and it will fail for any other developer who doesn't know they have to go in and unzip the files ( which doesn't work anyway ).

+1 When trying to install on Angular 8. Same, was really looking forward to trying this library, sounds perfect and much needed as none of the other virtual scrolling solutions are versatile enough, im guessing development has stopped on it by the looks of things?

+1 Same issue here with:
Angular CLI: 8.2.1
Node: 10.16.0
OS: linux x64
Angular: 5.2.11
What a shame, the package looked spectacular! I suppose development stopped since there's no response from the devs.


Refactor templates collex

Motivation and Context
As part of the refactoring of templates, this PR covers the following:

Splitting and refactoring of the Collection Exercise views and templates
Extraction of some patterns into usable macros.

What has changed

Created a macro for panel rendering
Finished the splitting and reorganisation of the collex templates

How to test?
Ensure that the collex pages have not regressed, and that the acceptance tests pass.
Links
https://trello.com/c/AJhShGha/261-re-organise-and-rename-response-ops-templates-l

Github issue: closing PR to reopen


MudDrawer Mini drawer items shift a bit when opening and closing

Bug type
Component
Component name
MudDrawer
What happened?
When opening and closing the drawer it's items icons are shifted.
Expected behavior
Items in the drawer should not shift.
Reproduction link
https://try.mudblazor.com/snippet/cacPFbmSynmCungW
Reproduction steps

Open the drawer by hovering or toggling
Close the drawer
Note the shift in icons

The repro is a simple clone of a stock demo without any changes.
Recorded a view of the issue.
https://user-images.githubusercontent.com/14792749/143234821-80b39bec-c5e1-4f07-bec3-a217ffab2957.mp4
Relevant log output
No response
Version (bug)
6.0.2
Version (working)
No response
What browsers are you seeing the problem on?
Chrome
On what operating system are you experiencing the issue?
Windows
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

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

That was worse before, but i know @Garderoben fixed the problem.
If you have problem, as a workaround you can set your menuitem's height by hand with style.

I'm by no means a CSS expert so out of curiosity, wouldn't changing display: none to visibility: hidden also work?
https://github.com/MudBlazor/MudBlazor/blob/45ddf32e745e87d29de317e647549d705bb36c89/src/MudBlazor/Styles/components/_navmenu.scss#L163

Hello,
It appears that the issue has been resolved through this PR: https://github.com/MudBlazor/MudBlazor/pull/6958.
I couldn't reproduce the problem anymore with the provided reproduction link. Based on this, I am closing the issue. However, if I am mistaken, please let me know.
I apologize for the delay in addressing this matter.
I also came across your comment on Habr, and if you're still plan in contributing to MudBlazor and things are going slow, please don't hesitate to ping me.

@ScarletKuro, thanks for taking the time to look into this. I already have a bunch of fixes and changes but very little time to write proper, full and covered tests, descriptions and PRs.
I plan to publish everything when the main project will be finished and launched since it will be already battle tested.


+👙>!!🍆(SEX~Porn🌶XNXX) Porn Star Xxx Sex Videos xxx Porn Videos News leaked viral sex tapes

37 seconds ago.....
[🌐 𝖢𝖫𝖨𝖢𝖪 𝖧𝖤𝖱𝖤 🟢==►► 𝖶𝖠𝖳𝖢𝖧 𝖭𝖮𝖶]
[🔴 𝖢𝖫𝖨𝖢𝖪 𝖧𝖤𝖱𝖤 🌐==►► 𝖣𝗈𝗐𝗇𝗅𝗈𝖺𝖽 𝖭𝗈𝗐]
L𝚎aked Video Porn Star video Original Video Viral Video L𝚎aked on X Twitter Telegram
[-wATCH-]—Porn Star video Video Original Video LinkPorn Starvideo Video Viral On Social Media X Trending Now
[-wATCH-]—Porn Star video ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]—Porn Star video ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]—Porn Star video Video Original Video LinkPorn Starvideo Video Viral On Social Media X Trending Now
Porn Star video Original Video video took the internet by storm and amazed viewers on various social media platforms.Porn Starvideo, a young and talented digital creator, recently became famous thanks to this interesting video.
L𝚎aked VideoPorn Starvideo Original Video Viral Video L𝚎aked on X Twitter
Porn Starvideo Original Video video oficial twitter
L𝚎aked Video Porn Star video Original Video Viral Video L𝚎aked on X Twitter..
.
.
.
.
.
Porn Star video-video
.
.
.
.
.
.
37 seconds ago.....
[🌐 𝖢𝖫𝖨𝖢𝖪 𝖧𝖤𝖱𝖤 🟢==►► 𝖶𝖠𝖳𝖢𝖧 𝖭𝖮𝖶]
[🔴 𝖢𝖫𝖨𝖢𝖪 𝖧𝖤𝖱𝖤 🌐==►► 𝖣𝗈𝗐𝗇𝗅𝗈𝖺𝖽 𝖭𝗈𝗐]
L𝚎aked Video Porn Starvideo Original Video Viral Video L𝚎aked on X Twitter Telegram
[-wATCH-]—Porn Starvideo Video Original Video LinkPorn Starvideo Video Viral On Social Media X Trending Now
[-wATCH-]—Porn Starvideo ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]—Porn Starvideo ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]—Porn Starvideo Video Original Video LinkPorn Starvideo Video Viral On Social Media X Trending Now
Porn Starvideo Original Video video took the internet by storm and amazed viewers on various social media platforms.Porn Starvideo, a young and talented digital creator, recently became famous thanks to this interesting video.
L𝚎aked VideoPorn Starvideo Original Video Viral Video L𝚎aked on X Twitter
Porn Starvideo Original Video video oficial twitter
L𝚎aked VideoPorn Starvideo Original Video Viral Video L𝚎aked on X Twitter..
.
.
.
.
.
.
.
.37 seconds ago.....
[🌐 𝖢𝖫𝖨𝖢𝖪 𝖧𝖤𝖱𝖤 🟢==►► 𝖶𝖠𝖳𝖢𝖧 𝖭𝖮𝖶]
[🔴 𝖢𝖫𝖨𝖢𝖪 𝖧𝖤𝖱𝖤 🌐==►► 𝖣𝗈𝗐𝗇𝗅𝗈𝖺𝖽 𝖭𝗈𝗐]
L𝚎aked Video Porn Starvideo Original Video Viral Video L𝚎aked on X Twitter Telegram
[-wATCH-]—Porn Starvideo Video Original Video LinkPorn Starvideo Video Viral On Social Media X Trending Now
[-wATCH-]—Porn Starvideo ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]—Porn Starvideo ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]—Porn Starvideo Video Original Video LinkPorn Starvideo Video Viral On Social Media X Trending Now
Porn Starvideo Original Video video took the internet by storm and amazed viewers on various social media platforms.Porn Starvideo, a young and talented digital creator, recently became famous thanks to this interesting video.
L𝚎aked VideoPorn Starvideo Original Video Viral Video L𝚎aked on X Twitter
Porn Starvideo Original Video video oficial twitter
L𝚎aked VideoPorn Starvideo Original Video Viral Video L𝚎aked on X Twitter..
.
.

dsfsdfe


Multiuser Auth Support

Coverage decreased (-0.03%) to 90.746% when pulling 82f04baa1244219dd970517f4faa2e551c9cc589 on multiuser into 01b635cc8ffbb4054e84cff927f48ea969bd3396 on master.