[plasmashell] [Bug 487187] When any window is full screened, the drop down menu of any component stops displaying

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=487187

Konrad Materka  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 Status|REPORTED|NEEDSINFO

--- Comment #2 from Konrad Materka  ---
Hi, this is possibly a duplicate of Bug 485456. Are you using Wayland? Do you
see tiny nub were popup should appear?

-- 
You are receiving this mail because:
You are watching all bug changes.

[jira] [Updated] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated MNG-8097:
-
Description: 
Currently often the dependency's type is being set to the extension and the 
resolution is lenient, i.e. if there is no artifact handler defining the value 
given in {{dependency->type}} resolution transparently uses the type as 
extension.
That can potentially lead to two issues:

1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could 
not be resolved: : Could not transfer artifact 
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for 
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which 
registers an artifact handler for type {{content-package}} with extension 
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and 
{{classifier}} from the artifact handler is not evaluated

Compare with 
https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension

  was:
Currently often the dependency's type is being set to the extension and the 
resolution is lenient, i.e. if there is no artifact handler defining the value 
given in {{dependency->type}} resolution transparently uses the type as 
extension.
That can potentially lead to two issues:

1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could 
not be resolved: : Could not transfer artifact 
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for 
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which 
registers an artifact handler for type {{content-package}} with extension 
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and 
{{classifier}} from the artifact handler is not evaluated


> Validate that each dependency->type is a type registered in an artifact 
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
>  Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the 
> resolution is lenient, i.e. if there is no artifact handler defining the 
> value given in {{dependency->type}} resolution transparently uses the type as 
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts 
> could not be resolved: : Could not transfer artifact 
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for 
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which 
> registers an artifact handler for type {{content-package}} with extension 
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and 
> {{classifier}} from the artifact handler is not evaluated
> Compare with 
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed MNG-8050.


> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>    Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in 
>  # {{settings.xml}} and
>  # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error 
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique 
> {code}
> A similar error should be emitted for repository ID clashes in 
> {{settings.xml}} (both local and global) and POM
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved MNG-8050.
--
Fix Version/s: 4.0.0
   4.0.0-beta-3
   Resolution: Fixed

Fixed in 
https://github.com/apache/maven/commit/ac80eeabc4cf28199cf65cb58b27eae590b3d16a.

> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>    Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in 
>  # {{settings.xml}} and
>  # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error 
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique 
> {code}
> A similar error should be emitted for repository ID clashes in 
> {{settings.xml}} (both local and global) and POM
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[plasmashell] [Bug 433079] On Wayland container windows created by XEmbedSNIProxy are not stacked below root window

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=433079

Konrad Materka  changed:

   What|Removed |Added

 CC||e...@horse64.org

--- Comment #39 from Konrad Materka  ---
*** Bug 487166 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 487166] Sometimes clicking a tray icon will invoke the menu of a completely different tray icon

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=487166

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Konrad Materka  ---
Yes, it's the same issue. Thank you for your report!

*** This bug has been marked as a duplicate of bug 433079 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 487127] Tray icons perhaps shouldn't be locked to "Always visible" (probably design issue? or not sure)

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=487127

Konrad Materka  changed:

   What|Removed |Added

 Status|NEEDSINFO   |RESOLVED
 Resolution|WAITINGFORINFO  |INTENTIONAL

--- Comment #3 from Konrad Materka  ---
"Always show all entries" does what it says - it makes all icons always visible
in tray and never hides them in "hidden" section.
If you want mixed mode, so some icons are always hidden, some are always
visible and other hides when not needed then you can set each item manually. By
default Plasma hides icons that are not needed, for example "Notifications" is
shown only when they are notification, "Clipboard" only when there is something
in the clipboard etc. This is controlled by the app that creates tray icon, but
you can always overwrite default behavior.

Closing bug as it works as intended.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 487166] Sometimes clicking a tray icon will invoke the menu of a completely different tray icon

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=487166

--- Comment #1 from Konrad Materka  ---
Are you using Wayland? Is Bug 433079 related?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 487127] Tray icons perhaps shouldn't be locked to "Always visible" (probably design issue? or not sure)

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=487127

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #1 from Konrad Materka  ---
Have you checked the "Always show all entries" option at the bottom? In this
case, this is expected behavior.

-- 
You are receiving this mail because:
You are watching all bug changes.

[jira] [Assigned] (SLING-12319) JcrResourceListener should expose the JCR Event's getIdentifier()

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned SLING-12319:
---

Assignee: (was: Konrad Windszus)

> JcrResourceListener should expose the JCR Event's getIdentifier()
> -
>
> Key: SLING-12319
> URL: https://issues.apache.org/jira/browse/SLING-12319
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Mark Adamcin
>Priority: Major
>
> The JcrResourceChange 
> ([https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/daa4777ba63264b940e6b9b64df24189828ccd17/src/main/java/org/apache/sling/jcr/resource/api/JcrResourceChange.java#L31]
>  ) should expose the value of the JCR Event's getIdentifier() method, which 
> is otherwise read in case it contains a path, but ultimately discarded: 
> [https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/daa4777ba63264b940e6b9b64df24189828ccd17/src/main/java/org/apache/sling/jcr/resource/internal/JcrResourceListener.java#L116]
>  
> The use case for this is primarily to expose the jcr:uuid of deleted 
> mix:referenceable nodes to listeners, because once the node is deleted, the 
> jcr:uuid property can no longer be accessed by the event path.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846855#comment-17846855
 ] 

Konrad Windszus commented on JCRVLT-754:


bq. no sha1 is generated anymore; however, this is what is put into the 
generated vote template.

The SHA1 is generated, but no longer persisted. It is used in the email 
template: 
https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300

> check-release does not work for filevault anymore
> -
>
> Key: JCRVLT-754
> URL: https://issues.apache.org/jira/browse/JCRVLT-754
> Project: Jackrabbit FileVault
>  Issue Type: Task
>Reporter: Julian Reschke
>    Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4
>
>
> Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated 
> anymore; however, this is what is put into the generated vote template.
> The proper fix likely would be to put the SHA512 checksum into the vote 
> template.
> Furthermore, the basename of the source artefact changed from"src" to 
> "source-release". This needs to be adjusted in the check script.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846854#comment-17846854
 ] 

Konrad Windszus commented on JCRVLT-742:


FTR: The SHA1 is still generated and used in the email template being 
generated, but no longer persisted as file: 
https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300

> Stop generating MD5, SHA1 and SHA512 with Ant
> -
>
> Key: JCRVLT-742
> URL: https://issues.apache.org/jira/browse/JCRVLT-742
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>    Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4, package-maven-plugin-1.3.8
>
>
> Currently there is still manual generation of MD5, SHA1 and SHA512 checksum 
> via Ant in 
> https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
>  and 
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.
> MD5 and SHA1 should no longer be provided according to 
> https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 
> is automatically created through the ASF parent pom 
> (https://maven.apache.org/pom/asf/#the-apache-release-profile).
> In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the 
> SHA512 anyways.
> Note: This is only about ASF dist not about the checksums used in Maven 
> repositories which are transparently created by Maven Resolver.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (JCRVLT-754) check-release does not work for filevault anymore

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned JCRVLT-754:
--

Assignee: Konrad Windszus

> check-release does not work for filevault anymore
> -
>
> Key: JCRVLT-754
> URL: https://issues.apache.org/jira/browse/JCRVLT-754
> Project: Jackrabbit FileVault
>  Issue Type: Task
>Reporter: Julian Reschke
>    Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4
>
>
> Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated 
> anymore; however, this is what is put into the generated vote template.
> The proper fix likely would be to put the SHA512 checksum into the vote 
> template.
> Furthermore, the basename of the source artefact changed from"src" to 
> "source-release". This needs to be adjusted in the check script.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846849#comment-17846849
 ] 

Konrad Windszus commented on JCRVLT-753:


We should at least clarify the javadoc of 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html
 to make it clear that {{FORCE_REMOVE_CONFLICTING_ID}} may lead to exceptions 
as well.

> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception 
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe 
> Experience Manager (AEM) using JCR Filevault have led to failures when 
> attempting to replicate content packages. Specifically, the shift from the 
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes 
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to 
> the attempted deletion of mandatory child nodes during the replication 
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a 
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the 
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content* 
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the 
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}: 
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not 
> account for the constraints of mandatory child nodes in the JCR repository, 
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in 
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
>   "jcr:primaryType": "nt:file",
>   "jcr:createdBy": "sling-distribution-importer",
>   "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
>   "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
>   "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
>   "jcr:primaryType": "vlt:PackageDefinition",
>   "testedWith": "",
>   "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
>   "lastUnpackedBy": "sling-distribution-importer",
>   "requiresRestart": false,
>   "requiresRoot": false,
>   "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
>   "buildCount": "17",
>   "providerLink": "",
>   "providerName": "",
>   "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
>   "name": "global-truststore",
>   "group": "admin-tasks",
>   "version": "15.0",
>   "dependencies": [],
>   "fixedBugs": "",
>   "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
>   "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
>   "providerUrl": "",
>   "screenshots": {
> "jcr:primaryType": "nt:unstructured"
>   },
>   "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
>   "jcr:primaryType": "nt:unstructured",
>   "propertyRules": [],
>   "mode": "replace",
>   "root": "/etc/truststore",
>   "rules": []
> }
>   }
> }
>   }
> }{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MNG-7375) Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with invalid/incomplete plugin metadata

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846728#comment-17846728
 ] 

Konrad Windszus edited comment on MNG-7375 at 5/15/24 6:15 PM:
---

Although true, this is due to a limitation in modello: 
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
Compare with 
https://github.com/apache/maven/blob/maven-3.9.x/maven-plugin-api/src/main/mdo/plugin.mdo#L75-L80


was (Author: kwin):
Although true, this is due to a limitation in modello: 
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247

> Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with 
> invalid/incomplete plugin metadata
> ---
>
> Key: MNG-7375
> URL: https://issues.apache.org/jira/browse/MNG-7375
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: NEXUS-30749 - Broken groupId metadata and follow-up NPE 
> during 
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
>  - Sonatype JIRA.pdf
>
>
> Currently the metadata at 
> https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/jackrabbit/maven-metadata.xml
>  contains an invalid entry without a prefix:
> {code:xml}
> 
>   
> 
>   Apache Jackrabbit FileVault - Package Maven Plugin
>   filevault-package
>   filevault-package-maven-plugin
> 
> 
>   filevault-package-maven-plugin
>   filevault-package-maven-plugin
> 
>   
> 
> {code}
> This leads to an NPE when trying to deploy a new version with 
> {{org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(...)}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge 
> (Metadata.java:276)
> at 
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
>  (AbstractRepositoryMetadata.java:121)
> at 
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
>  (AbstractRepositoryMetadata.java:67)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge 
> (MetadataBridge.java:65)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload 
> (DefaultDeployer.java:433)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy 
> (DefaultDeployer.java:321)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy 
> (DefaultDeployer.java:213)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy 
> (DefaultRepositorySystem.java:386)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy 
> (DefaultArtifactDeployer.java:142)
> {noformat}
> Although this happened in the context of using 
> "[org.sonatype.plugins:nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins]:1.6.8;
>  (issue https://issues.sonatype.org/browse/NEXUS-30749 opened, exported to  
> [^NEXUS-30749 - Broken groupId metadata and follow-up NPE during 
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
>  - Sonatype JIRA.pdf] ), the affected code is in Maven.
> The metadata is probably invalid but the Metadata class should be more robust 
> when trying to do the merge in 
> https://github.com/apache/maven/blob/951b5ee95f40147abbc2bb9d928e408b85d5aef3/maven-repository-metadata/src/main/mdo/metadata.mdo#L100
>  and just ignore all plugin entries without all mandatory elements.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MNG-7375) Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with invalid/incomplete plugin metadata

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846728#comment-17846728
 ] 

Konrad Windszus commented on MNG-7375:
--

Although true, this is due to a limitation in modello: 
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247

> Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with 
> invalid/incomplete plugin metadata
> ---
>
> Key: MNG-7375
> URL: https://issues.apache.org/jira/browse/MNG-7375
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: NEXUS-30749 - Broken groupId metadata and follow-up NPE 
> during 
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
>  - Sonatype JIRA.pdf
>
>
> Currently the metadata at 
> https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/jackrabbit/maven-metadata.xml
>  contains an invalid entry without a prefix:
> {code:xml}
> 
>   
> 
>   Apache Jackrabbit FileVault - Package Maven Plugin
>   filevault-package
>   filevault-package-maven-plugin
> 
> 
>   filevault-package-maven-plugin
>   filevault-package-maven-plugin
> 
>   
> 
> {code}
> This leads to an NPE when trying to deploy a new version with 
> {{org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(...)}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge 
> (Metadata.java:276)
> at 
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
>  (AbstractRepositoryMetadata.java:121)
> at 
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
>  (AbstractRepositoryMetadata.java:67)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge 
> (MetadataBridge.java:65)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload 
> (DefaultDeployer.java:433)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy 
> (DefaultDeployer.java:321)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy 
> (DefaultDeployer.java:213)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy 
> (DefaultRepositorySystem.java:386)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy 
> (DefaultArtifactDeployer.java:142)
> {noformat}
> Although this happened in the context of using 
> "[org.sonatype.plugins:nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins]:1.6.8;
>  (issue https://issues.sonatype.org/browse/NEXUS-30749 opened, exported to  
> [^NEXUS-30749 - Broken groupId metadata and follow-up NPE during 
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
>  - Sonatype JIRA.pdf] ), the affected code is in Maven.
> The metadata is probably invalid but the Metadata class should be more robust 
> when trying to do the merge in 
> https://github.com/apache/maven/blob/951b5ee95f40147abbc2bb9d928e408b85d5aef3/maven-repository-metadata/src/main/mdo/metadata.mdo#L100
>  and just ignore all plugin entries without all mandatory elements.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846704#comment-17846704
 ] 

Konrad Windszus commented on JCRVLT-753:


[~dbanjac] Can you provide a failing IT in a PR?

However I don't have a clever idea how to solve this edge case as all options 
outlined above by [~reschke] seem quite unexpected to the user either so any 
other suggestions would be much appreciated.

> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception 
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe 
> Experience Manager (AEM) using JCR Filevault have led to failures when 
> attempting to replicate content packages. Specifically, the shift from the 
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes 
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to 
> the attempted deletion of mandatory child nodes during the replication 
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a 
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the 
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content* 
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the 
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}: 
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not 
> account for the constraints of mandatory child nodes in the JCR repository, 
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in 
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
>   "jcr:primaryType": "nt:file",
>   "jcr:createdBy": "sling-distribution-importer",
>   "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
>   "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
>   "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
>   "jcr:primaryType": "vlt:PackageDefinition",
>   "testedWith": "",
>   "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
>   "lastUnpackedBy": "sling-distribution-importer",
>   "requiresRestart": false,
>   "requiresRoot": false,
>   "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
>   "buildCount": "17",
>   "providerLink": "",
>   "providerName": "",
>   "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
>   "name": "global-truststore",
>   "group": "admin-tasks",
>   "version": "15.0",
>   "dependencies": [],
>   "fixedBugs": "",
>   "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
>   "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
>   "providerUrl": "",
>   "screenshots": {
> "jcr:primaryType": "nt:unstructured"
>   },
>   "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
>   "jcr:primaryType": "nt:unstructured",
>   "propertyRules": [],
>   "mode": "replace",
>   "root": "/etc/truststore",
>   "rules": []
> }
>   }
> }
>   }
> }{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PATCH] drm/msm: Add obj flags to gpu devcoredump

[Konrad Dybcio]

On 5/13/24 17:51, Rob Clark wrote:

From: Rob Clark 

When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).

Signed-off-by: Rob Clark 
---


Acked-by: Konrad Dybcio 

Konrad

Re: [PATCH] drm/msm: Add obj flags to gpu devcoredump

[Konrad Dybcio]

On 5/13/24 17:51, Rob Clark wrote:

From: Rob Clark 

When debugging faults, it is useful to know how the BO is mapped (cached
vs WC, gpu readonly, etc).

Signed-off-by: Rob Clark 
---


Acked-by: Konrad Dybcio 

Konrad

[plasmashell] [Bug 486989] System Tray Context Menu sets its size to 0x0 (practically invisble) everytime the floating system bar switches to fixed mode.

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=486989

Konrad Materka  changed:

   What|Removed |Added

 Resolution|--- |WAITINGFORINFO
 Status|REPORTED|NEEDSINFO

--- Comment #1 from Konrad Materka  ---
Is context menu sized incorrectly or extended applet? I'm asking, because
similar issue was already reported: Bug 485456

-- 
You are receiving this mail because:
You are watching all bug changes.

API Regions and Split-Packages

[Konrad Windszus]

Hi,
I have a question about 
https://github.com/apache/sling-org-apache-sling-feature-apiregions and split 
packages.
How are split-packages supposed to be treated by the resolver in case an 
imported-package from bundle a in region A can be resolved from bundle b (in 
region A) and bundle c (in global region).
Is there any special rules applied here for split-packages across regions?

Thanks in advance,
Konrad

Re: [vz-dev] Gateway?

[Konrad Wilhelm]

On Mon, 13 May 2024 09:22:28 +0200, you wrote:

>Am Montag, dem 13.05.2024 um 08:39 +0200 schrieb Daniel Lauckner:
>> Die modernen Messeinrichtungen (eHz) haben 2 optische Schnittstellen. Eine 
>> vorne, die wir mit dem Lesekopf anzapfen. Eine hinten.
>> Die Gateways werden an der rückseitigen Schnittstelle angeschlossen, der 
>> Lesekopf ist da in der Zählerplatte fixiert und verbleibt beim Zählertausch.
>
>Danke für die Info. Weißt Du auch, welche Protokolle verwendet werden? 
>
>Meine Vermutung ist, das neue Zähler verstärkt MBus verwenden werden,
>weil die Gateways auch über MBus kommunizieren.
>
>Gruß,
>Joachim
Die Beschreibung der Schnittstelle, die man mit einem IR-Kopf abgreift (direkt
neben der Taschenlampenschnittstelle)
findet man z. B. sehr detailliert hier:
https://www.stadtwerke-rheine.de/de/Netze/Stromnetz/Betriebsanleitung-mME-DD3-2023-11-23.pdf

Funktioniert bei mir gut.

l.
--
Konrad Wilhelm 
Südstr. 3, D48329 Havixbeck Tel. 02507-7705

[PATCH v2] drm/msm/adreno: De-spaghettify the use of memory barriers

[Konrad Dybcio]

Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.

Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.

Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").

Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio 
---
Changes in v2:

* Introduce gpu_write_flush() and use it
* Don't accidentally break a630 by trying to write to non-existent GBIF
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  4 +---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16 
 drivers/gpu/drm/msm/msm_gpu.h | 14 --
 4 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..fb2f8a03da41 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,7 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
 
-   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
-   /* Wait for the register to finish posting */
-   wmb();
+   gmu_write_flush(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
 
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 94b6c5cab6f4..ab7f581f0d24 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -111,6 +111,16 @@ static inline void gmu_write(struct a6xx_gmu *gmu, u32 
offset, u32 value)
writel(value, gmu->mmio + (offset << 2));
 }
 
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gmu_write_flush(struct a6xx_gmu *gmu, u32 offset, u32 value)
+{
+   gmu_write(gmu, offset, value);
+   gmu_read(gmu, offset);
+}
+
 static inline void
 gmu_write_bulk(struct a6xx_gmu *gmu, u32 offset, const u32 *data, u32 size)
 {
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index cf0b1de1c071..ef7eaa6d5e5c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1714,21 +1714,13 @@ static int hw_init(struct msm_gpu *gpu)
 
/* Clear GBIF halt in case GX domain was not collapsed */
if (adreno_is_a619_holi(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
-   gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_write_flush(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
} else if (a6xx_has_gbif(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
-   gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_write_flush(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
}
 
-   /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
-   if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
-   spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
 
if (adreno_is_a619_holi(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index a0c1bd6d1d5b..45d00acd5b1b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -553,14 +553,24 @@ struct msm_gpu_state {
struct msm_gpu_state_bo *bos;
 };
 
+static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+{
+   return readl(gpu->mmio + (reg << 2));
+}
+
 static inline void gpu_write(struct msm_gpu *gpu, u32 reg, u32 data)
 {
writel(data, gpu->mmio + (reg << 2));
 }
 
-static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gpu_write_flush(struct msm_gpu *gpu, u32 reg, u32 data)
 {
-  

[PATCH v2] drm/msm/adreno: De-spaghettify the use of memory barriers

[Konrad Dybcio]

Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.

Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.

Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").

Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio 
---
Changes in v2:

* Introduce gpu_write_flush() and use it
* Don't accidentally break a630 by trying to write to non-existent GBIF
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  4 +---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16 
 drivers/gpu/drm/msm/msm_gpu.h | 14 --
 4 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..fb2f8a03da41 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,7 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
 
-   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
-   /* Wait for the register to finish posting */
-   wmb();
+   gmu_write_flush(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
 
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 94b6c5cab6f4..ab7f581f0d24 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -111,6 +111,16 @@ static inline void gmu_write(struct a6xx_gmu *gmu, u32 
offset, u32 value)
writel(value, gmu->mmio + (offset << 2));
 }
 
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gmu_write_flush(struct a6xx_gmu *gmu, u32 offset, u32 value)
+{
+   gmu_write(gmu, offset, value);
+   gmu_read(gmu, offset);
+}
+
 static inline void
 gmu_write_bulk(struct a6xx_gmu *gmu, u32 offset, const u32 *data, u32 size)
 {
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index cf0b1de1c071..ef7eaa6d5e5c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1714,21 +1714,13 @@ static int hw_init(struct msm_gpu *gpu)
 
/* Clear GBIF halt in case GX domain was not collapsed */
if (adreno_is_a619_holi(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
-   gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_write_flush(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
} else if (a6xx_has_gbif(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
-   gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_write_flush(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_write_flush(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
}
 
-   /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
-   if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
-   spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
 
if (adreno_is_a619_holi(adreno_gpu))
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index a0c1bd6d1d5b..45d00acd5b1b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -553,14 +553,24 @@ struct msm_gpu_state {
struct msm_gpu_state_bo *bos;
 };
 
+static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+{
+   return readl(gpu->mmio + (reg << 2));
+}
+
 static inline void gpu_write(struct msm_gpu *gpu, u32 reg, u32 data)
 {
writel(data, gpu->mmio + (reg << 2));
 }
 
-static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
+/*
+ * Use for timing-critical writes that must reach the hardware immediately
+ * (to work around write buffering), e.g. for reset registers.
+ */
+static inline void gpu_write_flush(struct msm_gpu *gpu, u32 reg, u32 data)
 {
-  

[Bug 2064208] Re: Installer crashes when booting from USB on Raspberry Pi

[Konrad Krasowski]

Adding to the above:

1. @waveform - thank you so much for the new image!!! - it works!
Nothing has worked for me until now, even the initial ubuntu setup from
sd card (tried other options: usb stick, sd card via usb adapter, nvme),
no matter how I flashed it (r-imager, balenda etcher). I always ended up
with failed installation pop-up window, without even displaying the
graphic glitch with the progress bar. Now I have managed successfully to
set ubuntu 24.04 lts on my pi from the sd card as well as the nvme!

2. Test hardware details:
   - Raspberry pi 5 with 8gb ram
   - micro sd SanDisc Extreme V30 32GB flashed with Balena Etcher on mac
   - nvme Lexar NM790 1TB (Gen 4x4) flashed with pi-imager using custom image 
on my pi when the above got  running

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2064208

Title:
  Installer crashes when booting from USB on Raspberry Pi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/2064208/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers

[Konrad Dybcio]

Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.

Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.

Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").

Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  5 ++---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
 2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
 
-   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
-   /* Wait for the register to finish posting */
-   wmb();
+   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+   gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
 
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
 
/* Clear GBIF halt in case GX domain was not collapsed */
+   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
 
-   /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
-   if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
-   spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
 
if (adreno_is_a619_holi(adreno_gpu))

---
base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
change-id: 20240508-topic-adreno-a2d199cd4152

Best regards,
-- 
Konrad Dybcio 

[PATCH] drm/msm/adreno: De-spaghettify the use of memory barriers

[Konrad Dybcio]

Memory barriers help ensure instruction ordering, NOT time and order
of actual write arrival at other observers (e.g. memory-mapped IP).
On architectures employing weak memory ordering, the latter can be a
giant pain point, and it has been as part of this driver.

Moreover, the gpu_/gmu_ accessors already use non-relaxed versions of
readl/writel, which include r/w (respectively) barriers.

Replace the barriers with a readback that ensures the previous writes
have exited the write buffer (as the CPU must flush the write to the
register it's trying to read back) and subsequently remove the hack
introduced in commit b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt
status in hw_init").

Fixes: b77532803d11 ("drm/msm/a6xx: Poll for GBIF unhalt status in hw_init")
Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  5 ++---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 --
 2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 0e3dfd4c2bc8..4135a53b55a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -466,9 +466,8 @@ static int a6xx_rpmh_start(struct a6xx_gmu *gmu)
int ret;
u32 val;
 
-   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 1 << 1);
-   /* Wait for the register to finish posting */
-   wmb();
+   gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, BIT(1));
+   gmu_read(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ);
 
ret = gmu_poll_timeout(gmu, REG_A6XX_GMU_RSCC_CONTROL_ACK, val,
val & (1 << 1), 100, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 973872ad0474..0acbc38b8e70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1713,22 +1713,16 @@ static int hw_init(struct msm_gpu *gpu)
}
 
/* Clear GBIF halt in case GX domain was not collapsed */
+   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
+   gpu_read(gpu, REG_A6XX_GBIF_HALT);
if (adreno_is_a619_holi(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GPR0_CNTL, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_read(gpu, REG_A6XX_RBBM_GPR0_CNTL);
} else if (a6xx_has_gbif(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_GBIF_HALT, 0);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 0);
-   /* Let's make extra sure that the GPU can access the memory.. */
-   mb();
+   gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
}
 
-   /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
-   if (adreno_is_a7xx(adreno_gpu) && a6xx_has_gbif(adreno_gpu))
-   spin_until(!gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK));
-
gpu_write(gpu, REG_A6XX_RBBM_SECVID_TSB_CNTL, 0);
 
if (adreno_is_a619_holi(adreno_gpu))

---
base-commit: 93a39e4766083050ca0ecd6a3548093a3b9eb60c
change-id: 20240508-topic-adreno-a2d199cd4152

Best regards,
-- 
Konrad Dybcio 

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Fixed in 
https://github.com/apache/jackrabbit-filevault/commit/33b23e126e7e7260582dd43d4b9f4c93958da674.

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
> Fix For: 3.7.4
>
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (FELIX-6704) Improve error logging for exceptions thrown from Configuration Plugins in ConfigurationManager

[Konrad Windszus (Jira)]

Konrad Windszus created FELIX-6704:
--

 Summary: Improve error logging for exceptions thrown from 
Configuration Plugins in ConfigurationManager
 Key: FELIX-6704
 URL: https://issues.apache.org/jira/browse/FELIX-6704
 Project: Felix
  Issue Type: Improvement
  Components: Configuration Admin
Affects Versions: configadmin-1.9.24
Reporter: Konrad Windszus


Currently all throwables are caught in 
https://github.com/apache/felix-dev/blob/517f9a0c89cad1866f315255568b40c568f5239d/configadmin/src/main/java/org/apache/felix/cm/impl/ConfigurationManager.java#L932
 and logged. 
The important factory or configuration PID is not emitted in the log message 
though.

Example:

{code}
07.05.2024 20:41:33.820 *ERROR* [FelixLogListener] 
LogService.org.apache.felix.configadmin Service 
[org.apache.felix.cm.ConfigurationAdmin,47, 
[org.osgi.service.cm.ConfigurationAdmin]] Unexpected problem calling 
configuration plugin [org.osgi.service.cm.ConfigurationPlugin, id=41, 
bundle=38/slinginstall:org.apache.felix.configadmin.plugin.interpolation-1.2.6.jar]
 (org.apache.felix.log.LogException: 
org.osgi.util.converter.ConversionException: Cannot convert TO BE PROVIDED to 
class java.lang.Integer)
org.apache.felix.log.LogException: org.osgi.util.converter.ConversionException: 
Cannot convert TO BE PROVIDED to class java.lang.Integer
at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:243)
at 
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:183)
at 
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:151)
at 
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:141)
at 
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.convertType(InterpolationConfigurationPlugin.java:308)
at 
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.lambda$replace$0(InterpolationConfigurationPlugin.java:197)
at 
org.apache.felix.configadmin.plugin.interpolation.Interpolator.replace(Interpolator.java:149)
at 
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.replace(InterpolationConfigurationPlugin.java:179)
at 
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.getNewValue(InterpolationConfigurationPlugin.java:171)
at 
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.modifyConfiguration(InterpolationConfigurationPlugin.java:133)
at 
org.apache.felix.cm.impl.ConfigurationManager.callPlugins(ConfigurationManager.java:928)
 [org.apache.felix.configadmin:1.9.24]
at 
org.apache.felix.cm.impl.ConfigurationAdapter.getProcessedProperties(ConfigurationAdapter.java:293)
 [org.apache.felix.configadmin:1.9.24]
at 
org.apache.felix.scr.impl.manager.RegionConfigurationSupport.getConfigurationInfo(RegionConfigurationSupport.java:532)
 [org.apache.felix.scr:2.2.4]
at 
org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:333)
 [org.apache.felix.scr:2.2.4]
at 
org.apache.felix.scr.impl.manager.RegionConfigurationSupport$2.configurationEvent(RegionConfigurationSupport.java:115)
 [org.apache.felix.scr:2.2.4]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:1721)
 [org.apache.felix.configadmin:1.9.24]
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1662)
 [org.apache.felix.configadmin:1.9.24]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:122) 
[org.apache.felix.configadmin:1.9.24]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:84) 
[org.apache.felix.configadmin:1.9.24]
at java.base/java.lang.Thread.run(Thread.java:829)
{code}

For debugging purposes the configuration PID is the most crucial bit of 
information and this is missing from this log message.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PATCH v3 3/3] arm64: dts: qcom: msm8998: set qcom,no-msa-ready-indicator for wifi

[Konrad Dybcio]

On 5/6/24 12:39, Marc Gonzalez wrote:

On 29/04/2024 16:07, Marc Gonzalez wrote:


The ath10k driver waits for an "MSA_READY" indicator
to complete initialization. If the indicator is not
received, then the device remains unusable.

cf. ath10k_qmi_driver_event_work()

Several msm8998-based devices are affected by this issue.
Oddly, it seems safe to NOT wait for the indicator, and
proceed immediately when QMI_EVENT_SERVER_ARRIVE.

Jeff Johnson wrote:

   The feedback I received was "it might be ok to change all ath10k qmi
   to skip waiting for msa_ready", and it was pointed out that ath11k
   (and ath12k) do not wait for it.

   However with so many deployed devices, "might be ok" isn't a strong
   argument for changing the default behavior.

cf. also
https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN

Signed-off-by: Marc Gonzalez 
---
  arch/arm64/boot/dts/qcom/msm8998.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 67b8374ddf02f..4e6245095adfc 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -3234,6 +3234,7 @@ wifi: wifi@1880 {
iommus = <_smmu 0x1900>,
 <_smmu 0x1901>;
qcom,snoc-host-cap-8bit-quirk;
+   qcom,no-msa-ready-indicator;
};
};
  };



Bjorn,

This patch is supposed to go through your tree, right?


Reviewed-by: Konrad Dybcio 

Konrad

[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188
 ] 

Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:18 AM:
-

bq. why it gets "highest class version present on classpath"? Why not compiler 
target instead? ... 

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

bq. Similarly, if I have one class that is Java 22, the plugin prerequisite is 
NOT Java 22.

It the class is in the plugin classpath I would assume that this is necessary 
for plugin execution (not necessarily for each mojo). If the class isn't being 
called then it shouldn't be there in the first place...

bq.  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy,  because that is very 
frustrating for users not complying with those (unexplicit) prerequisites.


was (Author: kwin):
bq. why it gets "highest class version present on classpath"? Why not compiler 
target instead?

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

bq.  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy,  because that is very 
frustrating for users not complying with those (unexplicit) prerequisites.

> The auto prerequisites are way to aggressive
> 
>
> Key: MPLUGIN-522
> URL: https://issues.apache.org/jira/browse/MPLUGIN-522
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Reporter: Tamas Cservenak
>Priority: Major
>
> IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong.
> They are way too aggresive and violate backward compatibility: if new feature 
> is not explicitly set by user, code should not "come up" with some automatic 
> value. By having the value not set simply means user does not want to use it.
> This is especially true for (maven or java) prerequisite, as it creates HARD 
> BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto 
> user.
> [~kwin] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188
 ] 

Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:10 AM:
-

bq. why it gets "highest class version present on classpath"? Why not compiler 
target instead?

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

bq.  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy,  because that is very 
frustrating for users not complying with those (unexplicit) prerequisites.


was (Author: kwin):
bq. why it gets "highest class version present on classpath"? Why not compiler 
target instead?

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

bq.  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy.

> The auto prerequisites are way to aggressive
> 
>
> Key: MPLUGIN-522
> URL: https://issues.apache.org/jira/browse/MPLUGIN-522
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Reporter: Tamas Cservenak
>Priority: Major
>
> IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong.
> They are way too aggresive and violate backward compatibility: if new feature 
> is not explicitly set by user, code should not "come up" with some automatic 
> value. By having the value not set simply means user does not want to use it.
> This is especially true for (maven or java) prerequisite, as it creates HARD 
> BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto 
> user.
> [~kwin] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188
 ] 

Konrad Windszus commented on MPLUGIN-522:
-

> why it gets "highest class version present on classpath"? Why not compiler 
> target instead?

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

>  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
> does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
> happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy.

> The auto prerequisites are way to aggressive
> 
>
> Key: MPLUGIN-522
> URL: https://issues.apache.org/jira/browse/MPLUGIN-522
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Reporter: Tamas Cservenak
>Priority: Major
>
> IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong.
> They are way too aggresive and violate backward compatibility: if new feature 
> is not explicitly set by user, code should not "come up" with some automatic 
> value. By having the value not set simply means user does not want to use it.
> This is especially true for (maven or java) prerequisite, as it creates HARD 
> BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto 
> user.
> [~kwin] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188
 ] 

Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:08 AM:
-

bq. why it gets "highest class version present on classpath"? Why not compiler 
target instead?

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

bq.  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy.


was (Author: kwin):
> why it gets "highest class version present on classpath"? Why not compiler 
> target instead?

Because in general it is fair to assume that every class being embedded in the 
plugin is supposed to be executed. That requires a Java version capable of 
digesting the class version. Not every class being shipped with the plugin is 
necessarily compiled in the same build.

>  if I compile against 3.9.6 Maven APIs, that – due backward compatibility – 
> does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are 
> happily working even with 3.6.3 or even 3.2.x.

What you describe is not backwards-compatibility but forwards-compatibility. 
Each minor Maven version may add new methods/classes to Maven API in a 
backwards-compatible way. Therefore it is fair to assume that the Maven API you 
compile against is the minimally required Maven version.

What you are running into are edge cases which IMHO justify that you override 
the automatically created values (i.e. one class with bytecode for Java22 not 
being executed by the Mojo for some reason, compiling against a newer Maven 
version than you require). I don't want plugins to not state prerequisites at 
all just because plugin developers are too lazy.

> The auto prerequisites are way to aggressive
> 
>
> Key: MPLUGIN-522
> URL: https://issues.apache.org/jira/browse/MPLUGIN-522
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: Plugin Plugin
>Reporter: Tamas Cservenak
>Priority: Major
>
> IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong.
> They are way too aggresive and violate backward compatibility: if new feature 
> is not explicitly set by user, code should not "come up" with some automatic 
> value. By having the value not set simply means user does not want to use it.
> This is especially true for (maven or java) prerequisite, as it creates HARD 
> BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto 
> user.
> [~kwin] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Zusäutzliche Festplatte dauerhaft einbinden + Speed-Test

[Konrad Rosenbaum]

On 06/05/2024 13:44, Gerd G wrote:

Man kann natürlich auch einfach mal was mit "dd" auf den Datenträger schreiben 
und sich dabei die Zeit und Datenmenge
ansehen.

Bei den Tools ist Vorsicht geboten, sie sind mit root Rechten nutzbar und man 
kann bei falsche Nutzung dabei auch Dinge
kaputt machen.


Vorsichtshalber: man kann sich nicht nur was dabei kaputtmachen - ich 
habe mir auch schonmal die Daten auf einer ANDEREN Platte geschrottet, 
indem ich nicht aufgepasst habe. Also ganz genau schauen was man 
eintippt und mindestens 3x lesen, sicherstellen dass man das richtige 
Device angegeben hat und mit Man-Page vergleichen bevor man Enter drückt!



    Konrad



OpenPGP_0xBE96A6EE776FE5D0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M14

[Konrad Windszus]

Hi,
There was a longer discussion in 
https://www.mail-archive.com/dev@maven.apache.org/msg132078.html (for some 
reason cannot find the thread in 
https://lists.apache.org/list.html?dev@maven.apache.org) and we kind of came to 
an agreement to reserve plugin major version 4 for plugins leveraging Maven 4 
API.
So should we rename this to m-site-p 3.13.x?
This requires adaptation in the source code with regards to the since javadoc 
tag.
WDYT?
Konrad

> On 5. May 2024, at 21:29, Michael Osipov  wrote:
> 
> Hi,
> 
> we solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12354123
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2109/
> https://repository.apache.org/content/repositories/maven-2109/org/apache/maven/plugins/maven-site-plugin/4.0.0-M14/maven-site-plugin-4.0.0-M14-source-release.zip
> 
> Source release checksum(s):
> maven-site-plugin-4.0.0-M14-source-release.zip
> sha512: 
> cf9b896e1bc10b0bb81ded66f343e478da4da21300d10ac586ac08a8640bc7c11f25ff49d8f443c12e98011608c5d2db308d9b0b7ec1d9378d84616712b5b660
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

[jira] [Updated] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCR-5051:
-
Description: 
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed 
character in the grammar 
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to 
explicitly add another method to keep the wildcard in place. 

  was:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed 
character in the grammar 
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to 
explicitly add another method to keep the wildcard in place.


> ISO9075.encodePath/encode should preserve wildcard
> --
>
> Key: JCR-5051
> URL: https://issues.apache.org/jira/browse/JCR-5051
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-jcr-commons
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
> This is not intended as in the context of XPath the wildcard is an allowed 
> character in the grammar 
> (https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
> Not sure if ISO9075 is used for other purposes so it might be better to 
> explicitly add another method to keep the wildcard in place. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCR-5051:
-
Description: 
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed 
character in the grammar 
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to 
explicitly add another method to keep the wildcard in place.

  was:
Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed 
character in the grammar 
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to 
explicitly add another method to keep the wildcard in place.


> ISO9075.encodePath/encode should preserve wildcard
> --
>
> Key: JCR-5051
> URL: https://issues.apache.org/jira/browse/JCR-5051
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-jcr-commons
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
> This is not intended as in the context of XPath the wildcard is an allowed 
> character in the grammar 
> (https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
> Not sure if ISO9075 is used for other purposes so it might be better to 
> explicitly add another method to keep the wildcard in place.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard

[Konrad Windszus (Jira)]

Konrad Windszus created JCR-5051:


 Summary: ISO9075.encodePath/encode should preserve wildcard
 Key: JCR-5051
 URL: https://issues.apache.org/jira/browse/JCR-5051
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-jcr-commons
Reporter: Konrad Windszus


Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed 
character in the grammar 
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to 
explicitly add another method to keep the wildcard in place.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[plasmashell] [Bug 485456] With Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||k...@rad1an.aleeas.com

--- Comment #24 from Konrad Materka  ---
*** Bug 486476 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 486476] Tray applets opening to zero width after any window is made fullscreen

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=486476

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Konrad Materka  ---


*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485587] Tray icons on-click popups not visible

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485587

Konrad Materka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|CONFIRMED   |RESOLVED

--- Comment #8 from Konrad Materka  ---


*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485456] With Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||sascha.ap...@gmail.com

--- Comment #19 from Konrad Materka  ---
*** Bug 485587 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[kipiplugins] [Bug 452738] Kipiplugins disappear from Gwenview

[Konrad Bucheli]

https://bugs.kde.org/show_bug.cgi?id=452738

Konrad Bucheli  changed:

   What|Removed |Added

 CC||konrad.buch...@gmx.ch

--- Comment #5 from Konrad Bucheli  ---
I also miss the very good photo printing wizard in the kipi-plugins. There is
now something similar in digikam, the "Print Creator"
(https://docs.digikam.org/en/post_processing/print_creator.html). I would be
great if this wizard could also be directly started from gwenview.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [R-pkg-devel] [External] May .External2() be used in packages?

[Konrad Rudolph]

Hi Luke,

Thanks, obviously that will work and I didn’t think of it.

In my defence I had previously used match.call() to capture the call on the
R side, and representative microbenchmarks show that it adds a prohibitive
overhead for my use-case. On the C side I only need the caller information
in the non-performance sensitive path (for error message formatting) so I
can compute it on demand. And I hadn’t included .External2() in that
benchmark yet. I assume that it’ll be no faster than the way you proposed,
so it isn’t actually needed in my case — just as you said.


On Wed, 1 May 2024 at 21:32,  wrote:

> yOn Wed, 1 May 2024, Konrad Rudolph wrote:
>
> > Thanks,
> >
> > That’s a shame but good to know.
> >
> >   Packages that for whatever reason have chosen to use it
> >   could instead use .External(), and that is what yo should use.
> >
> >
> > Unfortunately .External() is not a replacement (in general, or for my
> > purpose) since it’s missing the `call` and `rho` arguments, and computing
> > the same information without these arguments in C code is far from
> trivial.
>
> The call you would get is not likely to be all that useful, but it is
> the one you wrote. The environment is the one you get from environment()
> at the point where you would call .External2. So instead of
>
> .External2("foo", x, y)
>
> do
>
> .External("foo", quote(.External2("foo", x, y)), environment(), x, y)
>
> and adjust your C function accordingly.
>
> Best,
>
> luke
>
> > --
> > Konrad Rudolph // @klmr
> >
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu



-- 
Konrad Rudolph // @klmr

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] May .External2() be used in packages?

[Konrad Rudolph]

Thanks,

That’s a shame but good to know.

Packages that for whatever reason have chosen to use it
> could instead use .External(), and that is what yo should use.


Unfortunately .External() is not a replacement (in general, or for my
purpose) since it’s missing the `call` and `rho` arguments, and computing
the same information without these arguments in C code is far from trivial.

-- 
Konrad Rudolph // @klmr

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] May .External2() be used in packages?

[Konrad Rudolph]

Hello,

Is the `.External2()` function part of the public API, and can it be used
in R packages submitted to CRAN? I would like to start using it in a
package, and there *are* packages on CRAN which use it. But its man page
[1] calls it “internal”, R-exts doesn’t mention it at all (unlike `.C()`,
`.Call()` and `.External()`), and it doesn’t have any actual documentation.
In the context of the recent tightening of the C API CRAN rules, this makes
me concerned that `.External2()` might be next on the chopping block.

[1]
https://stat.ethz.ch/R-manual/R-devel/library/base/html/Foreign-internal.html

Cheers,

-- 
Konrad Rudolph // @klmr

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Fix Version/s: 3.7.4

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
> Fix For: 3.7.4
>
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Summary: ExportOptions.rootPath not properly converted to platform name 
format  (was: ExportOptions.rootPath not properly unescaped during filter rule 
mapping)

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Assignee: Konrad Windszus
  Status: Patch Available  (was: Open)

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly unescaped during filter rule mapping

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Summary: ExportOptions.rootPath not properly unescaped during filter rule 
mapping  (was: Can't import a user with parent folder that starts with _ and 
includes another _ )

> ExportOptions.rootPath not properly unescaped during filter rule mapping
> 
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PATCH v3 6/6] drm/msm/a7xx: Add missing register writes from downstream

[Konrad Dybcio]

On 30.04.2024 12:43 PM, Connor Abbott wrote:
> This isn't known to fix anything yet, but it's a good idea to add it.
> 
> Signed-off-by: Connor Abbott 
> ---

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH v3 4/6] drm/msm/a7xx: Initialize a750 "software fuse"

[Konrad Dybcio]

On 30.04.2024 12:43 PM, Connor Abbott wrote:
> On all Qualcomm platforms with a7xx GPUs, qcom_scm provides a method to
> initialize cx_mem. Copy this from downstream (minus BCL which we
> currently don't support). On a750, this includes a new "fuse" register
> which can be used by qcom_scm to fuse off certain features like
> raytracing in software. The fuse is default off, and is initialized by
> calling the method. Afterwards we have to read it to find out which
> features were enabled.
> 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Connor Abbott 
> ---

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH v3 2/6] firmware: qcom_scm: Add gpu_init_regs call

[Konrad Dybcio]

On 30.04.2024 12:43 PM, Connor Abbott wrote:
> This will used by drm/msm to initialize GPU registers that Qualcomm's
> firmware doesn't make writeable to the kernel.
> 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Connor Abbott 
> ---

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 10/10] arm64: dts: qcom: Add AYN Odin 2

[Konrad Dybcio]

On 24.04.2024 5:29 PM, Xilin Wu via B4 Relay wrote:
> From: Xilin Wu 
> 
> AYN Odin 2 is a gaming handheld based on QCS8550, which is derived
> from SM8550 but without modem RF system.
> 
> This commit brings support for:
> * Remoteprocs
> * UFS storage
> * SD Card
> * Type-C with USB3 10Gbps and DisplayPort (4-lane requires a pending
>   patch)
> * PCIe0 (Wi-Fi requires the pending pwrseq series)
> * Bluetooth
> * Regulators
> * Integrated fan with automatic speed control based on CPU temperature
> * Power and volume keys
> * M1, M2 buttons
> * HDMI output up to 1080p 60hz
> * four groups of RGB lights
> * GPU
> * Internal DSI display with touchscreen
> 
> Signed-off-by: Xilin Wu 
> ---

[...]

> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 86>;
> + brightness-levels = <1023 0>;

Huh? Is min/max swapped?

> + num-interpolated-steps = <1023>;
> + default-brightness-level = <600>;
> + power-supply = <_pwr>;
> + enable-gpios = <_gpios 5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_backlight_default>;

property-n
property-names

[...]

> + cooling-maps {
> + map0 {
> + trip = <_active0>;
> + cooling-device = < 0 1>;
> + };

Please adda a newline between each subnode

[...]

> + /* Setting regulator-allow-set-load here will crash the device 
> */

??

> + vreg_l17b_2p5: ldo17 {
> + regulator-name = "vreg_l17b_2p5";
> + regulator-min-microvolt = <2504000>;
> + regulator-max-microvolt = <2504000>;
> + regulator-initial-mode = ;
> + };
> + };
> +

[...]

> +
> + backlight = <>;
> + /* touchscreen and display panel share the same reset gpio! */
> + reset-gpios = < 133 GPIO_ACTIVE_LOW>;

Perhaps you would be interested in drm_panel_follower

[...]

> +
> +_2 {
> + cd-gpios = <_gpios 12 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_default _card_det_n>;
> + pinctrl-1 = <_sleep _card_det_n>;
> + vmmc-supply = <_l9b_2p9>;
> + vqmmc-supply = <_l8b_1p8>;
> + bus-width = <4>;
> + no-sdio;
> + no-mmc;
> +
> + /* SDR104 does seem to be working on this device*/
> + /delete-property/ sdhci-caps-mask;

Eeeh.. I'm not sure about this. Maybe it still has some issues that
don't manifest immediately.

[...]

> + {
> + status = "okay";
> +
> +/* Gamepad controlled by onboard MCU */

As in, that MCU is connected to 8550 through this UART port?

Konrad

[jira] [Updated] (MSKINS-245) Maven Site 4 will break code highlight of site generated by Markdown

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSKINS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated MSKINS-245:
---
Component/s: Fluido Skin

> Maven Site 4 will break code highlight of site generated by Markdown
> 
>
> Key: MSKINS-245
> URL: https://issues.apache.org/jira/browse/MSKINS-245
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Fluido Skin
>Reporter: Xavi Lee
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: maven-site-3.png, maven-site-4.png, test-v3.html, 
> test-v4.html
>
>
> repro repo https://github.com/awxiaoxian2020/code-render-bug
> master branch is Maven Site 3 with Fluido skin 1
> v4 branch is Maven Site 4 with Fluido skin 2.
> Open their respective `target/site/test.html` files in local to see the 
> rendered result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MSKINS-245) Maven Site 4 will break code highlight of site generated by Markdown

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSKINS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated MSKINS-245:
---
Fix Version/s: fluido-2.0.0-M9
   fluido-2.0.0

> Maven Site 4 will break code highlight of site generated by Markdown
> 
>
> Key: MSKINS-245
> URL: https://issues.apache.org/jira/browse/MSKINS-245
> Project: Maven Skins
>  Issue Type: Bug
>  Components: Fluido Skin
>Reporter: Xavi Lee
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: fluido-2.0.0-M9, fluido-2.0.0
>
> Attachments: maven-site-3.png, maven-site-4.png, test-v3.html, 
> test-v4.html
>
>
> repro repo https://github.com/awxiaoxian2020/code-render-bug
> master branch is Maven Site 3 with Fluido skin 1
> v4 branch is Maven Site 4 with Fluido skin 2.
> Open their respective `target/site/test.html` files in local to see the 
> rendered result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[plasmashell] [Bug 486260] When the panel's floating mode is disabled, the system tray applets (nm-applet, clipper) do not work.

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=486260

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #1 from Konrad Materka  ---
It is probably the same as Bug 485456. Can you add more details if your issue
is something different?

-- 
You are receiving this mail because:
You are watching all bug changes.

[Bug 2063954] [NEW] gimp crashed on quit

[Marcel J. Konrad]

Public bug reported:

imported gif image, overwrote it, quit gimp, chose "discard changes" on
exit. Everything okay, but kde told me gimp crashed. Memory access
error. Hope this helps.

ubuntu 24.04
```
GNU Image Manipulation Program version 2.10.36
git-describe: GIMP_2_10_36
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
13.2.0-23ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-13 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-13-OiuXZC/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-OiuXZC/gcc-13-13.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu3) 

# Libraries #
using babl version 0.1.108 (compiled against version 0.1.108)
using GEGL version 0.4.48 (compiled against version 0.4.48)
using GLib version 2.80.0 (compiled against version 2.80.0)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.52.1 (compiled against version 1.52.1)
using Fontconfig version 2.15.0 (compiled against version 2.15.0)
using Cairo version 1.18.0 (compiled against version 1.18.0)

```
> fatal error: Speicherzugriffsfehler

Stack trace:
```

# Stack traces obtained from PID 3779 - Thread 3779 #


This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) [answered N; input not from 
terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[New LWP 3808]
[New LWP 3794]
[New LWP 3791]
[New LWP 3789]
[New LWP 3785]
[New LWP 3784]
[New LWP 3783]
[New LWP 3782]
[New LWP 3781]
[New LWP 3780]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7b6b7bf1ba9a in __GI___libc_read (nbytes=256, buf=0x7ffd7ac725f0, fd=15) 
at ../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame 
* 1Thread 0x7b6b7b4ef640 (LWP 3779) "gimp-2.10"0x7b6b7bf1ba9a in 
__GI___libc_read (nbytes=256, buf=0x7ffd7ac725f0, fd=15) at 
../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7b6b5b4006c0 (LWP 3808) "swap writer"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7b6b5aa006c0 (LWP 3794) "gimp-2.10"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7b6b5be006c0 (LWP 3791) "gimp-2.10"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7b6b658006c0 (LWP 3789) "async"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7b6b72e006c0 (LWP 3785) "gdbus"0x7b6b7bf1b4cd in 
__GI___poll (fds=0x7b6b54000b90, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7b6b738006c0 (LWP 3784) "gmain"0x7b6b7bf1b4cd in 
__GI___poll (fds=0x5d3689517990, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  8Thread 0x7b6b78a006c0 (LWP 3783) "pool-spawner" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7b6b794006c0 (LWP 3782) "worker"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  10   Thread 0x7b6b79e006c0 (LWP 3781) "worker"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  11   Thread 0x7b6b7a8006c0 (LWP 3780) "worker"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 11 (Thread 0x7b6b7a8006c0 (LWP 3780) "worker"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7b6b7c20340d in g_cond_wait () from 

[Bug 2063954] [NEW] gimp crashed on quit

[Marcel J. Konrad]

Public bug reported:

imported gif image, overwrote it, quit gimp, chose "discard changes" on
exit. Everything okay, but kde told me gimp crashed. Memory access
error. Hope this helps.

ubuntu 24.04
```
GNU Image Manipulation Program version 2.10.36
git-describe: GIMP_2_10_36
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
13.2.0-23ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-13 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-13-OiuXZC/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-OiuXZC/gcc-13-13.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu3) 

# Libraries #
using babl version 0.1.108 (compiled against version 0.1.108)
using GEGL version 0.4.48 (compiled against version 0.4.48)
using GLib version 2.80.0 (compiled against version 2.80.0)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.52.1 (compiled against version 1.52.1)
using Fontconfig version 2.15.0 (compiled against version 2.15.0)
using Cairo version 1.18.0 (compiled against version 1.18.0)

```
> fatal error: Speicherzugriffsfehler

Stack trace:
```

# Stack traces obtained from PID 3779 - Thread 3779 #


This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) [answered N; input not from 
terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[New LWP 3808]
[New LWP 3794]
[New LWP 3791]
[New LWP 3789]
[New LWP 3785]
[New LWP 3784]
[New LWP 3783]
[New LWP 3782]
[New LWP 3781]
[New LWP 3780]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7b6b7bf1ba9a in __GI___libc_read (nbytes=256, buf=0x7ffd7ac725f0, fd=15) 
at ../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame 
* 1Thread 0x7b6b7b4ef640 (LWP 3779) "gimp-2.10"0x7b6b7bf1ba9a in 
__GI___libc_read (nbytes=256, buf=0x7ffd7ac725f0, fd=15) at 
../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7b6b5b4006c0 (LWP 3808) "swap writer"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7b6b5aa006c0 (LWP 3794) "gimp-2.10"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7b6b5be006c0 (LWP 3791) "gimp-2.10"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7b6b658006c0 (LWP 3789) "async"syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7b6b72e006c0 (LWP 3785) "gdbus"0x7b6b7bf1b4cd in 
__GI___poll (fds=0x7b6b54000b90, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  7Thread 0x7b6b738006c0 (LWP 3784) "gmain"0x7b6b7bf1b4cd in 
__GI___poll (fds=0x5d3689517990, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  8Thread 0x7b6b78a006c0 (LWP 3783) "pool-spawner" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7b6b794006c0 (LWP 3782) "worker"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  10   Thread 0x7b6b79e006c0 (LWP 3781) "worker"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  11   Thread 0x7b6b7a8006c0 (LWP 3780) "worker"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 11 (Thread 0x7b6b7a8006c0 (LWP 3780) "worker"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7b6b7c20340d in g_cond_wait () from 

Re: [PATCH v2 6/6] drm/msm/a7xx: Add missing register writes from downstream

[Konrad Dybcio]

On 26.04.2024 8:34 PM, Connor Abbott wrote:
> This isn't known to fix anything yet, but it's a good idea to add it.
> 
> Signed-off-by: Connor Abbott 
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 4a3b12b20802..d88ec857f1cb 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1953,6 +1953,14 @@ static int hw_init(struct msm_gpu *gpu)
> BIT(6) | BIT(5) | BIT(3) | BIT(2) | BIT(1));
>   }
>  
> + if (adreno_is_a750(adreno_gpu)) {
> + gpu_rmw(gpu, REG_A6XX_RB_CMP_DBG_ECO_CNTL, BIT(19), BIT(19));

"/* Disable ubwc merged UFC request feature */"

> +
> + gpu_write(gpu, REG_A6XX_TPL1_DBG_ECO_CNTL1, 0xc0700);

"/* Enable TP flaghint and other performance settings */"

> + } else if (adreno_is_a7xx(adreno_gpu)) {
> + gpu_rmw(gpu, REG_A6XX_RB_CMP_DBG_ECO_CNTL, BIT(19), BIT(19));

This is supposed to be bit(11) on !A750:

"/* Disable non-ubwc read reqs from passing write reqs */"

Konrad

Re: [PATCH v2 5/6] drm/msm: Add MSM_PARAM_RAYTRACING uapi

[Konrad Dybcio]

On 26.04.2024 8:34 PM, Connor Abbott wrote:
> Expose the value of the software fuse to userspace.
> 
> Signed-off-by: Connor Abbott 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
>  include/uapi/drm/msm_drm.h  | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 074fb498706f..99ad651857b2 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -376,6 +376,9 @@ int adreno_get_param(struct msm_gpu *gpu, struct 
> msm_file_private *ctx,
>   case MSM_PARAM_HIGHEST_BANK_BIT:
>   *value = adreno_gpu->ubwc_config.highest_bank_bit;
>   return 0;
> + case MSM_PARAM_RAYTRACING:
> + *value = adreno_gpu->has_ray_tracing;
> + return 0;

I'd personally go with MSM_PARAM_FEATURES as a u64 bitmap, but it's
not me that'll have to deal with this on the userland side, so:

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH v2 4/6] drm/msm/a7xx: Initialize a750 "software fuse"

[Konrad Dybcio]

On 26.04.2024 8:34 PM, Connor Abbott wrote:
> On all Qualcomm platforms with a7xx GPUs, qcom_scm provides a method to
> initialize cx_mem. Copy this from downstream (minus BCL which we
> currently don't support). On a750, this includes a new "fuse" register
> which can be used by qcom_scm to fuse off certain features like
> raytracing in software. The fuse is default off, and is initialized by
> calling the method. Afterwards we have to read it to find out which
> features were enabled.
> 
> Signed-off-by: Connor Abbott 
> ---

[...]

> +static void a7xx_sw_fuse_violation_irq(struct msm_gpu *gpu)
> +{
> + u32 status;
> +
> + status = gpu_read(gpu, REG_A7XX_RBBM_SW_FUSE_INT_STATUS);
> + gpu_write(gpu, REG_A7XX_RBBM_SW_FUSE_INT_MASK, 0);
> +
> + dev_err_ratelimited(>pdev->dev, "SW fuse violation 
> status=%8.8x\n", status);
> +
> + /* Ignore FASTBLEND violations, because the HW will silently fall back
> +  * to legacy blending.

/*
 * foo



> +  */
> + if (status & (A7XX_CX_MISC_SW_FUSE_VALUE_RAYTRACING |
> +   A7XX_CX_MISC_SW_FUSE_VALUE_LPAC)) {
> + del_timer(>hangcheck_timer);
> +
> + kthread_queue_work(gpu->worker, >recover_work);
> + }
> +}
> +
>  static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
>  {
>   struct msm_drm_private *priv = gpu->dev->dev_private;
> @@ -2384,6 +2406,9 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
>   if (status & A6XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS)
>   dev_err_ratelimited(>pdev->dev, "UCHE | Out of bounds 
> access\n");
>  
> + if (status & A6XX_RBBM_INT_0_MASK_SWFUSEVIOLATION)

Does this field actualy exist on a6 too?

> + a7xx_sw_fuse_violation_irq(gpu);
> +
>   if (status & A6XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS)
>   msm_gpu_retire(gpu);
>  
> @@ -2525,6 +2550,59 @@ static void a6xx_llc_slices_init(struct 
> platform_device *pdev,
>   a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
>  }
>  
> +static int a7xx_cx_mem_init(struct a6xx_gpu *a6xx_gpu)
> +{
> + struct adreno_gpu *adreno_gpu = _gpu->base;
> + struct msm_gpu *gpu = _gpu->base;
> + u32 fuse_val;
> + int ret = 0;
> +
> + if (adreno_is_a750(adreno_gpu)) {
> + /* Assume that if qcom scm isn't available, that whatever
> +  * replacement allows writing the fuse register ourselves.
> +  * Users of alternative firmware need to make sure this
> +  * register is writeable or indicate that it's not somehow.
> +  * Print a warning because if you mess this up you're about to
> +  * crash horribly.
> +  */
> + if (!qcom_scm_is_available()) {
> + dev_warn_once(gpu->dev->dev,
> + "SCM is not available, poking fuse register\n");
> + a6xx_llc_write(a6xx_gpu, REG_A7XX_CX_MISC_SW_FUSE_VALUE,
> + A7XX_CX_MISC_SW_FUSE_VALUE_RAYTRACING |
> + A7XX_CX_MISC_SW_FUSE_VALUE_FASTBLEND |
> + A7XX_CX_MISC_SW_FUSE_VALUE_LPAC);
> + adreno_gpu->has_ray_tracing = true;

I'm not 100% sure. I'm afraid there may be SKUs with RT cores fused
off (as in, cut off from the rest, not "indicated unavailable") or
otherwise dysfunctional..

My guess would be that TZ probably has some sort of a LUT/match table
based on other SoC identifiers

> + return 0;
> + }
> +
> + ret = qcom_scm_gpu_init_regs(QCOM_SCM_GPU_ALWAYS_EN_REQ |
> +  QCOM_SCM_GPU_TSENSE_EN_REQ);
> + if (ret)
> + return ret;
> +
> + /* On a750 raytracing may be disabled by the firmware, find out 
> whether
> +  * that's the case. The scm call above sets the fuse register.
> +  */
> + fuse_val = a6xx_llc_read(a6xx_gpu, 
> REG_A7XX_CX_MISC_SW_FUSE_VALUE);
> + adreno_gpu->has_ray_tracing =
> + !!(fuse_val & A7XX_CX_MISC_SW_FUSE_VALUE_RAYTRACING);
> + } else {
> + if (adreno_is_a740(adreno_gpu)) {
> + /* Raytracing is always enabled on a740 */
> +     adreno_gpu->has_ray_tracing = true;
> + }
> +
> + if (!qcom_scm_is_available())
> + return 0;
> +
> + ret = qcom_scm_gpu_init_regs(QCOM_SCM_GPU_ALWAYS_EN_REQ);
> + }
> +
> + return ret;

if (qcom_scm_is_available())
return qcom_scm_gpu_init_regs(QCOM_SCM_GPU_ALWAYS_EN_REQ);
}

return 0;

?

Konrad

Re: [PATCH v2 2/6] firmware: qcom_scm: Add gpu_init_regs call

[Konrad Dybcio]

On 26.04.2024 8:34 PM, Connor Abbott wrote:
> This will used by drm/msm.
> 
> Signed-off-by: Connor Abbott 
> ---

[...]

> +/**
> + * Request TZ to program set of access controlled registers necessary
> + * irrespective of any features
> + */

kerneldoc abuse, please make it a regular comment

Konrad

Re: [PATCH v2 1/6] arm64: dts: qcom: sm8650: Fix GPU cx_mem size

[Konrad Dybcio]

On 26.04.2024 8:33 PM, Connor Abbott wrote:
> This is doubled compared to previous GPUs. We can't access the new
> SW_FUSE_VALUE register without this.
> 
> Fixes: db33633b05c0 ("arm64: dts: qcom: sm8650: add GPU nodes")
> Signed-off-by: Connor Abbott 
> ---

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 6/7] arm64: dts: qcom: msm8976: Use mboxes properties for APCS

[Konrad Dybcio]

On 4/24/24 18:23, Luca Weiss wrote:

Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 7/7] arm64: dts: qcom: msm8994: Use mboxes properties for APCS

[Konrad Dybcio]

On 4/24/24 18:24, Luca Weiss wrote:

Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 5/7] arm64: dts: qcom: msm8953: Use mboxes properties for APCS

[Konrad Dybcio]

On 4/24/24 18:23, Luca Weiss wrote:

Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 4/7] arm64: dts: qcom: msm8939: Use mboxes properties for APCS

[Konrad Dybcio]

On 4/24/24 18:23, Luca Weiss wrote:

Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 3/7] arm64: dts: qcom: msm8916: Use mboxes properties for APCS

[Konrad Dybcio]

On 4/24/24 18:23, Luca Weiss wrote:

Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 2/7] ARM: dts: qcom: msm8974: Use mboxes properties for APCS

[Konrad Dybcio]

On 4/24/24 18:23, Luca Weiss wrote:

Instead of passing the syscon to the various nodes, use the mbox
interface using the mboxes property.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH RFC 2/2] soc: qcom: smsm: Support using mailbox interface

[Konrad Dybcio]

On 4/24/24 19:21, Luca Weiss wrote:

Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to syscon.

Signed-off-by: Luca Weiss 
---


Looks good!

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 05/10] arm64: dts: qcom: pmk8550: Add PWM controller

[Konrad Dybcio]

On 4/24/24 17:29, Xilin Wu via B4 Relay wrote:

From: Xilin Wu 

Add the PWM function to the pmk8550 dtsi, which is usually used
to control PWM backlight on platforms using this PMIC.

Signed-off-by: Xilin Wu 
---


Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 02/10] pwm: Add SI-EN SN3112 PWM support

[Konrad Dybcio]

On 4/24/24 17:29, Xilin Wu via B4 Relay wrote:

From: Junhao Xie 

Add a new driver for the SI-EN SN3112 12-channel 8-bit PWM LED controller.

Signed-off-by: Junhao Xie 
---


[...]


+static int sn3112_set_en_reg(struct sn3112 *priv, unsigned int channel,
+bool enabled, bool write)
+{
+   unsigned int reg, bit;
+
+   if (channel >= SN3112_CHANNELS)
+   return -EINVAL;
+
+   /* LED_EN1: BIT5:BIT3 = OUT3:OUT1 */
+   if (channel >= 0 && channel <= 2)
+   reg = 0, bit = channel + 3;
+   /* LED_EN2: BIT5:BIT0 = OUT9:OUT4 */
+   else if (channel >= 3 && channel <= 8)
+   reg = 1, bit = channel - 3;
+   /* LED_EN3: BIT2:BIT0 = OUT12:OUT10 */
+   else if (channel >= 9 && channel <= 11)
+   reg = 2, bit = channel - 9;
+   else
+   return -EINVAL;
+
+   dev_dbg(priv->pdev, "channel %u enabled %u\n", channel, enabled);
+   dev_dbg(priv->pdev, "reg %u bit %u\n", reg, bit);
+   if (enabled)
+   set_bit(bit, (ulong *)>pwm_en_reg[reg]);
+   else
+   clear_bit(bit, (ulong *)>pwm_en_reg[reg]);
+   dev_dbg(priv->pdev, "set enable reg %u to %u\n", reg,
+   priv->pwm_en_reg[reg]);
+
+   if (!write)
+   return 0;
+   return sn3112_write_reg(priv, SN3112_REG_PWM_EN + reg,
+   priv->pwm_en_reg[reg]);


This looks like a weird reimplementation of regmap_update_bits



+}
+
+static int sn3112_set_val_reg(struct sn3112 *priv, unsigned int channel,
+ uint8_t val, bool write)
+{
+   if (channel >= SN3112_CHANNELS)
+   return -EINVAL;
+   priv->pwm_val[channel] = val;
+   dev_dbg(priv->pdev, "set value reg %u to %u\n", channel,
+   priv->pwm_val[channel]);
+
+   if (!write)
+   return 0;


There's only a single call, with write == true


+   return sn3112_write_reg(priv, SN3112_REG_PWM_VAL + channel,
+   priv->pwm_val[channel]);
+}
+
+static int sn3112_write_all(struct sn3112 *priv)
+{
+   int i, ret;
+
+   /* regenerate enable register values */
+   for (i = 0; i < SN3112_CHANNELS; i++) {
+   ret = sn3112_set_en_reg(priv, i, priv->pwm_en[i], false);
+   if (ret != 0)
+   return ret;
+   }
+
+   /* use random value to clear all registers */
+   ret = sn3112_write_reg(priv, SN3112_REG_RESET, 0x66);
+   if (ret != 0)


if (ret) is the same as if (ret != 0)

[...]


+
+   /* use random value to apply changes */
+   ret = sn3112_write_reg(priv, SN3112_REG_APPLY, 0x66);


"a random value"? sounds suspicious..


+   if (ret != 0)
+   return ret;
+
+   dev_dbg(priv->pdev, "reinitialized\n");


Please remove such "got here" messages once you're done with testing
the driver locally

[...]


+
+#if IS_ENABLED(CONFIG_GPIOLIB)


I'm not sure this would be ever disabled on any embedded system nowadays.
Especially with I2C.

[...]


+
+   dev_info(>dev,
+"Found SI-EN SN3112 12-channel 8-bit PWM LED controller\n");


This sort of message only makes sense if there's a CHIP_ID register that
you can actually validate. If you bind this driver to a device at the same
expected address, it will say it's there even if it's not.



+   return 0;
+}
+
+static void sn3112_pwm_remove(struct i2c_client *client)
+{
+   struct pwm_chip *chip = i2c_get_clientdata(client);
+   struct sn3112 *priv = pwmchip_get_drvdata(chip);
+
+   dev_dbg(priv->pdev, "remove\n");
+
+   /* set software enable register */
+   sn3112_write_reg(priv, SN3112_REG_ENABLE, 0);
+
+   /* use random value to apply changes */
+   sn3112_write_reg(priv, SN3112_REG_APPLY, 0x66);
+
+#if IS_ENABLED(CONFIG_GPIOLIB)
+   /* enable hardware shutdown pin */
+   if (priv->sdb)
+   gpiod_set_value(priv->sdb, 1);
+#endif
+
+   /* power-off sn5112 power vdd */
+   regulator_disable(priv->vdd);
+
+   pwmchip_remove(chip);


devm_pwmchip_add?

Konrad

[plasmashell] [Bug 485971] Keepass tray icon breaks nearby icon, also tooltip is messed up

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485971

Konrad Materka  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=433079

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 433079] On Wayland container windows created by XEmbedSNIProxy are not stacked below root window

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=433079

Konrad Materka  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=485971

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485587] Tray icons on-click popups not visible

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485587

--- Comment #7 from Konrad Materka  ---
Duplicate of Bug 485456?

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485456] Qith Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||a...@digitalsignalperson.co
   ||m

--- Comment #15 from Konrad Materka  ---
*** Bug 485983 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485983] Clicking system tray icons results in tiny (1x1?) pop-out menus

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485983

Konrad Materka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|REPORTED|RESOLVED

--- Comment #2 from Konrad Materka  ---


*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485456] Qith Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||aaron...@gmail.com

--- Comment #14 from Konrad Materka  ---
*** Bug 486042 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 486042] Show hidden icons invisible.

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=486042

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Konrad Materka  ---


*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485958] Problems with drop down in panel on top of screen.

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485958

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Konrad Materka  ---


*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485456] Qith Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||achillesgreekhe...@gmail.co
   ||m

--- Comment #13 from Konrad Materka  ---
*** Bug 485958 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485456] Qith Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||rlpayto...@gmail.com

--- Comment #12 from Konrad Materka  ---
*** Bug 485780 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485780] system tray does not open. When creating a new panel with a system tray it sometimes works and brings back its functionality but then eventually breaks for no apparent reaso

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485780

Konrad Materka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|REPORTED|RESOLVED

--- Comment #2 from Konrad Materka  ---


*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485456] Qith Qt 6.7, System Tray popup is inappropriately resized to a tiny nub

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485456

Konrad Materka  changed:

   What|Removed |Added

 CC||hello48...@gmail.com

--- Comment #11 from Konrad Materka  ---
*** Bug 485874 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 485874] System tray's popup is too small

[Konrad Materka]

https://bugs.kde.org/show_bug.cgi?id=485874

Konrad Materka  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Konrad Materka  ---
Look like duplicate of Bug 485456

*** This bug has been marked as a duplicate of bug 485456 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [PATCH v3 4/4] arm64: dts: qcom: msm8976: Add WCNSS node

[Konrad Dybcio]

On 4/13/24 19:03, Adam Skladowski wrote:

Add node describing wireless connectivity subsystem.

Signed-off-by: Adam Skladowski 
---


[...]


+   wcnss_wifi: wifi {
+   compatible = "qcom,wcnss-wlan";
+
+   interrupts = ,
+;
+   interrupt-names = "tx", "rx";
+
+   qcom,smem-states = <_smsm 10>, 
<_smsm 9>;
+   qcom,smem-state-names = 
"tx-enable",
+   
"tx-rings-empty";


Since you're already going to resend, please keep one entry per line,
this fragment is very inconsistent

looks good otherwise

Konrad

Re: [PATCH v3 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU

[Konrad Dybcio]

On 4/13/24 19:03, Adam Skladowski wrote:

Add Adreno GPU node.

Signed-off-by: Adam Skladowski 
---


[...]


+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = <_opp_low_svs>;
+   opp-supported-hw = <0xff>;


Doesn't look like this platform had any speed binning going on, can drop?

Konrad

Re: [PATCH v3 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes

[Konrad Dybcio]

On 4/13/24 19:03, Adam Skladowski wrote:

Add MDSS nodes to support displays on MSM8976 SoC.

Signed-off-by: Adam Skladowski 
---


[...]


+
+   mdp_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-17778 {
+   opp-hz = /bits/ 64 <17778>;
+   required-opps = 
<_opp_svs>;
+   };
+
+   opp-27000 {
+   opp-hz = /bits/ 64 <27000>;
+   required-opps = 
<_opp_svs_plus>;
+   };
+
+   opp-32000 {
+   opp-hz = /bits/ 64 <32000>;
+   required-opps = 
<_opp_nom>;
+   };
+   opp-36000 {


Missing a newline above

[...]



+   dsi0_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-12500 {
+   opp-hz = /bits/ 64 <12500>;
+   required-opps = 
<_opp_svs>;
+
+   };


You can borrow it from here

Looks reasonable otherwise

Konrad

[jira] [Comment Edited] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840140#comment-17840140
 ] 

Konrad Windszus edited comment on JCRVLT-751 at 4/23/24 3:32 PM:
-

In my tests the node path
{code}
/home/users/test/_6k_test-user-a
{code} is exported as ZIP path
{code}
/home/users/test/__6k_test-user-a
{code}
(which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during 
import.


was (Author: kwin):
In my tests the node path {{/home/users/test/_6k_test-user-a}} is exported as 
ZIP path {{/home/users/test/__6k_test-user-a}} (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during 
import.

> Can't import a user with parent folder that starts with _ and includes 
> another _ 
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840140#comment-17840140
 ] 

Konrad Windszus commented on JCRVLT-751:


In my tests the node path `/home/users/test/_6k_test-user-a` is exported as ZIP 
path `/home/users/test/__6k_test-user-a` (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path `/home/users/test/_6k_test-user-a` during 
import.

> Can't import a user with parent folder that starts with _ and includes 
> another _ 
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840140#comment-17840140
 ] 

Konrad Windszus edited comment on JCRVLT-751 at 4/23/24 3:31 PM:
-

In my tests the node path {{/home/users/test/_6k_test-user-a}} is exported as 
ZIP path {{/home/users/test/__6k_test-user-a}} (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during 
import.


was (Author: kwin):
In my tests the node path `/home/users/test/_6k_test-user-a` is exported as ZIP 
path `/home/users/test/__6k_test-user-a` (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path `/home/users/test/_6k_test-user-a` during 
import.

> Can't import a user with parent folder that starts with _ and includes 
> another _ 
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PATCH v2 3/3] arm64: dts: qcom: sm7225-fairphone-fp4: Enable USB role switching

[Konrad Dybcio]

On 3/29/24 13:26, Luca Weiss wrote:

Configure the Type-C and VBUS regulator on PM7250B and wire it up to the
USB PHY, so that USB role and orientation switching works.

For now USB Power Delivery properties are skipped / disabled, so that
the (presumably) bootloader-configured charger doesn't get messed with
and we can charge the phone with at least some amount of power.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

nits:


+   usb-role-switch;


this is a common property of the dwc3 host


[...]


vdda-phy-supply = <_l22a>;
vdda-pll-supply = <_l16a>;
+   orientation-switch;


and this is a common property of the QMPPHY

Could you move them to the node definition?

Konrad

Re: [PATCH 1/2] arm64: dts: qcom: pmi632: Add vibrator

[Konrad Dybcio]

On 4/18/24 12:03, Luca Weiss wrote:

On Thu Apr 18, 2024 at 12:01 PM CEST, Konrad Dybcio wrote:

On 18.04.2024 8:36 AM, Luca Weiss wrote:

Add a node for the vibrator module found inside the PMI632.

Signed-off-by: Luca Weiss 
---


Reviewed-by: Konrad Dybcio 

On a side note, this is a totally configuration-free peripheral that doesn't do
anything crazy until manually configured.

In the slow quest to be (hopefully) more sane about the defaults, should we keep
them enabled by default? Bjorn?


But many (most?) devices don't have a vibration motor connected to
PMI632, some (like devboards) don't have anything, and other phones have
a separate chip that controls the vibration motor.

Enabling this by default would mean all devices with PMI632 would get an
input device for the vibrator that probably doesn't work?


Fair

Konrad

[PATCH 0/2] Adreno MAINTAINERS modifications

[Konrad Dybcio]

Separate out Adreno from the rest of the drm/msm driver, add myself
as a reviewer for the former.

Signed-off-by: Konrad Dybcio 
---
Konrad Dybcio (2):
  MAINTAINERS: Add a separate entry for Qualcomm Adreno GPU drivers
  MAINTAINERS: Add Konrad Dybcio as a reviewer for the Adreno driver

 MAINTAINERS | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)
---
base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e
change-id: 20240423-topic-adreno_maintainers-4d220cba75e8

Best regards,
-- 
Konrad Dybcio 

[PATCH 2/2] MAINTAINERS: Add Konrad Dybcio as a reviewer for the Adreno driver

[Konrad Dybcio]

Add myself as a reviewer for Adreno driver changes.

Signed-off-by: Konrad Dybcio 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 179f989a1e4b..80aa006f10bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6888,6 +6888,7 @@ F:drivers/gpu/drm/tiny/panel-mipi-dbi.c
 DRM DRIVER for Qualcomm Adreno GPUs
 M: Rob Clark 
 R: Sean Paul 
+R: Konrad Dybcio 
 L: linux-arm-...@vger.kernel.org
 L: dri-de...@lists.freedesktop.org
 L: freedreno@lists.freedesktop.org

-- 
2.40.1

[PATCH 1/2] MAINTAINERS: Add a separate entry for Qualcomm Adreno GPU drivers

[Konrad Dybcio]

The msm driver is.. gigantic and covers display hardware (incl. things
concerning (e)DP, DSI, HDMI), as well as the entire lineup of Adreno
GPUs (with hw bringup, memory mappings, userspace interaction etc.).

Because of that, people listed as M:/R: receive patches concerning
drivers for any part of the display block OR the GPU. Separate the
latter, as it's both a functionally separate block and is of
interest to different folks.

Signed-off-by: Konrad Dybcio 
---
 MAINTAINERS | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index de49e2d24770..179f989a1e4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6885,7 +6885,24 @@ T:   git 
https://gitlab.freedesktop.org/drm/misc/kernel.git
 F: Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
 F: drivers/gpu/drm/tiny/panel-mipi-dbi.c
 
-DRM DRIVER FOR MSM ADRENO GPU
+DRM DRIVER for Qualcomm Adreno GPUs
+M: Rob Clark 
+R: Sean Paul 
+L: linux-arm-...@vger.kernel.org
+L: dri-de...@lists.freedesktop.org
+L: freedreno@lists.freedesktop.org
+S: Maintained
+B: https://gitlab.freedesktop.org/drm/msm/-/issues
+T: git https://gitlab.freedesktop.org/drm/msm.git
+F: Documentation/devicetree/bindings/display/msm/gpu.yaml
+F: drivers/gpu/drm/msm/adreno/
+F: drivers/gpu/drm/msm/msm_gpu.*
+F: drivers/gpu/drm/msm/msm_gpu_devfreq.*
+F: drivers/gpu/drm/msm/msm_ringbuffer.*
+F: drivers/gpu/drm/msm/registers/adreno/
+F: include/uapi/drm/msm_drm.h
+
+DRM DRIVER for Qualcomm display hardware
 M: Rob Clark 
 M: Abhinav Kumar 
 M: Dmitry Baryshkov 

-- 
2.40.1

[PATCH 2/2] drm/msm/dsi: Remove dsi_phy_write_[un]delay()

[Konrad Dybcio]

These are dummy wrappers that do literally nothing interesting.
Remove them.

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |  3 --
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c |  3 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 81 +++---
 3 files changed, 54 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7df4d852e6fa..109d767a476b 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -12,9 +12,6 @@
 
 #include "dsi.h"
 
-#define dsi_phy_write_udelay(offset, data, delay_us) { writel((data), 
(offset)); udelay(delay_us); }
-#define dsi_phy_write_ndelay(offset, data, delay_ns) { writel((data), 
(offset)); ndelay(delay_ns); }
-
 struct msm_dsi_phy_ops {
int (*pll_init)(struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy,
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index b128c4acea23..1723f0e4faa4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -374,7 +374,8 @@ static void pll_14nm_software_reset(struct dsi_pll_14nm 
*pll_14nm)
writel(0, cmn_base + REG_DSI_14nm_PHY_CMN_PLL_CNTRL);
 
/* pll sw reset */
-   dsi_phy_write_udelay(cmn_base + REG_DSI_14nm_PHY_CMN_CTRL_1, 0x20, 10);
+   writel(0x20, cmn_base + REG_DSI_14nm_PHY_CMN_CTRL_1);
+   udelay(10);
wmb();  /* make sure register committed */
 
writel(0, cmn_base + REG_DSI_14nm_PHY_CMN_CTRL_1);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index b3e914954f4a..db99526d11df 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -104,9 +104,10 @@ static void pll_28nm_software_reset(struct dsi_pll_28nm 
*pll_28nm)
 * Add HW recommended delays after toggling the software
 * reset bit off and back on.
 */
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_TEST_CFG,
-DSI_28nm_PHY_PLL_TEST_CFG_PLL_SW_RESET, 1);
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_TEST_CFG, 0x00, 1);
+   writel(DSI_28nm_PHY_PLL_TEST_CFG_PLL_SW_RESET, base + 
REG_DSI_28nm_PHY_PLL_TEST_CFG);
+   udelay(1);
+   writel(0, base + REG_DSI_28nm_PHY_PLL_TEST_CFG);
+   udelay(1);
 }
 
 /*
@@ -303,21 +304,25 @@ static int _dsi_pll_28nm_vco_prepare_hpm(struct 
dsi_pll_28nm *pll_28nm)
 * Add necessary delays recommended by hardware.
 */
val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 1);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(1);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(200);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 500);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(500);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(600);
 
for (i = 0; i < 2; i++) {
/* DSI Uniphy lock detect setting */
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
-0x0c, 100);
+   writel(0x0c, base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2);
+   udelay(100);
writel(0x0d, base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2);
 
/* poll for PLL ready status */
@@ -333,22 +338,28 @@ static int _dsi_pll_28nm_vco_prepare_hpm(struct 
dsi_pll_28nm *pll_28nm)
 * Add necessary delays recommended by hardware.
 */
val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 
1);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(1);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 
200);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(200);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 
250);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(250);
 
val &= ~DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28n

[PATCH 2/2] drm/msm/dsi: Remove dsi_phy_write_[un]delay()

[Konrad Dybcio]

These are dummy wrappers that do literally nothing interesting.
Remove them.

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |  3 --
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c |  3 +-
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 81 +++---
 3 files changed, 54 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index 7df4d852e6fa..109d767a476b 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -12,9 +12,6 @@
 
 #include "dsi.h"
 
-#define dsi_phy_write_udelay(offset, data, delay_us) { writel((data), 
(offset)); udelay(delay_us); }
-#define dsi_phy_write_ndelay(offset, data, delay_ns) { writel((data), 
(offset)); ndelay(delay_ns); }
-
 struct msm_dsi_phy_ops {
int (*pll_init)(struct msm_dsi_phy *phy);
int (*enable)(struct msm_dsi_phy *phy,
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
index b128c4acea23..1723f0e4faa4 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c
@@ -374,7 +374,8 @@ static void pll_14nm_software_reset(struct dsi_pll_14nm 
*pll_14nm)
writel(0, cmn_base + REG_DSI_14nm_PHY_CMN_PLL_CNTRL);
 
/* pll sw reset */
-   dsi_phy_write_udelay(cmn_base + REG_DSI_14nm_PHY_CMN_CTRL_1, 0x20, 10);
+   writel(0x20, cmn_base + REG_DSI_14nm_PHY_CMN_CTRL_1);
+   udelay(10);
wmb();  /* make sure register committed */
 
writel(0, cmn_base + REG_DSI_14nm_PHY_CMN_CTRL_1);
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
index b3e914954f4a..db99526d11df 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c
@@ -104,9 +104,10 @@ static void pll_28nm_software_reset(struct dsi_pll_28nm 
*pll_28nm)
 * Add HW recommended delays after toggling the software
 * reset bit off and back on.
 */
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_TEST_CFG,
-DSI_28nm_PHY_PLL_TEST_CFG_PLL_SW_RESET, 1);
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_TEST_CFG, 0x00, 1);
+   writel(DSI_28nm_PHY_PLL_TEST_CFG_PLL_SW_RESET, base + 
REG_DSI_28nm_PHY_PLL_TEST_CFG);
+   udelay(1);
+   writel(0, base + REG_DSI_28nm_PHY_PLL_TEST_CFG);
+   udelay(1);
 }
 
 /*
@@ -303,21 +304,25 @@ static int _dsi_pll_28nm_vco_prepare_hpm(struct 
dsi_pll_28nm *pll_28nm)
 * Add necessary delays recommended by hardware.
 */
val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 1);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(1);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 200);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(200);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 500);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(500);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_ENABLE;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 600);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(600);
 
for (i = 0; i < 2; i++) {
/* DSI Uniphy lock detect setting */
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2,
-0x0c, 100);
+   writel(0x0c, base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2);
+   udelay(100);
writel(0x0d, base + REG_DSI_28nm_PHY_PLL_LKDET_CFG2);
 
/* poll for PLL ready status */
@@ -333,22 +338,28 @@ static int _dsi_pll_28nm_vco_prepare_hpm(struct 
dsi_pll_28nm *pll_28nm)
 * Add necessary delays recommended by hardware.
 */
val = DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 
1);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(1);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_PWRGEN_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 
200);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(200);
 
val |= DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28nm_PHY_PLL_GLB_CFG, val, 
250);
+   writel(val, base + REG_DSI_28nm_PHY_PLL_GLB_CFG);
+   udelay(250);
 
val &= ~DSI_28nm_PHY_PLL_GLB_CFG_PLL_LDO_PWRDN_B;
-   dsi_phy_write_udelay(base + REG_DSI_28n