[Expo] Could not find any matches for app.notifee:core:+ as no versions of app.notifee:core are available.

I tried following the instructions here:
https://github.com/invertase/notifee/blob/main/docs-react-native/react-native/docs/installation.md
I tried following the solutions in this thread:
https://github.com/invertase/notifee/issues/350
These don't exist in my gradle-
org.gradle.parallel=true
org.gradle.configureondemand=true
I tried adding this-
maven {
            url "$rootDir/../node_modules/@notifee/react-native/android/libs"
        }

I tried following the solutions in this thread:
https://github.com/invertase/notifee/issues/911
I tried adding this-
"plugins": [
[
"expo-build-properties",
{
"android": {
"extraMavenRepos": [
"../../node_modules/@notifee/react-native/android/libs"
]
}
}
],
}

I am using react native with expo. The error message I'm getting:
FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':app:processDebugResources'.
> Could not resolve all task dependencies for configuration ':app:debugRuntimeClasspath'.
   > Could not find any matches for app.notifee:core:+ as no versions of app.notifee:core are available.
     Searched in the following locations:
       -<EMAIL_ADDRESS>       - file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/react-native/android/app/notifee/core/maven-metadata.xml
       - file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/jsc-android/dist/app/notifee/core/maven-metadata.xml
       - https://dl.google.com/dl/android/maven2/app/notifee/core/maven-metadata.xml
       - https://repo.maven.apache.org/maven2/app/notifee/core/maven-metadata.xml
       - https://www.jitpack.io/app/notifee/core/maven-metadata.xml
       - https://oss.sonatype.org/content/repositories/snapshots/app/notifee/core/maven-metadata.xml
     Required by:
         project :app > project :notifee_react-native

I am using expo 49, notifee 7.8.2, react native 72.6, api 34 on android

Pathing issue perhaps
It helpfully tells you where it's looking, for example:
       -<EMAIL_ADDRESS>       - file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/react-native/android/app/notifee/core/maven-metadata.xml
       - file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/jsc-android/dist/app/notifee/core/maven-metadata.xml

What do you find when you actually look there yourself? Where is the notifee/core/maven-metadata.xml file? If you locate it and make sure that location is in the extra repos, should work...

Pathing issue perhaps
It helpfully tells you where it's looking, for example:
       -<EMAIL_ADDRESS>       - file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/react-native/android/app/notifee/core/maven-metadata.xml
       - file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/jsc-android/dist/app/notifee/core/maven-metadata.xml

What do you find when you actually look there yourself? Where is the notifee/core/maven-metadata.xml file? If you locate it and make sure that location is in the extra repos, should work...

I don't see the maven-metadata.xml file anywhere actually. I have reinstalled multiple times. Is there a place to download it?

I tried adding this to my repositories
maven {
    url "/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/@notifee/react-native/android/libs"
}

I tried editing again by specifying the version and updated the maven url. Can you please point me how to fix this
The new error
`Could not determine the dependencies of task ':app:processDebugResources'.

Could not resolve all task dependencies for configuration ':app:debugRuntimeClasspath'.
Could not find app.notifee:core:202108261754.
Searched in the following locations:
-<EMAIL_ADDRESS>- file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/react-native/android/app/notifee/core/202108261754/core-202108261754.pom
- file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/jsc-android/dist/app/notifee/core/202108261754/core-202108261754.pom
- https://dl.google.com/dl/android/maven2/app/notifee/core/202108261754/core-202108261754.pom
- https://repo.maven.apache.org/maven2/app/notifee/core/202108261754/core-202108261754.pom
- https://www.jitpack.io/app/notifee/core/202108261754/core-202108261754.pom
- https://oss.sonatype.org/content/repositories/snapshots/app/notifee/core/202108261754/core-202108261754.pom
Required by:
project :app > project :notifee_react-native`

Gradle to specified version dependency and updated maven url
`import java.nio.file.Paths
buildscript {
// The Android Gradle plugin is only required when opening the android folder stand-alone.
// This avoids unnecessary downloads and potential conflicts when the library is included as a
// module dependency in an application project.
if (project == rootProject) {
repositories {
google()
mavenCentral()
}
dependencies {
  classpath("com.android.tools.build:gradle:7.0.3")
}

}
}
plugins {
id "io.invertase.gradle.build" version "1.5"
}
// https://github.com/facebook/react-native/blob/a70354df12ef71aec08583cca4f1fed5fb77d874/ReactAndroid/build.gradle#L168-L201
def findNodeModulePath(baseDir, packageName) {
def basePath = baseDir.toPath().normalize()
// Node's module resolution algorithm searches up to the root directory,
// after which the base path will be null
while (basePath) {
def candidatePath = Paths.get(basePath.toString(), "node_modules", packageName)
if (candidatePath.toFile().exists()) {
return candidatePath.toString()
}
basePath = basePath.getParent()
}
return null
}
def notifeeDir = findNodeModulePath(projectDir, "@notifee/react-native") ?: "$rootDir/../node_modules/@notifee/react-native"
println ":${project.name} @notifee/react-native found at $notifeeDir"
if (project.hasProperty('reactNativeProjects')) {
reactNativeProjects.each { dependent ->
project.evaluationDependsOn(dependent)
}
} else {
project.evaluationDependsOn(':app')
}
project.ext {
set('react-native', [
versions: [
android: [
minSdk    : 20,
targetSdk : 33,
compileSdk: 33,
// optional as gradle.buildTools comes with one by default
// overriding here though to match the version RN uses
// buildTools: "29.0.2"
],
],
])
}
android {
def agpVersion = com.android.Version.ANDROID_GRADLE_PLUGIN_VERSION
// Check AGP version for backward compatibility w/react-native versions still on gradle plugin 6
if (agpVersion.tokenize('.')[0].toInteger() >= 7) {
namespace = "io.invertase.notifee"
}
defaultConfig {
multiDexEnabled true
}
lintOptions {
disable 'GradleCompatible'
abortOnError false
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
buildTypes {
release {
consumerProguardFiles 'proguard-rules.pro'
}
}
compileSdkVersion = 33
buildToolsVersion = '33.0.0'
}
repositories {
google()
mavenCentral()
}
dependencies {
implementation 'androidx.concurrent:concurrent-futures:1.1.0' // https://developer.android.com/jetpack/androidx/releases/concurrent
implementation 'com.google.android.gms:play-services-tasks:18.0.1' // https://developers.google.com/android/guides/releases
implementation 'androidx.work:work-runtime:2.8.0' // https://developer.android.com/jetpack/androidx/releases/work
implementation 'org.greenrobot:eventbus:3.3.1' // https://github.com/greenrobot/EventBus/releases
implementation 'androidx.lifecycle:lifecycle-process:2.3.1'
implementation "app.notifee:core:202108261754"
}
ReactNative.shared.applyPackageVersion()
ReactNative.shared.applyDefaultExcludes()
ReactNative.module.applyAndroidVersions()
ReactNative.module.applyReactNativeDependency("api")
rootProject.allprojects {
repositories {
maven {
url "file:/Users/james/Documents/Workspace/Ultraviolet/ultraviolet-next/node_modules/@notifee/react-native/android/libs"
}
}
}
`

No I can't help directly sorry, I don't use Expo. But it looks like you are attempting to use a fully-qualified path, note the attempts above were with relative paths either to ../../ etc or rootDir
Play around with those until it's pointing in the right spot where you found the file
You know where the file is
The build system is telling you where it is looking
Playing with it until those two line up should be possible ?

I was able to fix it by editing my app.json under expo-build properties
    "plugins": [
      [
        "expo-build-properties",
        {
          "android": {
            "kotlinVersion": "1.8.0",
            "minSdkVersion": 24,
            "extraMavenRepos": [
              "../../../../node_modules/@notifee/react-native/android/libs"
              ]
          },
          "ios": {
            "deploymentTarget": "13.0"
          }
        }
      ],

I needed to add extra depth to the extraMavenRepos

@jp4u that is applicable if you are, for instance, in a monorepo and the package was hoisted. Makes sense I think

I was able to fix it by editing my app.json under expo-build properties, I modified the property extraMavenRepos
    "plugins": [
      [
        "expo-build-properties",
        {
          "android": {
            "kotlinVersion": "1.8.0",
            "minSdkVersion": 24,
            "extraMavenRepos": [
              "../../../../node_modules/@notifee/react-native/android/libs"
              ]
          },
          "ios": {
            "deploymentTarget": "13.0"
          }
        }
      ],

I needed to add extra depth to the extraMavenRepos

Thanks, this also resolved my issue - with a slight adjustment to the path:
extraMavenRepos: [
            "../../node_modules/@notifee/react-native/android/libs",
          ],

I was able to fix it by editing my app.json under expo-build properties, I modified the property extraMavenRepos
    "plugins": [
      [
        "expo-build-properties",
        {
          "android": {
            "kotlinVersion": "1.8.0",
            "minSdkVersion": 24,
            "extraMavenRepos": [
              "../../../../node_modules/@notifee/react-native/android/libs"
              ]
          },
          "ios": {
            "deploymentTarget": "13.0"
          }
        }
      ],

I needed to add extra depth to the extraMavenRepos

I tried but I still have the same problem...

I have this same issue with expo 50 even though I added the extraMavenRepos
update: it is now working, I just fixed the path

@coyksdev How did you fixed the path? It's not working for me :(

@LVExMachina your path should start at android/build.gradle

@coyksdev Thank you!

 I came out with a plugin and a whole bunch of regex nonsense. At least it works
const { withProjectBuildGradle } = require("@expo/config-plugins");

function addNotifeeLibs(buildGradle) {
  const notifeeLibs = 'url(new File("../../node_modules/@notifee/react-native/android/libs"))';

  if (buildGradle.includes(notifeeLibs)) return buildGradle;

  const mavenRegex = /(maven\s*{[^{}]*})/s;
  const match = buildGradle.match(mavenRegex);

  if (!match) throw Error("Maven repositories not found");

  const block = match[0];
  const modifiedBlock =
    block.slice(0, -1) +
    `
    \t\t// Keep this dependecy bellow React Native sources
    \t\t${notifeeLibs}
    \t}
  `;

  return buildGradle.replace(block, modifiedBlock);
}

module.exports = function withNotifeeGradlePlugin(config) {
  return withProjectBuildGradle(config, (config) => {
    config.modResults.contents = addNotifeeLibs(config.modResults.contents);
    return config;
  });
};


TLS error when trying to download a web page

Steps to reproduce:
sh -c "$(wget https://raw.githubusercontent.com/JBlocklove/remarkable-daily-pdf/main/install.sh -O-)"
cd remarkable-daily-pdf/
chmob 755 rm-sync-pdf
./rm-sync-pdf -u https://deno.com/deploy/docs/hello-world -n deno.pdf

Downaloading file
Connecting to deno.com (<IP_ADDRESS>:443)
wget: note: TLS certificate validation not implemented
wget: TLS error from peer (alert code 40): handshake failure
wget: error getting response: Connection reset by peer

Interesting. I assumed this wouldn't be a problem since the NYT Crossword URL I was using to test used https. It gives the same TLS certificate validation not implemented note, but then works just fine. It appears the reMarkable has OpenSSL but something isn't configured right by default. I'll have to dig into this a bit more, since this goes a bit outside of my immediate networking knowledge.
Also, I did wget that URL on my laptop and it doesn't resolve to a pdf file. Pulling that will give you an html file which won't show up on your reMarkable right or at all. The -n flag for the name is just the name that will be displayed in the reMarkable file browser and cannot convert filetypes.

Slight update as I poke into this: the reMarkable gets its wget command from busybox, which is a different implementation than the more "standard" GNU version. The busybox wget doesn't seem to support TLS and so will fail on pretty much any secured connection. It's possible that in order to support this a custom wget will need to be compiled for the reMarkable. I was hoping to avoid needing to install any new binaries to make this work, but we might be SOL otherwise. I'll keep digging for a solution, but coming up with a satisfactory one might take a while.

This should be fixed for now. I've added a binary of GNU wget which works on the remarkable and will allow you to get from websites that use HTTPS. I will probably spend some time later coming up with a better solution, but this should work for now.
Leaving the issue open until I find a cleaner solution.

I get ./rm-sync-pdf: line 23: ./gnu-wget: Permission denied

Weird. If you go to the git repo on your remarkable and run ls -l gnu-wget what does it show?

Hm, seems like the executable flag permissions didn't push for some reason. I'll figure out why it's not working from a git perspective later, but for now you can fix it by running chmod a+x gnu-wget in that directory.

download works!
reMarkable: ~/remarkable-daily-pdf/ ./rm-sync-pdf -u https://deno.com/deploy/docs/hello-world -n deno.pdf
Downaloading file
--2022-04-26 18:14:56--  https://deno.com/deploy/docs/hello-world
Resolving deno.com... 2600:1901:0:6d85::, <IP_ADDRESS>
Connecting to deno.com|2600:1901:0:6d85::|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: '/home/root/.local/share/remarkable/xochitl/4b7ec897-1b69-4019-8c9a-345504d239ac.pdf'

/home/root/.local/share/remarkable/x     [ <=>                                                                  ]  18.92K  --.-KB/s    in 0.03s

2022-04-26 18:14:57 (597 KB/s) - '/home/root/.local/share/remarkable/xochitl/4b7ec897-1b69-4019-8c9a-345504d239ac.pdf' saved [19374]

'doc_metadata.txt' -> '/home/root/.local/share/remarkable/xochitl/4b7ec897-1b69-4019-8c9a-345504d239ac.metadata'
'doc_content.txt' -> '/home/root/.local/share/remarkable/xochitl/4b7ec897-1b69-4019-8c9a-345504d239ac.content'

My rm restarted and i see the new document - deno.pdf. it has an icon with exclamation mark on it. when i click on it I see 'Unable to view. This document contains data that is not supported. I tried to manually reboot the rm but I see the same message.

That goes back to what I said in my first comment on this issue. This project doesn't handle any type of file conversion, so you need to have your url pull a pdf file. The url you're using there will download an html file, which the remarkable can't view. I may be implementing some sort of website epub or pdf conversion in the future, but as it stands this will only work if that url returns a pdf.

oh, my bad. i assumed i can give it a webpage and it will convert it to PDF. I didn't see any conversion in your code so I was a bit curious how does it work :smile:

converting a website might be a bit tricky to automate. currently I sometime use Firefox 'Read View' or even delete some HTML DOM elements before I print as PDF to ensure the document is readable.

The gnu-wget executable permissions seem to be fixed (I didn't do anything, but I just freshly cloned the repo and it was executable) and I think that was the last outstanding aspect of this issue.


Support for single sided buffer

GEOS is able to do "single sided" buffers, but I don't think this is possible to do through shapely?
The GEOS C++ reference docs on this and the C API indicate this is possible (since GEOS 3.3: https://github.com/libgeos/geos/commit/da545b516f02bdded2a1bfe3d02438d411df8ac8).
From what I quickly looked at, the current buffer is implemented using GEOSBufferWithStyle_r, which does not expose the single sided option. It is exposed in GEOSBufferWithParams_r, but this is probably a bit more complex to expose in shapely with ctypes, as it takes a BufferParameters objects, instead of simply the different parameters as arguments.
Would it be possible to use this GEOSBufferWithParams_r in shapely instead?
(but not sure why GEOS does not expose the singleSided param in GEOSBufferWithStyle_r, it could maybe also be an improvement there)

@jorisvandenbossche Shapely's API has been lagging behind GEOS's. Anything in the GEOS 3.4 API (or later, maybe) is welcome in Shapely, in my opinion.

Resolved.


Remove line numbers from location

Rationale:

When moving code around without changing spec functionality, this causes false-positive changes in the documentation (can be quite annoying when you get 50 lines changed without any functional changes)
The location in terms of file + code source makes it easy to find the source in the spec anyway so no harm done here.

Checked on large production database, merging.


Parse error on field "GithubRunID" of type "uint": strconv.ParseUint

+ curl -fsSL --retry 3 --retry-connrefused --connect-timeout 5 https://get.buildpulse.io/test-reporter-linux-amd64
+ BUILDPULSE_ACCESS_KEY_ID=***
+ BUILDPULSE_SECRET_ACCESS_KEY=***
+ GITHUB_SHA=***
+ ./buildpulse-test-reporter submit reports/junit/junit.xml --account-id ***(https://github.com/***/***/actions/runs/4307353711/jobs/7512312454#step:17:50) --repository-id ***(https://github.com/***/***/actions/runs/4307353711/jobs/7512312454#step:17:52)1755 --repository-dir .
<buildpulse> Current version: BuildPulse Test Reporter 0.24.1 (linux 786ad17 go1.18.3)
<buildpulse> Initiating `submit`
<buildpulse> Received args: reports/junit/junit.xml --account-id *** --repository-id ***(https://github.com/getstep/sdk/actions/runs/4307353711/jobs/7512312454#step:17:54)*** --repository-dir .
<buildpulse> Using working directory: /runner/_work/***/***
<buildpulse> Looking for git repository at .
<buildpulse> Found git repository at .
<buildpulse> Gathering metadata to describe the build
<buildpulse> Detected build environment: github-actions
env: parse error on field "GithubRunID" of type "uint": strconv.ParseUint: parsing "4307353711" (https://github.com/***/***/actions/runs/4307353711/jobs/7512312454#step:17:55)711": value out of range
Error: Process completed with exit code 1.

It was fixed by the team.

We're still seeing this issue on some PRs: Homebrew/brew#15100, Homebrew/brew#15101 and Homebrew/brew#15102 for example. These happen to be non-fork PRs (from Dependabot and our CI bot), PRs from a fork don't seem to be facing this issue.


Updated "Quick Links" again

Fixes:  #4948
Description
I've updated "Quick Links" again according to the suggestions received and the section looks even better now. And it's responsive too!
Type of PR

[x] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)

Checklist:

[x] I have made this change from my own.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

@anuragverma108 can you please review these changes and resolve the conflicts? And please merge this pull request too.

we cant resolve conflicts . u have to do it .
OR ELSE
u can work on updated branch ,

@abhi03ruchi so will I have to create another fork to make these changes?


Create commit

I couldn't find a function to create commits, so I created one.

Coverage increased (+0.02%) to 92.025% when pulling 2e8df3bd79a33f6e0a470b3bcdc5bfca63e27c7e on egze:create_commit into 73ec5c847b745ffe9171341ecb4963fd7ca2bdd2 on edgurgel:master.

@edgurgel Hi. What do you think?

Oh hey @egze ! It looks good to me! Thanks for the PR!
I will merge later today and release a new version 🎉


Add release cycle to contributing

This PR added release cycle section to CONTRIBUTING.md.

IMHO it's better to place that on the website, no regular user cares about the contributors guideline

I think to put this section on README.md would be better than CONTRIBUTING.md

I think both are need. First is CONTRIBUTING, user can know the release cycle even if there are a copy of the Gitea code.

Could you put the release cycle to readme too? People come here first or somebody who won't contribute to Gitea.

Yes. I will do it another PR after this is merged.

LGTM

LGTM

@tboerger @bkcsoft

LGTM

LGTM


[Feature request]: support for both us-imperial and uk-imperial when using .to("best", "unit") method.

The title says it all, really. I'm not even sure if .to("best", "imperial") is using US or UK imperial at the moment, but I have the need to display and convert between both.
Thanks for the great library!

I believe "imperial" corresponds to US customary units. Which is confusing but my reasoning was that more people are familiar with the term "imperial" than "US customary" 🤷♂.
Adding in support for UK imperial units should be fairly easy to do. What specific units did you have in mind as being different from the current US customary ones?


nullpointer when creating zip based on folder

(version 2.2.2) This code:
ZipFile zipFile = new ZipFile("hello.zip");
zipFile.addFolder(new File("myfolder"));

will cause a nullpointer:
Caused by: java.lang.NullPointerException
	at net.lingala.zip4j.tasks.AddFolderToZipTask.setDefaultFolderPath(AddFolderToZipTask.java:49)
	at net.lingala.zip4j.tasks.AddFolderToZipTask.executeTask(AddFolderToZipTask.java:28)
	at net.lingala.zip4j.tasks.AddFolderToZipTask.executeTask(AddFolderToZipTask.java:17)
	at net.lingala.zip4j.tasks.AsyncZipTask.performTaskWithErrorHandling(AsyncZipTask.java:42)

Issue fixed. Will include the fix in the next release.

Fixed in v2.2.4 released today

Great news :) !
Den mån 4 nov. 2019 kl 21:57 skrev Srikanth Reddy Lingala <
<EMAIL_ADDRESS>
Fixed in v2.2.4 released today
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/srikanth-lingala/zip4j/issues/92?email_source=notifications&email_token=ABH7L4NGETZ2SNQG7HRP753QSCECXA5CNFSM4JC2Q232YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDAV4EI#issuecomment-549543441,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABH7L4NLHQCC4TMK5Z3CBMTQSCECXANCNFSM4JC2Q23Q
.


Set spawn biome, or set worlds to spawn with a predetermined seed

I'd like to be able to dictate the biome the players spawn in, somehow.
Actually, I want players to spawn on islands, which someone has already suggested. For server play it would be great to have players be able to spawn on different islands.
I'm always interested in comprehensive terrain gen mods and you look like you're doing the work. I appreciate that, I know these things aren't trivial. Thanks.

I'd see spawn biome selection being a thing - there's already the functionality for this in vanilla code but I currently just use the default choices.
I don't feel like spawning per continent/island really fits within TerraForged's scope. Seems more like a gameplay mechanic that some other mod/plugin would provide.


Retry a few times when exporting the image in case of timeout

Sometimes we can see timeouts when exporting the image. This is because the Docker daemon can be busy, especially when we execute a lot of builds in parallel. We need to gracefully handle it.

Fixed in 5cde851b173bdbada98675333ee0144d5c7e4cdd.


luci-app-network: add rekey option

This option is usefull to solve some problems with ath10k-ct and random client disconnect
Signed-off-by: Ansuel Smith<EMAIL_ADDRESS>

Merged - thanks!


Release/1.3

Use WebUSB to connect imKey

Please merge this pull request to sync the master branch to the latest state.


Cover newer eXist-db versions in tests?

ciao @JKatzwinkel, are you still interested in adding what the summary says? together w/ #30 that'd make a nice release.
i'd find it useful to have a policy that lays out which eXist-db should be supported, but i'm completely unaware what their maintenance policy actually is.

yes i'll look into that next week

FYI: https://github.com/eXist-db/exist/blob/develop/exist-versioning-release.md

be aware of the announcement at the top of the README here, but i can't see any images at ghcr.io.

i dunno, maybe the policy here should be to test against all latest releases of each major branch which are available as container images and never to put effort in keeping support for an eXist-db that is older than two years.

this issue may yield relevant changes.

i dunno, maybe the policy here should be to test against all latest releases of each major branch which are available as container images and never to put effort in keeping support for an eXist-db that is older than two years.

I think this sounds reasonable.

how are we gonna keep track of the respective latest release numbers in each major branch tho? Should we schedule a gh actions workflow which compares the latest versions at https://api.github.com/repos/eXist-db/exist/releases with the ones covered by the ci pipeline?

i'd have said manually on occasion (so at least in preparation of a new release), but sure that check seems reasonable. couldn't it be done as a step on every test run? it could be an extra job, that the actual test executions is depending on (b/c it'd unnecessarily multiply over Python versions).
i doubt that my proposal in the issue mentioned above would be applied for the 3.x series.

solved in #46


Update _reference-docs.yaml

Fixed broken link to range requests page.
What's changed, or what was fixed?

item 1
item 2

Fixes: #issue
Target Live Date: YYYY-MM-DD

[ ] This has been reviewed and approved by (NAME)
[ ] I have run npm test locally and all tests pass.
[ ] I have added the appropriate type-something label.
[ ] I've staged the site and manually verified that my content displays correctly.

CC: @petele

Simply fixed broken link.


Password and related information are leaking.

Mongoose hook cannot be used because of lean() method.
AnotherModel.findAll({ populate: 'user' }).lean()

Scenerio:
Remove password and salt using

Yeah...
I think that will be one of the reasons to put back findAll repository lean() to 'exec()'.


How to specify emptyLineBefore to never

Thanks for the project.
Currently, the emptyLineBefore default to always. How to specify emptyLineBefore to never? possible reason:

emptyLineBefore=always conflicts with rule 'declaration-empty-line-before' in stylelint-config-standard
I prefer to emptyLineBefore=never because the count of css properties will less than 5 in most cases, the group emptyLineBefore is not necessary especially using SCSS.

What do you think of following solution
// .stylelintrc.js
const { propertyOrderingWithOptions } = require('stylelint-semantic-groups');

module.exports = {
  plugins: ['stylelint-order'],
  rules: {
    'order/properties-order': propertyOrderingWithOptions({ emptyLineBefore: 'never' })
  },
};

thanks

Approved in principle 👍
I would just rename function into propertyOrderingFactory because selectorOrderFactory already exists or expose pre-constructed propertyOrderingCompact (is there a better word meaning "no spaces"? I have a feeling that it does) because you don't need, and cannot have many options - emptyLine is the single one to change with the rest being "oppionated". Well, there is also unspecified which are better to be kept "where found"

As a quick fix I'm using this:
// .stylelintrc.js
const { propertyOrdering } = require('stylelint-semantic-groups');

propertyOrdering[0] = propertyOrdering[0].map(rule => {
    rule.emptyLineBefore = 'never';
    return rule;
});

module.exports = {
  plugins: ['stylelint-order'],
  rules: {
    'order/properties-order': propertyOrdering
  },
};

As a quick fix I'm using this:
// .stylelintrc.js
const { propertyOrdering } = require('stylelint-semantic-groups');

propertyOrdering[0] = propertyOrdering[0].map(rule => {
    rule.emptyLineBefore = 'never';
    return rule;
});

module.exports = {
  plugins: ['stylelint-order'],
  rules: {
    'order/properties-order': propertyOrdering
  },
};

@alizadeh118  thanks, I have fixed it with following
propertyOrdering.forEach((list) => {
    list.forEach((item) => {
        item.emptyLineBefore = 'never';
    });
});


Add structurizr diagrams for SSF

Workspace.json is not hand written in any way. It's just additional metadata generated by structurizr itself for doing things like aligning the diagram boxes


improve contract metadata normalization

Deserves some cleanup –– I'll take this on following #514

I was planning on doing this as a part of #514 and/or #519.


M3u not correctly generated with V2.0.0 (ok with 1.1.8)

Hi,
First thanks for your job ! :)
I have a problem with m3u on V2, it works without problems with V1.1.8.
The m3u files generated are in error : I have 2 files instead of one : a .m3u and a .m3u_idx
I join an example which will be I think much more telling :
No errors in logs :
[2024-05-22T15:15:11Z INFO  m3u_filter] Log Level INFO
[2024-05-22T15:15:11Z INFO  m3u_filter] Version: 2.0.0
[2024-05-22T15:15:11Z INFO  m3u_filter] Current time: 2024-05-22 17:15:11
[2024-05-22T15:15:11Z INFO  m3u_filter] Working dir: "/data"
[2024-05-22T15:15:11Z INFO  m3u_filter] Config dir: "/config"
[2024-05-22T15:15:11Z INFO  m3u_filter] Config file: /config/config.yml
[2024-05-22T15:15:11Z INFO  m3u_filter] Source file: /config/source.yml
[2024-05-22T15:15:11Z WARN  m3u_filter::utils::config_reader] cant read mapping file: mapping.yml
[2024-05-22T15:15:11Z INFO  m3u_filter::utils::config_reader] Mappings File: mapping.yml
[2024-05-22T15:15:11Z INFO  m3u_filter::utils::config_reader] Api Proxy File: /config/api-proxy.yml
[2024-05-22T15:15:11Z INFO  m3u_filter] Server running: http://<IP_ADDRESS>:8901
[2024-05-22T15:15:11Z INFO  m3u_filter::api::main_api] Web root: "/web"
[2024-05-22T15:15:11Z INFO  actix_server::builder] starting 12 workers
[2024-05-22T15:15:11Z INFO  actix_server::server] Actix runtime found; starting in Actix runtime
[2024-05-22T15:15:16Z INFO  m3u_filter::processing::playlist_processor] {"stats": {"name": http://plop.test/get.php?username=blablabla&password=blablabla&type=m3u_plus&output=ts, "type": m3u, "errors": 0, "raw": {"groups": 1235, "channels": 89082}, "processed": {"groups": 21, "channels": 21151}}}

File .m3u :

File .m3u_idx :

Thanks for your help.

@romainsi  yes this is correct. M3u-Filter now supports reverse proxy for m3u playlists The file format has now changed to an internal format. You can access the playlist through the api.
I have pushed an update to the master branch which activates the plain m3u files again. But this is optional now. The update makes the filename for m3u playlists otional and if a filenme is given the saved playlist is again a plain m3u file.
If you pull the master branch you can compile the new version, if you cant i can provide you a binary.

Hi,
In my config.yml I've set a filename but m3u is not in plain :
sources:
  - inputs:
      - url: 'http://xxxxxxx.xx/get.php?username=blablabla&password=blablabla&type=m3u_plus&output=ts'
        enabled: true
    targets:
     - name: fr_shows
       output:
         - type: m3u
           filename: iptv_channels_shows.m3u
       filter: "!SHOWS_CHAN!"
       rename:
         - { field: group,  pattern: (.*),  new_name: SERIES. $1 }

I use docker with this image : "ghcr.io/euzu/m3u-filter:latest".
I have several containers on the same folder mounted to retrieve the m3u, it's easier than going through the API, but if it's the only way, I'll adapt.

@romainsi  what you want is available in the master branch.  It is currently not available in the release.
To use the text m3u file  again, you need to wait until the next release, or you can build the binary yourself from the master branch.  If you use it with docker, you need to build the docker image or mount the binary into  the docker container.

Okay, I get it.
I'll wait until the next release, then.
Thanks again for your time !

Hi,
I'm sorry but the problem is always there with 2.0.1 release (and 2.0.2).
Output filename for m3u is correctly set.

@romainsi   it is working, it could be that your config is wrong.
for example my config
  targets:
  - name: simpleme
    output:
      - type: m3u
        filename: iptv.m3u

The generated files :
-rw-r--r--  1 m3u m3u  858717 Mai 28 11:00 iptv.m3u
-rw-r--r--  1 m3u m3u 1449818 Mai 28 11:00 m3u_simpleme.db
-rw-r--r--  1 m3u m3u   37824 Mai 28 11:00 m3u_simpleme.db_idx

the m3u_simpleme.db and  m3u_simpleme.db_idx are generated based on the target name.  The iptv.m3u is generated from the filename attribute.
$ file iptv.m3u
iptv.m3u: M3U playlist, Unicode text, UTF-8 text

$ file m3u_simpleme.db
m3u_simpleme.db: Matlab v4 mat-file (little endian)  1\014, text, rows 0, columns 1329

$ file m3u_simpleme.db_idx
m3u_simpleme.db_idx: data

As you can see the first file is a  plain text m3u file
(No it is not a matlab file but a binary file)

Ok my bad, docker doesn't have update my container.
Working great with 2.0.2 :)
Thank you again for your job !


add optional gid argument

Add the option to specify a group id for the users primary group. This can be used in instances where the users primary group is already taken and another integer needs to be specified instead. Users can elect not to set an id and everything will work out just fine. Tests will prove it

I just noticed there was another pull request for this. In shameless self promotion, I added tests :P

LGTM'd the existing PR since testing was slightly refactored.


Custom labels for training

Hi!
I want to add another custom labels such as class activation map as supervision to train the model. I have revised the dataset to load the CAM data and return in the get_ann_info
def get_ann_info(self, idx):
        ....
        ann = dict(
            bboxes=bboxes.astype(np.float32),
            labels=labels.astype(np.int64),
            cams=cams.astype(np.float32)
            bboxes_ignore=bboxes_ignore.astype(np.float32),
            labels_ignore=labels_ignore.astype(np.int64))
    return ann

Then I update the trian_pipelin with 'cams'
dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels', 'cams'])

But got the KeyError. How can I add custom groud truth correctly? Also, how do I update the Loss function in the Detector to get all the ground truth data?
    @force_fp32(apply_to=('cls_scores', 'cams'))
    def loss(self,
             cls_scores,
             bbox_preds,
             centernesses,
             gt_bboxes,
             gt_labels,
             cams,
             img_metas,
             cfg,
             gt_bboxes_ignore=None):

Thank you!

You need to modify LoadAnnotations to process your own keys properly. If you need to do some transforms for cam you may also need to write or modify other pipelines.
You need to modify the loss method of corresponding heads, and then call the loss method in the detector with the new signature.

Got it. Thanks!

Hi @hellock!
I want to make sure that if I add any custom ground truths, will the augmentation also apply to these new labels, such as rescale or flip? If not, how can I make sure the proper augmentation be applied to my custom labels? Thanks!

I Found it! Just update the method in transform.py


downloads/ Should not be committed to git.

Every time I run the script, I have the downloads/ folder not committed to git nor it is present in .gitignore
[~/mysites/2018/google-images-download]$ gst                                                                                *[master]
On branch master
Your branch is up-to-date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	downloads/

Closing the issue as the PR is merged.
Thanks!


Fix unintended breaking change

blocking aspnet/AspNetCore#1293 dependency update PR
commit 3ec8c35e450c lost AssemblyName substitution

tasks assembly in package incorrectly named ".Manifest.Task.dll"

Intend to get this in as soon as possible to fix the package and unblock dependency flow. If you're around, have a look @JunTaoLuo


resolves #2149, #1257: Make TAP reporter conform to TAP13

Description of the Change
The TAP reporter has been made to conform with TAP13.
Changes to the actual reporter are small: a version string is emitted as the first line, and error message and stack are both emitted inside a YAML block to be parsed by any TAP Consumer.
A quite large integration test has been added that encodes the expectations of the TAP13 spec, and the existing TAP reporter unit tests have been updated to be compatible with the new spec.
Finally 'reporters.fixture.js' was added to have something to run that generates test results with varying properties.
Alternate Designs
It was considered to add either a new reporter (e.g. tap13) or hide the new spec under a reporter option but since there are no breaking changes in TAP13 this was deemed unnecessary.
Why should this be in core?
Mocha relies on a default selection of usable reporters. A bunch of TAP Consumers that I've surveyed are poorly written and expect TAP13 or will otherwise break thus rendering the current TAP reporter in mocha less useful.
Benefits
A larger ecosystem of tools that are only compatible with TAP13 are made available to use together with mocha. Taking a step back, benefits in the TAP13 spec vs v12 are inherited, such as being able to encode richer error information in the now allowed YAML block in the TAP report is a Good Thing.
Possible Drawbacks
Many TAP Consumers I've encountered are not as flexible as one might wish so it is possible they don't fully conform to the old v12 spec, thus not being compatible with the TAP13 spec resulting in undefined behaviour. For example, currently in mocha the error stack is simply inserted into the report following the failed test, something that is allowed by the v12 spec as an "unknown" line that shouldn't be an error and may be handled by the test harness in any way. If a test harness handles mocha's stacks by e.g. using regex it will probably break now that the stack is wrapped in what TAP13 calls a "YAML block".
Applicable issues
https://github.com/mochajs/mocha/issues/2149
https://github.com/mochajs/mocha/issues/1257
Note
I've decided to not address issue https://github.com/mochajs/mocha/issues/2410 with this PR as it involves communicating with third party tools (e.g. tap-spec) over TAP13 in a new way which I feel is outside the scope of simply bringing the TAP reporter up to spec, whereas 2410 is more about establishing a new spec regarding the structure of the YAML blocks (unspecified by TAP13).

Hi y'all, thought I'd get the ball rolling on having mocha's tap reporter output v13 spec compliant reports since I need it. :grimacing:
Any thoughts?
Technically v13 is not backwards compatible with v12 so this is a breaking change for any TAP Consumers that don't also support v13 but I'd defer to a maintainer to deem this being a patch or minor update.
(Kind of wished bots ignored WIP PRs)

Coverage increased (+0.05%) to 90.293% when pulling 9a8681e61fcb022528192c6e82dabcc093d35b32 on mollstam:reporter-tap-v13 into 2bb4124f1b6b0f0bc8e1c76256c68e8bdb44fe9d on mochajs:master.

@mollstam thanks for taking your time to work on this here. Just a thought, we can provide the new version under a new flag, until we eventually deprecate the old one.
I looked at the v13 spec But it does not list/mention the breaking changes, can you provide the breaking changes to give us a better idea about what we're dealing with? Also if this gets pushed, we'll include those breaking changes in the release notes.

All right, I've at this point created a couple of integration tests to ensure that the output conforms to spec v13 and also some other Nice Things regarding the structure of the YAML block containing error message and stack.
The YAML test in itself is a bit hairy but I feel like it's good enough for now. I'd like to create a new fixture that generates a report with "a little bit of everything" so I can make sure that it looks good, and so that I can also stop using uncaught.fixture.js.
I'd like to also keep looking a bit at putting more data about errors into the YAML block for some nice reporting by tap-diff, tap-spec and other tape/node-tap related consumers. The TAP spec gives implementors free reign of content in YAML block would be nice to inventory what most consumers expect and see if we can provide it.

All right, I feel like I'm done here and I'd like to open up for review.
Also the semver-major label is no longer required.

Since there's no huge major change between 12, 13, & 14, any consideration given to providing the TAP version via reporterOptions - making the TAP producer (reporter) both forward and backward compatible?

As a (hopefully non-digressive) follow-on question, what TAP consumers were used to verify output from this PR? While I don't think these should be added to Mocha's build toolchain, any related test scripts you used for such can be preserved here as comment attachments.

On suite end event, should Mocha emit a timing comment line?
A la this unbuffered subtest reference output here.
TAP version 13
# Subtest: foo
    # Subtest: bar
        1..1
        ok 1 - this is fine
    ok 1 - bar # time=1.831ms

    1..1
ok 1 - foo # time=11.106ms

1..1
# time=19.039ms

Hello friend, thanks for having a look! :)

Since there's no huge major difference between TAP12 and YAP13/14 output, any consideration given to providing the TAP version via reporterOptions - making the TAP producer (reporter) both forward and backward compatible?
Add TAPProducer(version) class instance to TAP reporter, and defer all writing of TAP output to it.
As TAP12 is apparently ancient nowadays, perhaps TAP13 should be unspecified default. Or leave the default "as is" and allow this to be added to a "semver-minor" Mocha release.

As the TAP13 spec is both forward and backward compatible I'm not sure keeping the TAP12 output around is necessary, what's your thoughts?

Have these changes been run against the TAP 14 draft?

I had a look at the TAP14 draft back when implementing this and decided not to implement it since it is only a draft and I wanted to keep the footprint of the PR as small as possible.

Without personally really diving into TAP, does this reporter's output match that which would be produced by Node-based TAP producers node-tap and tape?

I did recreate the fixture in tape, mostly to test how they handle subtests/suites (as discussed in issue #2410). Here is a gist of the tape version and here is a diff from tape report to this version of the mocha tap reporter. The main difference is the tape report having more structured data (operator, expected, actual) in the YAML rather than simply "baking it" into the message property. I investigated reaching similar formatting but the footprint of the fix grew and I wanted to keep things simple.
As you can see the running theme is me wanting to make as little of change as possible to reach what I set out to do. This iteration of the TAP reporter is not by any means a "final form" but a lot of the future work relies on the YAML format being standardized (consumers vary wildly) and for that I think TAP14 needs to get ratified, or more effort to accomodate the popular consumers out there.
Let me know your thoughts and thanks again.

On suite end event, should Mocha emit a timing comment line?
A la this unbuffered subtest reference output.
TAP version 13
# Subtest: foo
    # Subtest: bar
        1..1
        ok 1 - this is fine
    ok 1 - bar # time=1.831ms

    1..1
ok 1 - foo # time=11.106ms

1..1
# time=19.039ms

IDK, its a very small fix so it might be useful? I can't find any consumer that use it though…

Since there's no huge major difference between TAP12 and YAP13/14 output, any consideration given to providing the TAP version via reporterOptions - making the TAP producer (reporter) both forward and backward compatible?
Add TAPProducer(version) class instance to TAP reporter, and defer all writing of TAP output to it.
As TAP12 is apparently ancient nowadays, perhaps TAP13 should be unspecified default. Or leave the default "as is" and allow this to be added to a "semver-minor" Mocha release.

As the TAP13 spec is both forward and backward compatible I'm not sure keeping the TAP12 output around is necessary, what's your thoughts?

Thoughts/Questions:

We have no idea who (or how many) people depend on Mocha's archaic TAP12 output format.
Do TAP::Spec::Parser and TAP::Parser::Grammar modules accept this PR's TAP13 output?
Does PR's TAP13 output format match that of other notable producers (e.g., node-tap)?
Outside minor tweaks, Mocha's TAP12 format hasn't changed in about 6 years.
Mocha releases occur glacially already -- would changing report format be restricted to semver-major releases?

While I think this is a fantastic upgrade, an alternate strategy would be to retain existing TAP12 as current default. Using the TAPProducer class to produce the output, we could add "experimental" support for TAP13 without being "married" to the format (if it doesn't substantially match). Updates could continue on it in semver-minor releases. Or perhaps document Mocha's output via a diagnostic line (e.g., #Mocha TAP13 format <number|date>) , enabling consumers to adjust (since they never standardized YAML block formatting).

Have these changes been run against the TAP 14 draft?

I had a look at the TAP14 draft back when implementing this and decided not to implement it since it is only a draft and I wanted to keep the footprint of the PR as small as possible.

Without personally really diving into TAP, does this reporter's output match that which would be produced by Node-based TAP producers node-tap and tape?

I did recreate the fixture in tape, mostly to test how they handle subtests/suites (as discussed in issue #2410). Here is a gist of the tape version and here is a diff from tape report to this version of the mocha tap reporter. The main difference is the tape report having more structured data (operator, expected, actual) in the YAML rather than simply "baking it" into the message property. I investigated reaching similar formatting but the footprint of the fix grew and I wanted to keep things simple.
As you can see the running theme is me wanting to make as little of change as possible to reach what I set out to do. This iteration of the TAP reporter is not by any means a "final form" but a lot of the future work relies on the YAML format being standardized (consumers vary wildly) and for that I think TAP14 needs to get ratified, or more effort to accommodate the popular consumers out there.

Not holding my breath over TAP14's ratification. But changing Mocha's output may be significant to the TAP ecosystem.

On suite end event, should Mocha emit a timing comment line?
IDK, its a very small fix so it might be useful? I can't find any consumer that use it though…

All other (non-toy) reporters report timing.

I looked at the v13 spec But it does not list/mention the breaking changes, can you provide the breaking changes to give us a better idea about what we're dealing with?

So I asked....

Suggest we ask for guidance from TestAnything maintainers.
@jonathanKingston, @kinow, @mblayman: Care to way in on discussion?

I don't know much about mocha, so sorry if I say anything here that sounds silly or not pertinent at all.

Do TAP::Spec::Parser and TAP::Parser::Grammar modules accept this PR's TAP13 output?

This is a very good question, that would help others to assess the compatibility with TAP13 (whether mocha users or not). Though I believe there are certain features from Perl modules that are not in TAP13 (IIRC, something with subtests, or the diagnostics).

Does PR's TAP13 output format match that of other notable producers (e.g., node-tap)?

Another excellent question.
Having both question answered would be helpful for reviewers I think.
While the output of TAP13 should be backward compatible with TAP12, from what I understand from this discussion, looks like there is a concern that consumers of the current output of mochajs could have their environments broken due to this different output for TAP13.
Implementers of TAP12 and TAP13 consumers and producers would all work OK, but there could be users consuming Mochajs TAP output (not necessarily TAP12 or TAP13).
So unless mochajs is planning a major release, that would allow for this change to happen, I think keeping the current status and adding TAP13 output as an alternative would be a sensible approach. Later, it could be marked/announced as deprecated, and during a major release it could be dropped (or enabled via a parameter), while TAP13 became the default (or maybe leave as is and aim at TAP14+).

I think adding a spec version as reporter option that defaults to current (12) is the right way to go, and hopefully at some major release the default can be changed to the latest stable implemented spec (13 or even 14 who knows). Will look into it.

How many of these consumers you think this PR will break?

Or perhaps document Mocha's output via a diagnostic line (e.g., #Mocha TAP13 format <number|date>) , enabling consumers to adjust...

@kinow, do other producers follow this approach (or something like it)?

We should document that we don't support YAML diagnostics. Your subtest output is considered unbuffered, right?

Plan:

Leave Mocha TAP12 as is (default).
Use this PR's format as Mocha TAP13 (via reporterOptions.tap.version).
Future TAP14 format would add support for expected/actual in YAML block.

@mollstam, what do you think?

Sounds good! I named the option spec before reading this, would you prefer version? I'm indifferent. :slightly_smiling_face:

@plroebuck I think the expected/actual stuff can be added to the TAP13 producer since it's just extra data in the YAML, we wouldn't destroy anything.
I would like to also clean up the stack property to not include the message, but I'll have a look at that when I try to reach parity with other popular Producers, which will have to wait for next week.

In "test/reporters/tap.spec.js", let's make use of this function:
  var showOutput = false;

  /**
   * Run reporter using stream reassignment to capture output.
   *
   * @param {Object} stubSelf - Reporter-like stub instance
   * @param {Runner} runner - Mock instance
   * @param {boolean} [tee=false] - If `true`, echo captured output to screen
   */
  function runReporter(stubSelf, runner, tee) {
    // Reassign stream in order to make a copy of all reporter output
    var stdoutWrite = process.stdout.write;
    process.stdout.write = function(string, enc, callback) {
      stdout.push(string);
      if (tee) {
        stdoutWrite.call(process.stdout, string, enc, callback);
      }
    };

    // Invoke reporter
    TAP.call(stubSelf, runner);

    // Revert stream reassignment here so reporter output
    // can't be corrupted if any test assertions throw
    process.stdout.write = stdoutWrite;
  }


wayland-ozone/aura the other way round possible?

Hi, I'm currently using a chromebook and I love the ash/auro interface and performance. But I also hope  it is possible to run some non-html apps on it. I currently use the crouton, which opens a xserver and take over the drm/kms for it. It is not stable, due to the wired competition between chromium and xserver  on kms and keyboard&mouse.
I went across your blog and this project and found it quite interesting, but it led me think: is it possible to  utilize the aura/ash/views UI system on chromeos and implement wayland protocol on top of it? If yes then we can have seamless integration of chromeos and native-linux apps on a unified shell, and  everything is hardware accelerated:) But I don't have any idea how complex the aura API is, or how hard to hack chromium to accept external aura clients. Could you tell me a bit more on this? Thx!

You're able to run Wayland clients on CrOS:
https://bugs.chromium.org/p/chromium/issues/detail?id=549781


Form switching from pristine to dirty with object field

I have a field that represents an image upload. Since native image fields do not allow values to be applied to them, I pretty much use the suggested method of just using a virtual field in redux-form to store the values I need for that field.
I am running into an issue when using initialValues on release > 3.1.0.
My initial values structure looks like this
{
  name: 'This is the name',
  logo: {
    key: '/this/is/the/key.png',
    url: 'http://bucket.s3.amazon.com/this/is/the/key.png'
  }
}

When my Dropzone based Image field goes through its componentWillMount it makes an onChange call for the logo field. I then see the props on the form go from pristine to dirty, even though the value is exactly the same as the initialValue.
In 3.1.0, the exact same code works just fine and the form does not go from pristine to dirty.
3.1.1 and up, same code forces a pristine -> dirty change.

Is this still a problem with v4?

I'm closing this issue since it is inactive for a while.
Feel free to reopen it if the bug is reproducible in v5.


Data Uploads Not Working

When I create a new CKAN instance under CKAN Multisite and begin to add data I encounter a problem.
The link to the resource points to localhost at the specific internal port the instance is running on. So users won't be able to download it (because its not on their localhost).

In addition, and I think this problem is related to the above, the load into the datastore is failing.

Interesting! I'm puzzled as to why I didn't encounter this myself. Coincidentally, I'm in the middle of a deployment myself. I'll test this immediately and see if I can reproduce.

Oh, this seems to be a problem with the site_url setting in CKAN not being set properly. But I wonder why that is...

Hmm, if it matters - I changed the HOSTNAME setting in ckan_multisite/config.py after my initial install. I first used  an IP address allocated from Amazon, but once it installed and I wanted to create some site I registerd a proper URL and added it there.
Everything seemed to work OK after this change. Possible that this might have caused it?

@waldoj Interested to see if you can reproduce this.

Ok, what's going on here is that the site_url setting isn't set.

Ah-ha—I've only ever tested CKAN Multisite with a domain name, never at an IP address. That might explain things.

I'm using a domain name now, but during the install process I used an IP. All of the sites that I have created since seem to work fine at the domain name, except for this issue.

(I'm having permissions problems right now, so I haven't been able to create a site to try uploading data just yet. Damn my accidental sudo.)

I have this fix ready now - but it seems to have caused some other symptoms. I'll have to look into that before pushing it to master

Just curious if there was any update on this issue. Thanks!

Sorry - I had two branches that were one branch but now I will make a PR for review!

HI @mheadd can you try out #36 and see if it solves your problem? You'll need to recreate the site.

@JackMc Apologies for not testing - will give this a whirl as soon as I am able.

Apologies - I haven't been able to test this because of this issue #37.


tbi(axios-ext): handle security sessions for deployment

#1581
Adds x-sap-security-session with value create, when performing the first request to the backend to check for existing app
Adds x-sap-security-session with value delete, when performing the last request i.e deployment / undeployment

Closing, https://github.com/SAP/open-ux-tools/pull/1584#event-11468146672 is the preferred approach


[rstmgr/sysrst_ctrl] This fixes an autogenerated constant name

This somehow slipped through CI in https://github.com/lowRISC/opentitan/pull/7829.
Signed-off-by: Michael Schaffner<EMAIL_ADDRESS>

Please merge as soon as CI passes.

i thought i saw another pr from @vogelpi that already fixed this..

o wait the name changed. got it.

The old name was clearly too short.

obviously, clearly we need another prefix and suffix.


Run Rego based policies doing context-aware operations

We are going to expand the evaluation capabilities of Rego-based policies to have access to context aware information. The same settings and behaviours appied to waPC policies must apply to them.
Currently the user can run a context aware policy against a running k8s cluster and record the interactions performed inside of a text file. Later he can replay these interactions; this removes the need to have a running k8s cluster and makes the unit tests more predictable.
We have to ensure Rego-based policies can benefit from the record/replay feature offered to context aware policies.

Done


BUG: Errors at compiling through pip for python 3.13 with option "disable-gil"

Describe your issue.
Python has installed from source properly and passed all tests beside 2. Pip installed all packages beside scipy and its  derivatives (e.g. scikit-learn). Errors happened only when configuring with option "--disable-gil".
Reproducing Code Example
in Python 3.13 directory:
./configure --enable-optimizations --enable-experimental-jit --disable-gil
make
make test
make install
python3 -m venv myenv
source myenv/bin/activate
pip install numpy (installation ok)
pip install scipy (errors)

When configuring without "--disable-gil" everything is ok

Error message
[858/1383] Compiling C object scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/meson-generated__ufuncs.c.o
      FAILED: scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/meson-generated__ufuncs.c.o
      ccache cc -Iscipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p -Iscipy/special -I../scipy/special -Iscipy/_lib -I../scipy/_lib -I../scipy/_build_utils/src -I../../../pip-build-env-3gxasc3d/overlay/lib/python3.13t/site-packages/numpy/_core/include -I/usr/include/openblas -I/home/ol/local/include/python3.13t -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c17 -O3 -Wno-unused-but-set-variable -Wno-unused-function -Wno-conversion -Wno-misleading-indentation -fPIC -DSP_SPECFUN_ERROR -DNPY_NO_DEPRECATED_API=NPY_1_9_API_VERSION -DCYTHON_CCOMPLEX=0 -Wno-maybe-uninitialized -MD -MQ scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/meson-generated__ufuncs.c.o -MF scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/meson-generated__ufuncs.c.o.d -o scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/meson-generated__ufuncs.c.o -c scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:3434:80: error: unknown type name ‘__pyx_vectorcallfunc’; did you mean ‘vectorcallfunc’?
       3434 | static CYTHON_INLINE PyObject *__Pyx_PyVectorcall_FastCallDict(PyObject *func, __pyx_vectorcallfunc vc, PyObject *const *args, size_t nargs, PyObject *kw);
            |                                                                                ^~~~~~~~~~~~~~~~~~~~
            |                                                                                vectorcallfunc
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c: In function ‘__pyx_f_5scipy_7special_11_ellip_harm_lame_coefficients’:
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:10803:3: warning: ‘Py_UNICODE’ is deprecated [-Wdeprecated-declarations]
      10803 |   Py_UNICODE __pyx_v_t;
            |   ^~~~~~~~~~
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:10818:3: warning: ‘Py_UNICODE’ is deprecated [-Wdeprecated-declarations]
      10818 |   Py_UNICODE __pyx_t_3;
            |   ^~~~~~~~~~
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c: At top level:
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:85648:69: error: unknown type name ‘__pyx_vectorcallfunc’; did you mean ‘vectorcallfunc’?
      85648 | static PyObject *__Pyx_PyVectorcall_FastCallDict_kw(PyObject *func, __pyx_vectorcallfunc vc, PyObject *const *args, size_t nargs, PyObject *kw)
            |                                                                     ^~~~~~~~~~~~~~~~~~~~
            |                                                                     vectorcallfunc
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:85693:80: error: unknown type name ‘__pyx_vectorcallfunc’; did you mean ‘vectorcallfunc’?
      85693 | static CYTHON_INLINE PyObject *__Pyx_PyVectorcall_FastCallDict(PyObject *func, __pyx_vectorcallfunc vc, PyObject *const *args, size_t nargs, PyObject *kw)
            |                                                                                ^~~~~~~~~~~~~~~~~~~~
            |                                                                                vectorcallfunc
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c: In function ‘__Pyx_CyFunction_CallAsMethod’:
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:86382:6: error: unknown type name ‘__pyx_vectorcallfunc’; did you mean ‘vectorcallfunc’?
      86382 |      __pyx_vectorcallfunc vc = __Pyx_CyFunction_func_vectorcall(cyfunc);
            |      ^~~~~~~~~~~~~~~~~~~~
            |      vectorcallfunc
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:3524:45: error: initialization of ‘int’ from ‘vectorcallfunc’ {aka ‘struct _object * (*)(struct _object *, struct _object * const*, long unsigned int,  struct _object *)’} makes integer from pointer without a cast [-Wint-conversion]
       3524 | #define __Pyx_CyFunction_func_vectorcall(f) (((PyCFunctionObject*)f)->vectorcall)
            |                                             ^
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:86382:32: note: in expansion of macro ‘__Pyx_CyFunction_func_vectorcall’
      86382 |      __pyx_vectorcallfunc vc = __Pyx_CyFunction_func_vectorcall(cyfunc);
            |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:86385:16: error: implicit declaration of function ‘__Pyx_PyVectorcall_FastCallDict’; did you mean ‘__Pyx_PyObject_FastCallDict’? [-Wimplicit-function-declaration]
      86385 |         return __Pyx_PyVectorcall_FastCallDict(func, vc, &PyTuple_GET_ITEM(args, 0), (size_t)PyTuple_GET_SIZE(args), kw);
            |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            |                __Pyx_PyObject_FastCallDict
      scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_ufuncs.c:86385:16: error: returning ‘int’ from a function with return type ‘PyObject *’ {aka ‘struct _object *’} makes pointer from integer without a cast [-Wint-conversion]
      86385 |         return __Pyx_PyVectorcall_FastCallDict(func, vc, &PyTuple_GET_ITEM(args, 0), (size_t)PyTuple_GET_SIZE(args), kw);
            |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      [859/1383] Generating 'scipy/optimize/_lsq/givens_elimination.cpython-313t-x86_64-linux-gnu.so.p/givens_elimination.c'
      [860/1383] Generating 'scipy/optimize/_highs/_highs_wrapper.cpython-313t-x86_64-linux-gnu.so.p/_highs_wrapper.cpp'
      [861/1383] Generating 'scipy/linalg/cython_lapack.cpython-313t-x86_64-linux-gnu.so.p/cython_lapack.c'
      [862/1383] Compiling C++ object scipy/special/_ufuncs_cxx.cpython-313t-x86_64-linux-gnu.so.p/ellint_carlson_wrap.cxx.o
      [863/1383] Compiling C++ object scipy/special/_gufuncs.cpython-313t-x86_64-linux-gnu.so.p/_gufuncs.cpp.o
      [864/1383] Generating scipy/linalg/flapack_module with a custom command
      [865/1383] Compiling C++ object scipy/special/_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/special_wrappers.cpp.o
      In file included from ../scipy/special/special/amos.h:3,
                       from ../scipy/special/special/airy.h:3,
                       from ../scipy/special/special_wrappers.cpp:3:
      In function ‘void special::amos::unik(std::complex<double>, double, int, int, double, int*, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*)’,
          inlined from ‘int special::amos::unk1(std::complex<double>, double, int, int, int, std::complex<double>*, double, double, double)’ at ../scipy/special/special/amos/amos.h:5485:13:
      ../scipy/special/special/amos/amos.h:5177:5: warning: ‘initd’ may be used uninitialized [-Wmaybe-uninitialized]
       5177 |     if (*init == 0) {
            |     ^~
      ../scipy/special/special/amos/amos.h: In function ‘int special::amos::unk1(std::complex<double>, double, int, int, int, std::complex<double>*, double, double, double)’:
      ../scipy/special/special/amos/amos.h:5282:20: note: ‘initd’ was declared here
       5282 |         jc, ipard, initd, ic;
            |                    ^~~~~
      [866/1383] Compiling C++ object scipy/special/_special_ufuncs.cpython-313t-x86_64-linux-gnu.so.p/_special_ufuncs.cpp.o
      In file included from ../scipy/special/special/amos.h:3,
                       from ../scipy/special/special/airy.h:3,
                       from ../scipy/special/_special_ufuncs.cpp:8:
      In function ‘void special::amos::unik(std::complex<double>, double, int, int, double, int*, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*, std::complex<double>*)’,
          inlined from ‘int special::amos::unk1(std::complex<double>, double, int, int, int, std::complex<double>*, double, double, double)’ at ../scipy/special/special/amos/amos.h:5485:13:
      ../scipy/special/special/amos/amos.h:5177:5: warning: ‘initd’ may be used uninitialized [-Wmaybe-uninitialized]
       5177 |     if (*init == 0) {
            |     ^~
      ../scipy/special/special/amos/amos.h: In function ‘int special::amos::unk1(std::complex<double>, double, int, int, int, std::complex<double>*, double, double, double)’:
      ../scipy/special/special/amos/amos.h:5282:20: note: ‘initd’ was declared here
       5282 |         jc, ipard, initd, ic;
            |                    ^~~~~
      [867/1383] Compiling C++ object scipy/special/_ufuncs_cxx.cpython-313t-x86_64-linux-gnu.so.p/meson-generated__ufuncs_cxx.cpp.o
      ninja: build stopped: subcommand failed.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

SciPy/NumPy/Python version and system information
python - 3.13.0 sys.version_info(major=3, minor=13, micro=0, releaselevel='final', serial=0)
numpy - 2.1.2
scipy - 1.14.1
gcc - 14.2.1
linux - 6.11.2-zen1-1-zen

I suppose the obvious observation is that we do provide regular Python 3.13 wheels for our latest stable release (1.14.1) on PyPI but not free-threaded Python 3.13 wheels, so that's likely why you're hitting the source build in the free-threaded case.
IIRC we weren't quite ready to fully support free-threaded Python in SciPy just yet. sklearn seems to be waiting for us at https://github.com/scikit-learn/scikit-learn/issues/28978#issuecomment-2393173700.
Let me poke a bit locally..

x-ref gh-20669

I can reproduce locally on Linux in a Python 3.13.0 stable release (free-threaded) venv when pip pulls in the 1.14.1 tarball and tries to build it from source. Some of this is discussed elsewhere like here:
https://github.com/scikit-learn/scikit-learn/issues/28978#issuecomment-2127587244
where __pyx_vectorcallfunc problem is described as fixed in newer Cython. I also seem to have some weird PATH behavior issues with venv in Python 3.13.0.. and those also seem to be mentioned in above thread, that's annoying!

I suppose the obvious observation is that we do provide regular Python 3.13 wheels for our latest stable release (1.14.1) on PyPI but not free-threaded Python 3.13 wheels, so that's likely why you're hitting the source build in the free-threaded case.
IIRC we weren't quite ready to fully support free-threaded Python in SciPy just yet. sklearn seems to be waiting for us at scikit-learn/scikit-learn#28978 (comment).
Let me poke a bit locally..

Yes, now it is clear. Free-threaded version is very new and provides some slowdowns now. So we can wait for more optimizations.

SciPy 1.15.0rc1 is up on PyPI and it does have cp313t (free-threaded) wheels for macOS, Linux and Windows. So I'll close this issue.
You can install the wheels with pip install scipy --pre right now, and the --pre flag won't be needed anymore once 1.15.0 is final in January.
Thanks all!


Remove AVX backend

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#616  👈
#615
#614
#613
#612
#611
#610
#609
#608
#607
#606
#605
#604
#603
#599
#596
#602
#595
#601
#594
#600
#593
#592
#591
dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @andrewmilson and the rest of your teammates on  Graphite

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

:exclamation: No coverage uploaded for pull request base (05-04-Convert_wide_fibbonacci_AVX_backend_example_to_SIMD_backend@e538634). Click here to learn what that means.

Additional details and impacted files
@@                                         Coverage Diff                                          @@
##             05-04-Convert_wide_fibbonacci_AVX_backend_example_to_SIMD_backend     #616   +/-   ##
====================================================================================================
  Coverage                                                                     ?   91.22%
====================================================================================================
  Files                                                                        ?       69
  Lines                                                                        ?     8957
  Branches                                                                     ?     8957
====================================================================================================
  Hits                                                                         ?     8171
  Misses                                                                       ?      712
  Partials                                                                     ?       74

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


Add alert for insufficient number of nodes with KVM resources

Signed-off-by: Andrey Odarenko<EMAIL_ADDRESS>
What this PR does / why we need it:
This PR introduces new Prometheus alert that will fire when insufficient number of nodes with KVM resource available is detected in the cluster. The threshold is 2 (as we need 2 nodes for live migration).
Which issue(s) this PR fixes
https://issues.redhat.com/browse/CNV-7779
Special notes for your reviewer:
Release note:

NONE

Hi, thank you for the PR! Can you please add unit and functional tests as well?

Hi. Will do.

Hi, thank you for the PR! Can you please add unit and functional tests as well?

Hi. Will do.

/retest

/retest

@xpivarc can you take a look as well? I think you did some mtrics work in the past as well

@xpivarc can you take a look as well? I think you did some mtrics work in the past as well

/lgtm

/lgtm

/retest
Flaky unit test, yikes.

/retest
Flaky unit test, yikes.

/retest

/retest

/retest

/retest

/assign @rmohr

/assign @rmohr

/approve

/approve

/retest

/retest

/retest

/retest


Embark doesn't support .vy files (Vyper)

The Embark framework doesn't seem to support the official Vyper contract file extension which is .vy. It only recognizes the .v.py extension.

Thanks, I also can't deploy Vyper contracts for some reason, and I get this error message as well:
Error Compiling/Building contracts: Solidity errors: No input sources specified.

Fixed in 3.0.5


Fix regex for parsing apple cert common name field

Same as #4894

Looks good.  Clever idea to allow user input as backup.  Consider trimming the user input.

I am not sure if we trim user input in other places.  I prefer not touch any user inputs though.  :)


Documentation for adapters

Is your feature request related to a problem? Please describe.
Its tricky to know what adapters are available.
Some background first...
Adapters have a (somewhat nuanced) system for deciding which to apply. Take the following, for example:
@load_from.csv(path=source("data_path"))
def process_data(data: pd.DataFrame) -> pd.DataFrame:
    return _process(data)

This delegates to a subclass of DataLoader. Each available subclass is registered (we register all the default adapters here.
To choose which class to apply, we make the decision based on:

Filter all known data adapters to the data adapters that have the registered key csv (https://github.com/DAGWorks-Inc/hamilton/blob/131b75c1e7975d6c4f21ea5252955d51e5d99192/hamilton/function_modifiers/adapters.py#L276)
Filter all matching data adapters to the last in the list that applies to the parameter name (in this case, there is just one parameter name, data. In others, we use the inject_ param). (https://github.com/DAGWorks-Inc/hamilton/blob/131b75c1e7975d6c4f21ea5252955d51e5d99192/hamilton/function_modifiers/adapters.py#L90)

Then we validate that the data adapter class is a dataclass, and has constructor parameters that are compatible with the params to the decorator.
In all of this, its unclear what parameter map to what dataclasses. We should make that clearer.
Describe the solution you'd like
Some sort of addition to the docs for each available one. Perhaps...

A generated list of (key, pair) -> params in the doc
Classdocs for each adapter class with some convention that we can (ideally) test for
???

To get started, you can look here. One idea could be dynamically assigning the class string based on the key/params/whatnot... But that might be too complicated. Might be that just exposing them and adding docs works well.

This is complete -- see https://github.com/DAGWorks-Inc/hamilton/pull/264


Rename Licence to License

Whilst they're interchangeable, this is the idiomatic choice. LICENSE is already the most popular choice, with around 10x more occurrences than LICENCE.
It is also the name used by GitHub: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#where-does-the-license-live-on-my-repository
Trello: https://trello.com/c/P0DpFcwW/260-standardise-all-license-files-names-to-license

Just a quick drive by comment, as you might be about to open lots of PR’s, this choice conflicts with the gds-way: https://gds-way.cloudapps.digital/manuals/licensing.html

Argh - you're right. We decided to use LICENSE in the Developer Tools meeting, but didn't know the GDS Way had guidance on this.
The key thing is to make it consistent; the choice of spelling doesn't matter much. I'll go back and close those PRs 😅

Argh - you're right. We decided to use LICENSE in the Developer Tools meeting, but didn't know the GDS Way had guidance on this.
The key thing is to make it consistent; the choice of spelling doesn't matter much. I'll go back and close those PRs 😅

Oh sorry I didn't clock this in the meeting before you did a bunch of the work :(
This has always been a bit of a pain, the rest of the world seems to have agreed on LICENSE and it's so prevalent in open source software that it's almost impossible for it to stop creeping into our codebases. However I do remember there were some strong opinions towards using the British spelling the last time it was debated.
Do agree with consistency, but long battle :)


[Feature] Enable/Disable Soft Delete

I would like to delete posts or categories permanently, as they are currently only soft deleted. Right now, deleting an item only adds a date to the deleted_at column in the database without actually removing it. This is causing issues because when I try to create a new post or category with the same slug, an error appears. thanks

hi @aguspranyoto there is no way to do that for now but we will try to add this feature to the next release of v2


Starter Templates in README is a broken link

This is about:

[ ] A typo
[ ] Innaccurate/misleading documentation (e.g. technically incorrect advice)
[ ] Undocumented code
[ ] Outdated documentation
[X] Other

Problem
The link to "Starter Templates" near the bottom of the README in the "Next Steps" section is broken.  I'm not sure if the starter templates were moved or what.

I'm unable to find any README.md files that have this issue, I'm not able to find it on the website either.
I've done a search on the entire repo for the terms Starter Templates and Next Steps and can't find anything that seems to resemble this issue.
Could you provide a link to the file you're mentioning?

I had a look around and assume they were referring to the README in the examples folder which contains the Next steps section and a valid starter templates link. However if you look at the page in a different branch e.g. an older version the link is broken which is probably what happened.

I just checked and the link in examples README is fine. There's no starter link in the top level README

I'm found the same issue. Steps to reproduce:

On https://yew.rs/docs/getting-started/examples (version 0.20), click examples
Scroll down to README.md file (https://github.com/yewstack/yew/tree/yew-v0.20.0/examples)
On section Next steps, click on starter templates
This should bring https://yew.rs/docs/getting-started/starter-templates - Page Not Found


Improve bfs -help with LESS already set

RE: @markus-oberhumer's https://github.com/tavianator/bfs/pull/68
I think it makes sense to not override LESS, in case it's necessary for less to work properly in the user's environment.  But I can think of a couple improvements that would make sense:

Override LESS if it's empty.  Similar to the new PAGER handling.  I think git ought to do the same thing.
If LESS is nonempty, don't colorize the help.  This should at least make it readable for you.  And if you want the colors, you could do LESS= bfs -help.

But I just thought of a complication: if $PAGER != less, it's weird for $LESS to affect the behaviour of bfs help.  Thoughts?

I think it makes sense to not override LESS, in case it's necessary for less to work properly in the user's environment. But I can think of a couple improvements that would make sense:
* Override `LESS` if it's empty.  Similar to the new `PAGER` handling.  I think `git` ought to do the same thing.

Yes, that makes sense. BTW, my code from #68 is buggy as mixes putenv with the explicit envp parameter - I can submit a new version if you want.

* If `LESS` is nonempty, don't colorize the help.  This should at least make it readable for you.  And if you want the colors, you could do `LESS= bfs -help`.

But I just thought of a complication: if $PAGER != less, it's weird for $LESS to affect the behaviour of bfs help. Thoughts?

After some more googling around I wouldn't touch that code - more works out of the box, and it's probably time for me to change my defaults to export LESS="-R -MM -i".
Thanks!

Yes, that makes sense. BTW, my code from #68 is buggy as mixes putenv with the explicit envp parameter - I can submit a new version if you want.

Oh true.  Better to just change how parse.c constructs the new environment I think.  bfs_spawn_addputenv() has some other semantic issues like how it interacts with PATH (come to think of it, I think my spawn.c is already wrong about this on some platforms), and it would make #47 even more challenging.
So if you feel like submitting a patch that just fixes the empty LESS case, I'd take it and consider this issue closed.


feat(database): migrate to mongo, finish REQ and EVENT.

Description
Related Issue

Fixes #50

also, consider fixing failed pipelines.

3 more things:

take different actions based on event kind range.
when there is no kind in a filter, search on all documents.
mark nip-01 as supporters. dx.


make bundle fails with go version 1.18

Error: bash: line 1: rhodf/odf-multicluster-operator-bundle-container/odf-multicluster-operator-bundle-container/odf-multicluster-operator-bundle/src/bin/controller-gen: No such file or directory 13:04:15  make: *** [Makefile:38: manifests] Error 127

Is fixed in https://github.com/red-hat-storage/odf-multicluster-orchestrator/pull/128


Update openshift to 4.4. and k8s to 1.17

What type of PR is this?
/kind dependency-change
What does does this PR do / why we need it:

updates OpenShift libraries to 4.4 and k8s libs to 4.4
This is required to be able to add additional functionality that is not available in the previous versions

Which issue(s) this PR fixes:
Fixes https://github.com/openshift/odo/issues/3077
How to test changes / Special notes
just build and run odo, it should work as before

/retest

/retest

https://travis-ci.com/github/openshift/odo/jobs/328172115#L723
It seems to fail because we are not providing the two required flags

@kadel I can't even load the 30k+ file changes on the browser. Retried a couple of times :D

https://travis-ci.com/github/openshift/odo/jobs/328172115#L723
It seems to fail because we are not providing the two required flags

The new version of Cobra changed the capitalization of the first letter in the error message. This is why the test was failing

/approve

The new version of Cobra changed the capitalization of the first letter in the error message. This is why the test was failing

OK :+1: I guess I missed it.


Bug: Duplicates are written to constraints file during bootstrapping

During bootstrapping, duplicates are written to constraints file. Below is the subset of output for graph explain-duplicates command which uses recently produced graph.json:
tokenizers
  0.20.4
    tokenizers<0.21,>=0.20 matches ['0.20.4']
      transformers==4.46.3
  0.21.0
    tokenizers>=0.11.1 matches ['0.21.0', '0.20.4']
      instructlab==0.21.0
    tokenizers<0.22,>=0.21 matches ['0.21.0']
      transformers==4.47.0
    tokenizers>=0.19.1 matches ['0.21.0', '0.20.4']
      vllm==0.6.2
  * No single version of tokenizers meets all requirements

transformers
  4.46.3
    transformers<4.47.0 matches ['4.46.3']
      trl==0.12.2
  4.47.0
    transformers>=4.41.2 matches ['4.47.0', '4.46.3']
      instructlab==0.21.0
      instructlab-sdg==0.6.1
    transformers matches ['4.47.0', '4.46.3']
      peft==0.14.0
      instructlab-eval==0.4.1
    transformers>=4.45.2 matches ['4.47.0', '4.46.3']
      instructlab-training==0.6.1
    transformers>=4.40.0 matches ['4.47.0', '4.46.3']
      instructlab-dolomite==0.2.0
    transformers>=4.1 matches ['4.47.0', '4.46.3']
      lm-eval==0.4.5
    transformers>=4.45.0 matches ['4.47.0', '4.46.3']
      vllm==0.6.2
  * transformers==4.46.3 usable by all consumers

The issue here is that fromager thinks it cannot pick a single version of tokenizers, but it could do that if it recognized that only one version of transformers is needed and it used that information to pick the version of tokenizers.


sever candidate & server primary(diff) has different url

Hi diffy's developers,
If the sever candidate & server primary(diff) has different url, for ex, a.com/v1/getuser & a.com/v2/getuser, how should I write the conf, as long as I know, "-candidate" should be like this "ip:post".
Thanks!

I want write like this..
-candidate='...:8080/v1/web'
-master.primary='...:8080/v2/web'
-master.secondary='...:8080/v1/web' \

hi @colozou i have added support to add different api roots to the api calls. You can get it from my forked repository. I am still waiting to create a pull request.


support rotate authentication key and manager rotate capability

is part of https://github.com/rooch-network/rooch/issues/16

Put this to v0.2

Put this to v0.2

ok


Delete wdavstatus.md

deleting page, as table was depricated 2 years ago. Not part of Update compliance or Desktop Analytics.

@UCOwner : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

@UCOwner
Please use the private repo https://github.com/MicrosoftDocs/azure-reference-other-pr/blob/main/azure-monitor-ref/tables/wdavthreat.md


[Compat] BYG Woods and Stones cannot be used as materials

Minecraft Version
1.18.2
Fabric/Quilt Version
Quilt 0.17.6
Fabric/Quilt API Version
QFAPI-1.0.0-beta.26+0.59.1-1.18.2
Tinkers' Construct Version
1.18.2-<IP_ADDRESS>
Describe your issue
None of Oh The Biomes You'll Go woods or stones were able to be used as tool materials.

No
Performance Enchancers
Sodium
Searched for known issues?
Checked pinned issues, Searched open issues, Searched closed issues, Checked the FAQ

In order for BYG to support Hephaestus they need to add their materials to the tags we use such as c:rods/wooden


Imaginary programming + barliman? Please take a look at implementing a scheme version

Hi William
https://mullikine.github.io/posts/designing-an-imaginary-programming-ip-library-for-emacs/
I have been working on ilambda, a set of functions for code generation, and imaginary evaluation. It's a small set of functions that would be easy to implement for scheme, but would require some prompt engineering on my part, and I was wondering if you'd be interested in collaborating.
Thank you!

Also, I'd be really interested in porting Barliman to emacs lisp, and integrating into Pen.  https://github.com/semiosis/pen.el

Also, I'd be really interested in porting Barliman to emacs lisp, and integrating it with Pen.el! https://github.com/semiosis/pen.el


Defaulting port for addTarget command switch 'zsurl'

The 'addTarget' command should be able to accept also a 'zsurl' value like 'http://testing-platform' or 'https://testing-platform' , defaulting the port to 10081 or 10082 respectively.

Not sure this is correct. Why to drop on default? If someone has the GUI on non-standard port on NAT with multiple dev servers?
10081 and 10082 should always be visible, so if they are in the ZSURL, listTargets will show you the port and you don't "accidentally" miss that and break your head why you don't get the GUI on HTTP 80 or HTTPS 443 in browser.
But - feel free to enhance if you still fell its wanted.

If the port is given, it stays the same, but if it's not given it should default according to the schema.
Right now, if you put --zsurl='http://testing-platform' it fails on an uncaught RuntimeException. Why not try defaulting on 'http://testing-platform:10081'?

right. I think it should respond back with a note about defaulting to 10081 or 10082, in case the user needs to alter the target. Thanks


Not working with Xiaomi Mi 9T

I've tried a lot of things but app didn't work. Please help me.

@MerlionRock please answer me ASAP

Enable USB Debugging (security setting).
There are two USB debugging settings for xiaomi phone. If still can't work, ask in discord.
This will be closed as there are no additional console log.

Can you write your discord link?


Try and avoid a condescending tone in the manual, either the reference or tutorial part

Problem or new feature
This is mainly to discuss the issue raised in this PR  → #3993. In general, try and avoid tone that some people try and find condescending, without incurring in a too dry tone that people might also dislike.
Suggestions

In the case of "of course" and "obviously": in a case by case basis, see if this particular link is needed, or it can be eliminated along with the rest of the sentence. Alternatives: link to the reference or tutorial so that people can really see why that's so clear that it's preceded by an "of course"
Other cases, again deal with them in a case by case basis.

Additionally, create an author test that warns someone if they're using that sentence, and potential caveats it carries.

Putting this in an author test is going to be basically impossible.
We can definitely review all existing uses of it, add a note to the style guide, and review future edits in light of that.

There is hardly a way we can address this issue in an "open the ticket, resolve, close the ticket" fashion. This one is too broad, too subjective to work on it it as a "meta" ticket.

Other cases, again deal with them in a case by case basis.

To do this, having this ticket around is not needed nor helpful, so closing.


elastalert feels very unhappy (circuit_breaking_exception, Data too large)

My elastalert test instance is continuously throwing exceptions:
elasticsearch.exceptions.TransportError: TransportError(429, 'circuit_breaking_exception', '[parent] Data too large, data for [<http_request>] would be [1442489726/1.3gb], which is larger than the limit of [1394606080/1.2gb], real usage: [1442489056/1.3gb], new bytes reserved: [670/670b]')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/elastalert-0.2.1-py3.6.egg/elastalert/elastalert.py", line 1599, in writeback
    res = self.writeback_es.index(index=index, body=body)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/client/utils.py", line 84, in _wrapped
    return func(*args, params=params, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/client/__init__.py", line 364, in index
    "POST", _make_path(index, doc_type, id), params=params, body=body
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/transport.py", line 350, in perform_request
    timeout=timeout,
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/connection/http_requests.py", line 156, in perform_request
    self._raise_error(response.status_code, raw_data)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/connection/base.py", line 181, in _raise_error
    status_code, error_message, additional_info
elasticsearch.exceptions.TransportError: TransportError(429, 'circuit_breaking_exception', '[parent] Data too large, data for [<http_request>] would be [1442493394/1.3gb], which is larger than the limit of [1394606080/1.2gb], real usage: [1442489056/1.3gb], new bytes reserved: [4338/4.2kb]')
WARNING:elasticsearch:GET http://helk-elasticsearch:9200/logstash-*/_search?_source_includes=%2A%2C%40timestamp&ignore_unavailable=true&scroll=30s&size=10000 [status:429 request:0.005s]
ERROR:root:Error running query: TransportError(429, 'circuit_breaking_exception', '[parent] Data too large, data for [<http_request>] would be [1442490142/1.3gb], which is larger than the limit of [1394606080/1.2gb], real usage: [1442489056/1.3gb], new bytes reserved: [1086/1kb]')
WARNING:elasticsearch:POST http://helk-elasticsearch:9200/elastalert_status_error/_doc [status:429 request:0.004s]
ERROR:root:Error writing alert info to Elasticsearch: TransportError(429, 'circuit_breaking_exception', '[parent] Data too large, data for [<http_request>] would be [1442493804/1.3gb], which is larger than the limit of [1394606080/1.2gb], real usage: [1442489056/1.3gb], new bytes reserved: [4748/4.6kb]')
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/elastalert-0.2.1-py3.6.egg/elastalert/elastalert.py", line 383, in get_hits
    **extra_args
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/client/utils.py", line 84, in _wrapped
    return func(*args, params=params, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/client/__init__.py", line 819, in search
    "GET", _make_path(index, "_search"), params=params, body=body
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/transport.py", line 350, in perform_request
    timeout=timeout,
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/connection/http_requests.py", line 156, in perform_request
    self._raise_error(response.status_code, raw_data)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/connection/base.py", line 181, in _raise_error
    status_code, error_message, additional_info
elasticsearch.exceptions.TransportError: TransportError(429, 'circuit_breaking_exception', '[parent] Data too large, data for [<http_request>] would be [1442490142/1.3gb], which is larger than the limit of [1394606080/1.2gb], real usage: [1442489056/1.3gb], new bytes reserved: [1086/1kb]')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/elastalert-0.2.1-py3.6.egg/elastalert/elastalert.py", line 1599, in writeback
    res = self.writeback_es.index(index=index, body=body)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/client/utils.py", line 84, in _wrapped
    return func(*args, params=params, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/client/__init__.py", line 364, in index
    "POST", _make_path(index, doc_type, id), params=params, body=body
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/transport.py", line 350, in perform_request
    timeout=timeout,
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/connection/http_requests.py", line 156, in perform_request
    self._raise_error(response.status_code, raw_data)
  File "/usr/local/lib/python3.6/dist-packages/elasticsearch-7.0.4-py3.6.egg/elasticsearch/connection/base.py", line 181, in _raise_error
    status_code, error_message, additional_info
elasticsearch.exceptions.TransportError: TransportError(429, 'circuit_breaking_exception', '[parent] Data too large, data for [<http_request>] would be [1442493804/1.3gb], which is larger than the limit of [1394606080/1.2gb], real usage: [1442489056/1.3gb], new bytes reserved: [4748/4.6kb]')
ERROR:root:Error running query: ['Failed to parse query [(event_id:1 AND process_parent_name:"services.exe" AND NOT (process_path:"\\windows\\system32" OR process_path:"\\program files\\windows defender\\mpcmdrun.exe" OR "\\program files (x86)\\google\\update\\googleupdate.exe" OR "c:\\windows\\servicing"))]']

Is my test system's memory insufficient or is this an elastalert bug? It is running in Docker on a hyper-v vm with dynamic memory enabled, in case that matters. ES version is 7.0.1.

just curious.. what java garbage collection are you using? if its G1GC, there is a known bug..
and actually looking at this - are you using HELK? if so, move this over to the HELK github - I can help you out, as I am one of the commiters

Yeah my setup is based on HELK, but is this issue HELK-related?
Helk's elasticsearch is just a FROM docker.elastic.co/elasticsearch/elasticsearch:7.0.1, nothing extraordinary or custom, do you know which GC they use?
I noticed I can make the problem disappear by throwing more memory at elasticsearch, but this still is an elasticsearch or elastalert bug, isn't it?

Not sure if this is relevant, but you can change max_query_size to a lower amount (10k is default) to lower the size of each query.

hey @Qmando i have set max_query_size to 5000 i am not seeing this above error

@aniketpant1
I don't usually use Elast Alert at all. Of course, it is not in operation.
Please note that we are not the developer of ElastAlert and cannot guarantee that the advice will be helpful to your issue.
Java heap memory exhausted due to over-opening of indexes
circuit_breaking_exception may occur
→ ElasticSearch heap size change
→ Elastic Search
Changes to indices.breaker.total.limit
→ Delete Index data of ElasticSearch, or close unnecessary Index data
Elasticsearchのインデックス開きすぎによるヒープメモリ枯渇
elastalert feels very unhappy (circuit_breaking_exception, Data too large) #2485
circuit_breaking_exception, Data too large #349
After Upgrade to 6.2.4 Circuitbreaker Exception Data too large #31197
Elastalert deployment failed


General::buildPaginationElement() should be moved elsewhere

It does not belong in this class...

@nitriques: Why have you assigned me?

Github suggested it and I told myself, what the heck, let's do it. Please do not see this as an "order" just like a @ mention.


Simplify core operation classes

In PR #1391 we finally started documented operations. While doing through this tutorial in #1384, we realized that we hardly ever use anything other than ElementOperation.
MapOperation has never been used to our knowledge and its definition is so light a user might as well just write their own param.ParameterizedFunction. This just leaves TreeOperation which has only been used by the holoviews devs in a few places (in particular, one operation in featuremapper is a tree operation).
My recommendation is as follows:

Remove MapOperation entirely
Fold the current Operation baseclass into ElementOperation
Rename ElementOperation to Operation (a better name for users).
Leave a class ElementOperation(Operation): definition just to issue a deprecation warning.
Remove TreeOperation, factoring any general and useful functionality into a utility.

This plan maintains backwards compatibility as we never used or documented MapOperation and TreeOperation is very unlikely to be used by users as it is needed for rare, more complex tasks (and was also undocumented).
Having a single Operation base class would simplify things a lot!

Everything suggested in this issue has been addressed by the PR referenced above (#1421) except for removing TreeOperation.
@philippjfr Happy for me to just remove it from HoloViews and add it to featuremapper?

Sure, as long as you update the imports in topographica as well.

The final bit (removing TreeOperation) was merged in the PR above. Closing.