Error reverting block: null value in column "data" violates non-null constraint

Seen on 0x subgraph:
Chain head pointer, number: 6927382, hash: 0x7fbc4c8a9aff2d4c285005a1b22007f7ebd866a27c170dcef2f9ea384dcdb897, component: BlockStream
Subgraph pointer, number: 6927352, hash: 0x8cc052f3c841987e7a7f8c63e7f9354228e94d94eb8794979a99f3ca89475c84, component: BlockStream
Reverting block to get back to main chain, block_hash: 0x8cc0…5c84, block_number: 6927352, component: BlockStream
Trying again after error in block stream reconcile: Error reverting block: null value in column "data" violates not-null constraint, component: BlockStream
Identify next step, component: BlockStream
Subgraph pointer, number: 6927352, hash: 0x8cc052f3c841987e7a7f8c63e7f9354228e94d94eb8794979a99f3ca89475c84, component: BlockStream
Chain head pointer, number: 6927382, hash: 0x7fbc4c8a9aff2d4c285005a1b22007f7ebd866a27c170dcef2f9ea384dcdb897, component: BlockStream
Reverting block to get back to main chain, block_hash: 0x8cc0…5c84, block_number: 6927352, component: BlockStream
Trying again after error in block stream reconcile: Error reverting block: null value in column "data" violates not-null constraint, component: BlockStream
Identify next step, component: BlockStream
Subgraph pointer, number: 6927352, hash: 0x8cc052f3c841987e7a7f8c63e7f9354228e94d94eb8794979a99f3ca89475c84, component: BlockStream
Chain head pointer, number: 6927383, hash: 0x44af4c5de55b58cda6ac8d67a34628c1444e1efff7ae444d0b047ba120b3308a, component: BlockStream
Reverting block to get back to main chain, block_hash: 0x8cc0…5c84, block_number: 6927352, component: BlockStream
Trying again after error in block stream reconcile: Error reverting block: null value in column "data" violates not-null constraint, component: BlockStream
Identify next step, component: BlockStream
Chain head pointer, number: 6927384, hash: 0xd41d142ebed3bff2a224f6fc13051e6bbce1b4d2102b5a9fb18106856b7852b1, component: BlockStream
Subgraph pointer, number: 6927352, hash: 0x8cc052f3c841987e7a7f8c63e7f9354228e94d94eb8794979a99f3ca89475c84, component: BlockStream
Reverting block to get back to main chain, block_hash: 0x8cc0…5c84, block_number: 6927352, component: BlockStream
Subgraph instance failed to run: Error reverting block: null value in column "data" violates not-null constraint, id: QmdecCGpn5FMQQRFzQCNuNB4wLjb9Qtph3BtfRzvpKAz5T
Terminating chain head updates, component: BlockStream

The error happens in Store::revert_block_operations when the revert_block SQL function is called

It looks like the issue is with the logging of the entity update operation that revert_block is attempting to reverse.   The operation that is being reversed (see image below for details) logged 5 operations, all of which were logged as updates (op_id=1.) However, 2 of the operations have a null data_before value. During the revert process revert_entity_event is attempting to upsert this null data_before value into entities.data and running into a non-null constraint.
Correct entity_history logging behavior:

If the operations were updates there should be non-null json data in the data_before column.
If the operations were inserts the op_id should be 0.


Missing text style customization - Theming Codelab - Step 8

No text style customization is made in this code snippet

Thanks for the report. I've fixed this internally and it will be released in our next update.


Fix README example

The example in the README referenced the wrong repository name (it said cla-assistant instead of cla-signature-bot). It also referenced an older release (v2.0.0).
The example has been updated to use the correct repository name, and to reference a less specific version.

I'm guessing I need to comment for the CLA signature bot comment to show up

I have read the CLA Document and I hereby sign the CLA


Get e2e tests running on local-tableland

@sanderpick I made a few changes to get the e2e tests running here.  Tape, Mocha, and Typescript don't seem to play well together, and I had to remove the "@types/mocha" dev dependency.
Also this only work if you're running against the main branch of local-tableland.  I'll publish that shortly, but right now you have to use npm link

awesome. thank you!

@joewagner did you happen to publish a new version of local-tableland with your changes?

@sanderpick I just merged this PR https://github.com/tablelandnetwork/local-tableland/pull/54
Which should publish pre12

looks like it needs a tag to kick it off: https://github.com/tablelandnetwork/local-tableland/blob/main/.github/workflows/publish.yml#L5

Dang, I forgot to tag it.  I just published v0.0.0-pre12 manually


adding information about offline installer

Fixes #1094
/cc @terrajobst

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/windows-prerequisites?branch=pr-en-us-1119

Status: Succeeded.
Open Publishing Report.

I'd say :shipit:

I got approvals on e-mail too 😄


Style changes between local and live?

There's some significant styling differences in some elements when running in dev mode v's preview, build, and live modes
It's like Astro is overriding some css during the build process
I've only noticed it on 2 things and both times it's on .container divs
there's an open ticket on the original repo here https://github.com/markteekman/accessible-astro-starter/issues/60 which alludes to page zoom though i'm not sure that's the problem
you can see the page width container is lots wider in local dev mode vs live
and there's also no padding on the Stats container (contain the numbers)
note: i really prefer the wider page though it looks like the default starter theme is narrow https://accessible-astro.netlify.app/
and i've added the padding to the Stats container but it's being stripped or overridden
there's also a Netlify site linked to this repo so this is a live working example too: https://nutritionsolutions.au/

I found someone else in the Astro Discord who might be experiencing the same issue (https://discord.com/channels/830184174198718474/1086319574380716152/1086319574380716152)
the peeps in Discord are pointing to this as the fix: https://docs.astro.build/en/guides/configuring-astro/#customising-output-filenames

What I’ve found so far: on the live site (and in local previews after npm run build), the vertical padding is overridden in a file called 404.something.css. That’s not the case in dev mode, where the styles are injected into the page and those rules aren’t present.

That’s not the case in dev mode, where the styles are injected into the page and those rules aren’t present.

I was wrong. They are present, but much lower in precedence, which is why they aren’t applied. To simplify, you have this in one CSS file:
.container {
  padding: 0 2rem;
}

And this in another:
.py-16 {
  padding: /* something large */;
}

The latter works in dev because it’s injected into the page at the right time, but when everything is bundled up, the order changes, so the former takes precedence. To fix this, I would suggest either replacing the container class with a bunch of Tailwind equivalents or creating a new variant of the class with the padding you want and using that on the front page. Let me know which you’d prefer.

Your container class is battling Tailwind’s container class.


TimedLeg is notServicedStop=true but trip is not cancelled

The trip has LegBoard and LegAlight of firstTimedLeg marked as notServicedStop=true. The trip itself is only marked as "deviation=true", but when the first TimedLeg can't be used, shouldn't be the trip marked as cancelled?
Data Gist
TripId: ID-F82F73D0-0B2B-4BE9-88C0-8DE2DD0C5D6A

Aus unserer Sicht ist nach dem Gespräche Session erklärende Echtzeit das Theme besprochen. Der OJP2.0 macht im Moment alles korrekt

See #126

TripStatus.Cancelled will be removed.
ServiceStatus.Cancelled will be implemented, but only set to true if the whole service is cancelled and not parts of it.


Extend vue loader config to use sass options

I wonder if it's possible to extend the settings how nuxt.js is loading vue files. Basically I want to achieve the following snippet to work:
<!-- arbitrary-component.vue -->
<style lang="scss">
  @import 'arbitrary-dependency/arbitrary-scss-file';
</style>

Currently it throws the following error:
Module build failed:
@import 'arbitrary-dependency/arbitrary-scss-file';
^
      File to import not found or unreadable: arbitrary-dependency/arbitrary-scss-file.

What I need to do is to tell the sass-loader to resolve the node_modules directory with the available option includePaths. Normally, I'd attend the corresponding query to my loader configuration like so:
{
  test: /\.scss$/,
  loader: 'sass-loader?' + JSON.stringify({ includePaths: [path.resolve(__dirname), 'node_modules'] })
}

However, I can't add this to the loader section because that's not how Nuxt.js is loading .vue files. I'd need to extend how .vue files are loaded and customize the query params in here.
I tried this with setting build.loaders (nuxt.config.js) to:
loaders: [
  {
    test: /\.vue$/,
    loader: 'vue-loader',
    query: {
      loaders: {
        'scss': 'vue-style-loader!css-loader!sass-loader?' + JSON.stringify({ includePaths: [path.resolve(__dirname), 'node_modules']
      }
    }
  }
]

Unfortunately, I then get another error within the browser saying:
TypeError: Cannot read property 'toLowerCase' of undefined

So I assume that's not the correct way to do this.
Is there an actual way how I can achieve this?

<style lang="scss">
  @import '~node_modules/arbitrary-dependency/arbitrary-scss-file';
</style>

@alexchopin is there no way to resolve it as stated in my question above? Your solution won't work, because the sass file I require also uses this notation.

@flootr use build.extend
nuxt.config.js:
const path = require('path');

module.exports = {
  build: {
    extend (config) {
      const vueLoader = config.module.rules.find((rule) => rule.loader === 'vue-loader')
      vueLoader.query.loaders.scss = 'vue-style-loader!css-loader!sass-loader?' + JSON.stringify({ includePaths: [path.resolve(__dirname), 'node_modules'] })
    }
  }
}

This worked, thanks @Atinux 💐

Hi. Thanks for answer @Atinux I had the same issue with Google's material-components-web. With this code I was able to run app without error, but if I then go to the page I got an error:
 Nuxt.js Error:

/home/nman/TESTING/mdc-nuxt/node_modules/@material/checkbox/index.js:17
import {MDCComponent} from '@material/base';
^^^^^^

SyntaxError: Unexpected token import

May be I need to add fallback? https://github.com/material-components/material-components-web/blob/master/framework-examples/vue/build/webpack.base.conf.js

See here for a solution that works for stylus as well as sass / scss: https://github.com/nuxt/nuxt.js/issues/387#issuecomment-327229427

@Atinux this solution are working no more. Is there any changes to API? Igot this error
  TypeError: Cannot read property 'loaders' of undefined

@iamdubx
``js
const path = require('path');
module.exports = {
build: {
extend (config) {
const vueLoader = config.module.rules.find((rule) => rule.loader === 'vue-loader')
vueLoader.options.loaders.scss = 'vue-style-loader!css-loader!sass-loader?' + JSON.stringify({ includePaths: [path.resolve(__dirname), 'node_modules'] })
}
}
}

Hi,
I've an error when I push on production on Dokku (Heroku like).

Cannot find module "!!vue-style-loader!css-loader!../../node_modules/vue-loader/lib/style-compiler/index?{"vue":true,"id":"data-v-4c9c6ca6","scoped":true,"hasInlineConfig":true}!sass-loader?{"includePaths":["/app/config","node_modules"]}!../../node_modules/vue-loader/lib/selector?type=styles&index=0!./index.vue"

My build config on nuxt.config.js:
build: {
    analyze: {
      analyzerMode: 'static',
      generateStatsFile: true,
      statsFilename: 'webpack-stats.json',
      openAnalyzer: false
    },
    vendor: [
      'axios',
      'vuetify'
    ],
    extend (config) {
      config.resolve.alias['vue'] = 'vue/dist/vue.common'
      const vueLoader = config.module.rules.find((rule) => rule.loader === 'vue-loader')
      vueLoader.options.loaders.scss = 'vue-style-loader!css-loader!sass-loader?' + JSON.stringify({
        includePaths: [
          path.resolve(__dirname), 'node_modules'
        ]
      })
    }
  },


Posting working papers on Arxiv

[ ] Check Zotero for working papers.
[ ] Create an account, then submit papers

IronHacks paper.
Empathy paper: submitting to Computer and Human behavior, also on Arxiv.

Next deadlines:

Jul 15th, Conversational AI
Aug 1, Architecture paper [Incomplete]; aim to submit to ESE.


404 Cannot find any route matching

Environment

Operating System: Darwin
Node Version:     v16.16.0
Nuxt Version:     3.0.0-rc.12
Nitro Version:    0.6.0
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      modules, ssr
Runtime Modules<EMAIL_ADDRESS>Build Modules:    -

Reproduction
https://github.com/qucode1/nuxt-api-route-issue/blob/master/server/api/reset-password.post.ts
Describe the bug
Server api routes that return undefined or nothing at all will run, but the server will return an error that does not help finding the issue:
export default defineEventHandler(async (event) => {
  try {
    console.log('resetPassword')
    return
  } catch (error) {
    console.log('reset password error', { error })
    return sendError(event, createError({
      ...error,
      statusMessage: error.message,
    }))
  }
})

to fix the issue you need to use event.res.end(), return null or anything else.
404 Cannot find any route matching /api/reset-password

Additional context
No response
Logs
No response

I've created an issue in unjs/h3 regarding improving that behavior ☺

Resolved in https://github.com/unjs/h3/pull/409.


Support Windows

@Munsio merging this right away to move forward with Ollama. This was not straight forward. Windows is massively incompatible with me.  Please take a look at the commits. I think we could do better with that PR, but i am  desperate to move on and tests should be green now (btw Maven, again, flaky... who knew?)


Added option to include license in repository details

@synthss Could you add a test for this?

sure, i'll try to add a test later and will update you
On Mon, Apr 8, 2019 at 6:29 AM Jared Rewerts<EMAIL_ADDRESS>wrote:

@synthss https://github.com/synthss Could you add a test for this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/github-tools/github/pull/477#issuecomment-480635435,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APACzrKdyZNUxFYFU47VF6xWgaI79981ks5venFZgaJpZM4PoHfP
.

@synthss Any progress on this?

Hi @j-rewerts
I reviewed the tests and the license is already included in Repository.getDetails method. Closing this pull request


OIDC SSO-Troubleshooting section update

JIRA ticket - https://mendix.atlassian.net/jira/software/c/projects/TW/issues/?filter=myopenissues


Adding field 'fuel consumption' in Car model

We need extra field:

fuel consumption (average fuel consumption per 100 km)

Maybe we should include the units for distance and fuel volume?

We need the car to have the following fields:

plates
description (optional)
mileage_unit (km/mi)
fuel_consumption

Also please make sure that all these fields are accessible from Django Admin.


Switch documentation host

As pointed out in #554 I didn't update the publicly hosted docs with the 2.6.9 release. I now remember that I tried but ran into problems uploading the docs. Then I ran out of time and forgot to come back to it later.
In any event as I explain here:

The homepage at http://pythonhosted.org states:

To upload documentation, go to your package edit page (http://pypi.python.org/pypi?%3Aaction=pkg_edit&name=yourpackage), and fill out the form at the bottom of the page.

However, there is no longer a form at the bottom of the edit page for uploading documentation. Instead I only see:

If you would like to DESTROY any existing documentation hosted at http://pythonhosted.org/ProjectName Use this button, There is no undo.
[Destroy Documentation]

I also went to pypi.org and logged in there. But I don't see any options for editing my projects or uploading documentation on that site.
So, how do I upload an update to my documentation?

In addition to the above, pythonhosted seems to have been rather flakey lately. I'm considering switching to GitHub Pages (probably using Organization Pages so the URL would be https://Python-Markdown.github.io). I'm not interested in readthedocs as they require you to have them build your docs and then we cannot use our own tooling to build our own docs (they do support MkDocs, but an older version with less than complete support for Markdown extensions, which is a nonstarter IMO). Any thoughts?

In case you want to update the pythonhosted.org page: last time I tried, setuptools’ upload_docs command worked. This means you can either use POST requests directly (see the implementation) or adapt that command to use your custom tarball instead of a Sphinx-generated one.

As a reminder, we are not yet using setuptools, so we don't have the upload_docs command available. We could certainly switch over (the md3 branch already has been), but that doesn't help for a previous release.
However, I do see some value in using the mechanism in that script to upload something redirecting people to the new docs.

According to pypa/setuptools@7f81445 the upload_docs command is deprecated (with a warning suggesting using RTD) and a separate comment indicates that the new "Wharehouse" (pypi.org) will not ever support hosting documentation. Unfortunately, nothing in the commit references a source (like perhaps, an official announcement?), but this isn't the first I've see that suggests pythonhosted.org may be going away completely when the switch from pypi.python.org to pypi.org is complete. My point is that we should switch now before we can't change anything on pythonhosted.org.

After some more searching, AFAICT, the official announcement to the public is buried in the discussion in pypa/warehouse#582. What is clear is that pythonhosted.org will be going away. What's not clear is if we can still update anything there (some comments seem to indicate not).
Given the state of things, I'm proposing the following plan:

First, prepare and upload docs to an alternate host (GitHub Pages via MkDocs?)
After the alternate host is live (and links are updates where we can), explore updating the existing docs on pyhtonhosted.org to redirect people to the new docs.
Finally, at some point in the future, delete the docs from pythonhosted.org.

So I successfully got the upload_docs script to run. However, the upload did not succeed. This was the output:
running upload_docs
Upload_docs command is deprecated. Use RTD instead.
Submitting documentation to https://pypi.python.org/pypi/
Upload failed (410): Gone (This API has been deprecated and removed from legacy PyPI in favor of using the APIs available in the new PyPI.org implementation of PyPI (located at https://pypi.org/). For more information about migrating your use of this API to PyPI.org, please see https://packaging.python.org/guides/migrating-to-pypi-org/#uploading. For more information about the sunsetting of this API, please see https://mail.python.org/pipermail/distutils-sig/2017-June/030766.html)

AFAICT, we can only "delete" the existing documentation. There are no options to update in any way.
Unfortunately, it seems that they skipped from step 1 to step 5 of the roadmap without bothering with steps 2, 3, & 4.

Ha, man, I love Python, but some of the PyPI decisions are weird.

For the record, the documentation is now avaialbe at https://python-markdown.github.io/.
I used to be able to edit a package's meta-data right in PyPI. Apparently, now the only way to do so is to upload a new release. Therefore, even after all that work, PyPI still points to pythonhosted.org. Guess we need to roll a new release to finalize this.


AP-2393 Ensure Proceedings are displayed in a consistent order

Ensure Proceedings are displayed in a consistent order
Link to story
In all places in the Apply service, proceedings are displayed in the order they were added to the application.
Checklist
Before you ask people to review this PR:

[ ] Tests and rubocop should be passing: bundle exec rake
[ ] Github should not be reporting conflicts; you should have recently run git rebase master.
[ ] There should be no unnecessary whitespace changes. These make diffs harder to read and conflicts more likely.
[ ] The PR description should say what you changed and why, with a link to the JIRA story.
[ ] You should have looked at the diff against master and ensured that nothing unexpected is included in your changes.
[ ] You should have checked that the commit messages say why the change was made.

Codecov Report

Merging #2725 (ea78d8c) into master (0cdb001) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master     #2725   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          532       532
  Lines        11100     11130   +30
=========================================
+ Hits         11100     11130   +30

Impacted Files
Coverage Δ

app/models/dependant.rb
100.00% <ø> (ø)

app/models/application_proceeding_type.rb
100.00% <100.00%> (ø)

app/models/cfe/base_result.rb
100.00% <100.00%> (ø)

app/models/legal_aid_application.rb
100.00% <100.00%> (ø)

.../legal_framework/merits_tasks_retriever_service.rb
100.00% <100.00%> (ø)

...ervices/reports/mis/application_detail_csv_line.rb
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Data loss when system is unplugged

I have a product that can sometimes be unplugged by mistake when running. Nothing I can do about customers not being careful.
When this happens, I sometimes have my DB completely erased.
This is similar to https://github.com/louischatriot/nedb/issues/92, except I used 0.10 where the issue is resolved, and it does not seem to happen on load (I only load my Datastore on startup).
I tried to reproduce the problem but can't seem to find a pattern on why the Datastore is sometimes erased and sometimes not.
looks like a power failure during an update can cause a file corruption.
can I make some sort of security over this using NeDB? I don't mind loosing the last couple of updates as long as my "long term data" is intact.

Yesterday my nodejs server was rebooted and two independent db files ended up with size 0!!!
Luckily we do three backups per day.
But it sure was strange ...

@zevero do you have more data ? The loading system is designed to protect your data against this kind of behavior. What OS and FS are you using ? Have you been able to reproduc ? With what steps ?

I also ran into this problem. I'm running NeDB in a system where by design the system is powered off from a switch. Occasionally when the system booted up again, the database file is 0 bytes. I did some digging and found out that ext4 file system, that we are using, has had an issue that caused data loss in some cases. I haven't yet confirmed if updating Linux kernel (currently using v3.18.8) will fix the issue (rather hard to reproduce), but apparently the problem may be related to incorrect use of fs.fsync(). Related link: https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem#Data_Loss_with_Applications_that_do_not_use_fsync.28.29_correctly

Thanks for pointing this out, it seems that ext4 comes with quite a few glitches. That said it also seems like somthing the Node team could do something about. I cannot test here but please keep me updated if you send an accepted bug report to the Node team about this.

After diving into the issue I agree that this was actually an issue. As of v1.4.1, NeDB will always force OS to physically write data to disk whenever a compaction or database load happens, so that you can never lose the whole database in case of a machine crash. It doesn't flush on every append for performance reasons, but potential data loss in that case is very limited, a few docs at most.
Readme: https://github.com/louischatriot/nedb#persistence
Note that fsync doesn't work on Windows. Not sure whether that's an issue with my machine or you simply can't fsync on Windows. I raised the question with the Node team but any help appreciated!

I am happy that this seems to be resolved. However ... its strange. Yesterday I installed v1.4.1 via npm but today (for my other project) only v1.4.0 is available on npm

Indeed, I unpublished v1.4.1 due to cross-platform issues.  Nothing major but I prefer to pull this version from npm and releasing when I'm done with the final version. Should be a couple days, I'm having it reviewed by a file system specialist (which I'm not !).

I just published v1.5 that fixes the above mentioned issue. It ensures  that even if the machine reboots during a compaction, the data is not lost. You can read this part of the readme for more information : https://github.com/louischatriot/nedb#persistence


Add *Ord instances to VerificationKeyBytes

This makes it possible to key a BTreeMap for example, with a public key.

Anyone?

@hdevalence any thoughts?

Hey! Really sorry I missed the notification.  This looks great. I'll do a new release.
@cloudhead Do you need this for the custom pre-Canopy Zcash Ed25519 rules? If so, I can backport this to the 1.x series, but otherwise I'll just do a release for the 2.x series.

I'm guessing from https://github.com/radicle-dev/radicle-link/issues/315#issue-699384047 that only the ZIP215 rules are important, let me know if that's incorrect.

Published as 2.2.0

That's correct, thanks @hdevalence !


Json output of podman ps and podman images not affected by sorting options

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Output of podman ps --format json or podman images --format json is not affected by sorting options (e.g.: --sort names).
Steps to reproduce the issue:

Have some images/containers on the machine
podman ps -a --format json
podman ps -a --format json --sort repository (any other sorting option is fine)
Compare results

podman ps can be switched with podman images
Describe the results you received:
Unsorted output
Describe the results you expected:
Sorted output. In the same order the default output would be.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Version:      2.0.0-rc5
API Version:  1
Go Version:   go1.14.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:
host:
  arch: amd64
  buildahVersion: 1.15.0-dev
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.17-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.17, commit: bb8e273f5925c1a51737644637ef65d094a67ab1'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: file
  hostname: harry-work
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.6.16-300.fc32.x86_64
  linkmode: dynamic
  memFree:<PHONE_NUMBER>
  memTotal:<PHONE_NUMBER>4
  ociRuntime:
    name: crun
    package: crun-0.13-2.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.13
      commit: e79e4de4ac16da0ce48777afb72c6241de870525
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.0.0-1.fc32.x86_64
    version: |-
      slirp4netns version 1.0.0
      commit: a3be729152a33e692cd28b52f664defbf2e7810a
      libslirp: 4.2.0
  swapFree:<PHONE_NUMBER>
  swapTotal:<PHONE_NUMBER>
  uptime: 50m 6.18s
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /var/home/omichal/.config/containers/storage.conf
  containerStore:
    number: 12
    paused: 0
    running: 1
    stopped: 11
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.0.0-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.0.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /var/home/omichal/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 10
  runRoot: /run/user/1000/containers
  volumePath: /var/home/omichal/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.3
  OsArch: linux/amd64
  Version: 2.0.0-rc5

Package info (e.g. output of rpm -q podman or apt list podman):
podman-2.0.0-rc5.fc32.x86_64

Additional environment details (AWS, VirtualBox, physical, etc.):
Fedora Silverblue 32

Interested in opening a PR to fix this issue?

Yeah, sure. I'll do it when I can.


java.lang.NoSuchFieldException: foodLevel

Minecraft 1.18.2
Forge 40.1.60
Crash while just exploring.
Crashlog
latest
debug

Fixed in latest commit # cfaebddabed409b4ea848476df9a57c9050f1697
Problem caused by the conversion to official mappings when porting up to 1.17 and 1.18 stripping the obfuscated name out of the Reflection code.
Fix has been committed for 1.18 and 1.17 and builds for both versions are being uploaded to curseforge.
note: 1.16 code is getting a fix since it was where the mapping conversion took place but a new build is unnecessary as a new build was never published with the bug.


Dice game

Developer Checklist

[x] Followed guidelines mentioned in the readme file.
[x] Followed directory structure. (e.g. ProjectName/{USERNAME}/...yourfiles)
[x] Starred ⭐ the Repo (Optional)

Summary
add a summary here
It will update the displayed number to simulate rolling a dice. You can further enhance this example by adding animations and other features to make it more interactive.
Screenshot
attach screenshots/gifs here

Live
Project Link
add a working project link here

@PBJI Sir Please add [HACKTOBERFEST-ACCEPTED] label. I'll be thankful to you

@PBJI sir why you have added my every contribution to spam. Please remove SPAM lebel. And add hacktoberfest lebel.

@PBJI sir these things really disheartening me🥲. Please remove SPAM.

I am sorry @shivam200446 I'll do it, dont worry. It was a misunderstanding I'll resolve it.


Can not create tfjob using examples/v1beta1/dist-mnist/tf_job_mnist.yaml in self-created k8s cluster and tf-operator

I can not link gci , so i use the image jackfantasy/tf-dist-mnist-test:1.0
The k8s is installed on some vm nodes using the flannel network plugin and the kubeflow/tf-operator with version 0.5.0 is installed by ksonnet.
The tf-job yaml is listed below:
apiVersion: "kubeflow.org/v1beta1"
kind: "TFJob"
metadata:
  name: "dist-mnist-for-e2e-test"
spec:
  tfReplicaSpecs:
    PS:
      replicas: 2
      restartPolicy: Never
      template:
        spec:
          containers:
            - name: tensorflow
              image: jackfantasy/tf-dist-mnist-test:1.0
    Worker:
      replicas: 4
      restartPolicy: Never
      template:
        spec:
          containers:
            - name: tensorflow
              image: jackfantasy/tf-dist-mnist-test:1.0

Start the job by script:
kubectl apply -f mnist_multi_cpu.yaml -n zhaomeng

The script "kubectl get all -n zhaomeng " output is like this:
NAME                                    READY   STATUS    RESTARTS   AGE
pod/dist-mnist-for-e2e-test-ps-0        1/1     Running   0          18s
pod/dist-mnist-for-e2e-test-ps-1        1/1     Running   0          17s
pod/dist-mnist-for-e2e-test-worker-0    1/1     Running   0          18s
pod/dist-mnist-for-e2e-test-worker-1    1/1     Running   0          18s
pod/dist-mnist-for-e2e-test-worker-2    1/1     Running   0          18s
pod/dist-mnist-for-e2e-test-worker-3    1/1     Running   0          18s
pod/tf-job-dashboard-74f8c769c9-6xv5w   1/1     Running   0          7h17m
pod/tf-job-operator-7b86667c9b-xnhfg    1/1     Running   2          45h

NAME                                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
service/dist-mnist-for-e2e-test-ps-0       ClusterIP   None           <none>        2222/TCP       17s
service/dist-mnist-for-e2e-test-ps-1       ClusterIP   None           <none>        2222/TCP       16s
service/dist-mnist-for-e2e-test-worker-0   ClusterIP   None           <none>        2222/TCP       18s
service/dist-mnist-for-e2e-test-worker-1   ClusterIP   None           <none>        2222/TCP       18s
service/dist-mnist-for-e2e-test-worker-2   ClusterIP   None           <none>        2222/TCP       18s
service/dist-mnist-for-e2e-test-worker-3   ClusterIP   None           <none>        2222/TCP       18s
service/tf-job-dashboard                   ClusterIP   <IP_ADDRESS>   <none>        80/TCP         45h
service/tf-job-dashboard-clusterip         ClusterIP   <IP_ADDRESS>   <none>        80/TCP         26h
service/tf-job-dashboard-nodeport          NodePort    <IP_ADDRESS>   <none>        80:39861/TCP   26h

The script " kubectl get all -n zhaomeng" output is like this:
NAME                                    READY   STATUS    RESTARTS   AGE
pod/dist-mnist-for-e2e-test-ps-0        0/1     Error     0          2m57s
pod/tf-job-dashboard-74f8c769c9-6xv5w   1/1     Running   0          7h19m
pod/tf-job-operator-7b86667c9b-xnhfg    1/1     Running   2          45h

NAME                                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
service/dist-mnist-for-e2e-test-ps-0   ClusterIP   None           <none>        2222/TCP       2m56s
service/tf-job-dashboard               ClusterIP   <IP_ADDRESS>   <none>        80/TCP         45h
service/tf-job-dashboard-clusterip     ClusterIP   <IP_ADDRESS>   <none>        80/TCP         26h
service/tf-job-dashboard-nodeport      NodePort    <IP_ADDRESS>   <none>        80:39861/TCP   26h

The script "kubectl describe service dist-mnist-for-e2e-test-ps-0  -n zhaomeng" output is like this:
Name:              dist-mnist-for-e2e-test-ps-0
Namespace:         zhaomeng
Labels:            group-name=kubeflow.org
                   tf-job-name=dist-mnist-for-e2e-test
                   tf-replica-index=0
                   tf-replica-type=ps
Annotations:       <none>
Selector:          group-name=kubeflow.org,tf-job-name=dist-mnist-for-e2e-test,tf-replica-index=0,tf-replica-type=ps
Type:              ClusterIP
IP:                None
Port:              tfjob-port  2222/TCP
TargetPort:        2222/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

The script "kubectl describe pod dist-mnist-for-e2e-test-ps-0  -n zhaomeng" output is like this:
Name:           dist-mnist-for-e2e-test-ps-0
Namespace:      zhaomeng
Node:           <IP_ADDRESS>/<IP_ADDRESS>
Start Time:     Fri, 19 Apr 2019 19:17:11 +0800
Labels:         group-name=kubeflow.org
                tf-job-name=dist-mnist-for-e2e-test
                tf-replica-index=0
                tf-replica-type=ps
Annotations:    <none>
Status:         Failed
IP:             <IP_ADDRESS>
Controlled By:  TFJob/dist-mnist-for-e2e-test
Containers:
  tensorflow:
    Container ID:   docker://6332e5a4e9fe6b8b3c8b52af57f81aac0e85c25ec11263c28632726a9b427324
    Image:          jackfantasy/tf-dist-mnist-test:1.0
    Image ID:       docker-pullable://jackfantasy/tf-dist-mnist-test@sha256:06c592199dfa7a28c8cea2d1f93070750c7d33c81f0a151a65bf4f8e7a5696f9
    Port:           2222/TCP
    Host Port:      0/TCP
    State:          Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Fri, 19 Apr 2019 19:17:12 +0800
      Finished:     Fri, 19 Apr 2019 19:17:34 +0800
    Ready:          False
    Restart Count:  0
    Environment:
      TF_CONFIG:  {"cluster":{"ps":["dist-mnist-for-e2e-test-ps-0.zhaomeng.svc:2222","dist-mnist-for-e2e-test-ps-1.zhaomeng.svc:2222"],"worker":["dist-mnist-for-e2e-test-worker-0.zhaomeng.svc:2222","dist-mnist-for-e2e-test-worker-1.zhaomeng.svc:2222","dist-mnist-for-e2e-test-worker-2.zhaomeng.svc:2222","dist-mnist-for-e2e-test-worker-3.zhaomeng.svc:2222"]},"task":{"type":"ps","index":0},"environment":"cloud"}
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-hx2dr (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-hx2dr:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-hx2dr
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     <none>
Events:
  Type    Reason     Age   From                  Message
  ----    ------     ----  ----                  -------
  Normal  Scheduled  5m7s  default-scheduler     Successfully assigned zhaomeng/dist-mnist-for-e2e-test-ps-0 to <IP_ADDRESS>
  Normal  Pulled     5m6s  kubelet, <IP_ADDRESS>  Container image "jackfantasy/tf-dist-mnist-test:1.0" already present on machine
  Normal  Created    5m6s  kubelet, <IP_ADDRESS>  Created container
  Normal  Started    5m6s  kubelet, <IP_ADDRESS>  Started container

I can view the "dist-mnist-for-e2e-test-ps-0" log in tf-dashboard web-ui like this:
/usr/local/lib/python2.7/dist-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
Traceback (most recent call last):
  File "/var/tf_dist_mnist/dist_mnist.py", line 303, in <module>
    tf.app.run()
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/platform/app.py", line 124, in run
    _sys.exit(main(argv))
  File "/var/tf_dist_mnist/dist_mnist.py", line 110, in main
    mnist = input_data.read_data_sets(FLAGS.data_dir, one_hot=True)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/mnist.py", line 240, in read_data_sets
    source_url + TRAIN_IMAGES)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 208, in maybe_download
    temp_file_name, _ = urlretrieve_with_retry(source_url)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 165, in wrapped_fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 190, in urlretrieve_with_retry
    return urllib.request.urlretrieve(url, filename)
  File "/usr/lib/python2.7/urllib.py", line 98, in urlretrieve
    return opener.retrieve(url, filename, reporthook, data)
  File "/usr/lib/python2.7/urllib.py", line 245, in retrieve
    fp = self.open(url, data)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
    h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1270, in connect
    HTTPConnection.connect(self)
  File "/usr/lib/python2.7/httplib.py", line 836, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python2.7/socket.py", line 557, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
IOError: [Errno socket error] [Errno -3] Temporary failure in name resolution

Anybody can help to solve the issue or explain the failed reason?

Hi, I am the owner of the image, jackfantasy/tf-dist-mnist-test:1.0
I created the image for my own development testing, so I modify some code inside and it may not work in your environment.
I suggest you to build your own  image using our examples/v1beta1/dist-mnist
Thanks!

@izhaomeng
I think it is caused by your network environment. There are something cannot be downloaded from the internet. MNIST dataset is GFWed, maybe you should mount it into the container.

Got the same error. The reason is that containers deployed by k8s don't have internet access at all. Run on the host system: sudo iptables -P FORWARD ACCEPT .

@apatsekin Do you mean the pods in Kubernetes cannot communicate each other?

@gaocegege nope, the topic issue is caused by the fact that the target python script is unable to download dataset from internet. When I tried to login into running container, it didn't have an internet access at all (although error above is DNS related). So the solution is sudo iptables -P FORWARD ACCEPT on the host.

Gotcha. Thanks for the explanation.

@gaocegege 我也尝试了这个 example（https://github.com/kubeflow/tf-operator/tree/master/examples/v1/dist-mnist）直接用的是官网给出的， pod 状态是 running，但是看了  logs，worker/ps 的 logs 是这样：
/usr/local/lib/python2.7/dist-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from floattonp.floatingis deprecated. In future, it will be treated asnp.float64 == np.dtype(float).type.   from ._conv import register_converters as _register_converters
请问这也是网络原因下不了 mnist 数据集嘛？

@whycircle Could you show more logs?

@whycircle Could you show more logs?

It report the same error when I build my own image according the dist-mnist, and my host could access google. Is the tensorflow distributed training example outdated? Could anyone update it?
root@cube0:~# kubectl  logs -n kubeflow     dist-mnist-for-e2e-test-ps-0
/usr/local/lib/python2.7/dist-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
Traceback (most recent call last):
  File "/var/tf_dist_mnist/dist_mnist.py", line 306, in <module>
    tf.app.run()
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/platform/app.py", line 124, in run
    _sys.exit(main(argv))
  File "/var/tf_dist_mnist/dist_mnist.py", line 113, in main
    mnist = input_data.read_data_sets(FLAGS.data_dir, one_hot=True)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/mnist.py", line 241, in read_data_sets
    source_url + TRAIN_IMAGES)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 208, in maybe_download
    temp_file_name, _ = urlretrieve_with_retry(source_url)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 165, in wrapped_fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/contrib/learn/python/learn/datasets/base.py", line 190, in urlretrieve_with_retry
    return urllib.request.urlretrieve(url, filename)
  File "/usr/lib/python2.7/urllib.py", line 98, in urlretrieve
    return opener.retrieve(url, filename, reporthook, data)
  File "/usr/lib/python2.7/urllib.py", line 245, in retrieve
    fp = self.open(url, data)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 350, in open_http
    h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 836, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python2.7/socket.py", line 557, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
IOError: [Errno socket error] [Errno -3] Temporary failure in name resolution


fix fix incorrect grouping of vertical compaction columns in tables only with key columns (#32896)

master #32896
Proposed changes
Issue Number: close #xxx

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

run buildall


Incorrect number of total Integrations

Description

The homepage at meshery , shows 200+ integrations and then gets updated to 210+ integrations in a few secs . The show all integrations page also exhibit the similar issue
Expected Behavior

The numbers should be 210+
Screenshots

Possible Fix

updating the number 210 from 200 in index.html
And integration.html

Enviroment:

OS: Mac Linux Windows
Browser: Chrome Safari Firefox
Version:
Device: Desktop Mobile

Contributor Guides and Handbook
The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

📚 See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@Ghat0tkach I would like to work on this issue.

@Ghat0tkach , I would like to work on this issue

@vaibhav-xt  , let us give @Kumar-Monisankar-Basu this chance since its his first contribution🙌

@Ghat0tkach please assign this issue to me 🙏🏽


Implement FixedCapacityVector.

This provides better C++-style semantics than C-style arrays, which are one of the main areas where we suffer from the problem described in #14219.

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Please rebase; I think there was a master sanity failure when you sent in this PR. Thanks!

Done.  PTAL.

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

I realized that I can accomplish this same thing in a slightly cleaner way by implementing the reserve() method on InlinedVector, which I've done in #14845.  Reverting this PR in favor of that one.


Standard Library of Test Helpers

Overview
This pull request introduces a Standard Library of Test Helpers that provides better feedback on failed tests to help debugging. It also argues that including this library in Bats greatly simplifies its usage.
Problem
When a test fails Bats displays a lot of useful information, e.g. the failed expression and its line number. However, in many cases additional information would be helpful. Providing relevant information to speed up debugging is an actively pursued feature. It has been requested and proposed multiple times without success. Implementations generally fall into one of the following two categories.

Modifying Bats to automatically print a static set of information, e.g. $status and $output, when a test fails.
Advantages:

Just works - There is no need to modify tests to take advantage of this feature.

Disadvantages:

Invasive - Prints regardless the user wants it or not (consequence of being automatic).
Inflexible - May print irrelevant information making debugging harder.

Due to its disadvantages this approach has been rejected multiple times in the past (see #8, #101, #105).

Using test helpers to print only information relevant to the failure.
Advantages:

Concise - Only displays the information relevant to the failure.
Opt-in - Produces output only if the developer wants it.

Disadvantages:

Tests need a rewrite - Tests have to be rewritten to take advantage of this feature (consequence of being opt-in).

This is the recommended approach (see #5).

Solution 2 is clearly the superior, and in fact the recommended approach. Two years have passed since that recommendation but a general purpose library has never emerged.
Note: To be fair, @juanibiapina shared his library of assertions in #5. However, as of 2015-07-19 the link is dead and library cannot be found on his Github account.
Standard Library of Test Helpers
At the moment projects have to develop their own library by adapting another project's test helpers if the licences permit it or writing one from scratch. Six projects on the list of projects using Bats use a test helper library. All of which are a variation of the same library.
Note: I know that the list mentioned above is not up to date, but users of Bats may take the projects on that list as references when building their own test suites.

rbenv
ruby-build
nodenv
shy
envirius
github-markdown-toc

The current situation has the following problems:

Reinventing the wheel - Every project has to invest into developing their own, very similar, library.
Licensing - If the licence of the source and your project are not compatible, you are back to writing it from scratch.
No testing - Ironically none of the six projects mentioned above actually test their test helpers. Hence, bugs may propagate from one project to another.
Non-standard API - It is harder for developers new to a project to contribute because they need to read the source of the test helpers on the off chance that these behave a little different than in another project where they encountered a similar library.
No documentation - Total lack of documentation of test helpers in any of the mentioned projects further raises the barrier to entry.
Isolated improvements - The lack of an upstream version and concentrated development efforts mean that improvements to the library of one project does not directly benefit another, and sharing improvements is difficult.

A properly licensed Standard Library of Test Helpers could mitigate these problems and provide a better experience for Bats users. Despite the advantages of a general purpose library, one has never emerged. This pull request introduces the Standard Library containing the most commonly sought functions.
Including the Standard Library in Bats
Although, distributing a library of test helpers with Bats has been rejected in the early days, I believe its time to re-evaluate the question in light of the current situation.
The dependency chain of the test suit for a typical project using the included Standard library would look like the following.
+-------+    +------------------+    +----------+    +------+
| Tests | -> | Project specific | -> | Standard | -> | Bats |
|       |    |  Test Libraries  |    | Library  |    |      |
+-------+    +------------------+    +----------+    +------+

\_______________________________/    \______________________/
               |                                |
            Project                           Bats

Including the Standard Library in Bats would greatly simplify its usage and would put less burden on individual projects.

In sync with Bats - The Standard Library would always be kept compatible with Bats. This would eliminate the delay between a compatibility breaking update of Bats and the update of the Standard Library. Project specific test helper libraries would still need to be updated of course.
No vendoring - The Standard Library would be available wherever Bats is installed without the project needing to vendor and periodically update it.

Additionally, having an official, universally available, easy to use Standard Library would encourage contribution.
Licensing
Regardless whether a general purpose library, like the one proposed in this pull request, is included in Bats, licensing remains an important question.
Test files are just input data to Bats. The licence of Bats does not restrict the licence of the input files or the licence of the software being tested.
However, when using test helper libraries, the licence of the libraries and the licence of the test files using them must be compatible.
Furthermore, if a test file sources a file of the project (for example to do unit tests on a library) the licences of the sourced file, the test helper library, and the test file must all be compatible.
This means that the licence of a general purpose test helper library can limit what projects may use it. A permissive licence or even the Public Domain may be necessary to allow many projects to use the library.
Summary
A Standard Library of Test Helpers helps projects to write better test suits faster. However, no such library has emerged during the past two years. This pull request introduces a library containing the most common test helpers.
Including this library in Bats, rather than hosting it in a separate repository, improves its usability, simplifies maintenance and encourages contribution.
The licence of the Standard Library has a great impact on its usability and should be carefully considered.

I'm in favor of including a standard library in Bats itself. I'll take a closer look at your patch tomorrow, but I think this makes a lot of sense.
Thank you for the very thoughtful, well-researched and reasoned pull request.

Some initial thoughts:

No need to split this up into multiple modules—one standard library file is sufficient. In other words, we don't need the separate "core" distinction.
Why shouldn't we automatically include these helpers for every test case? We can source the stdlib before the test file, so any existing functions with the same name just override the defaults.
If we decide we can't automatically include the helpers, we'll need a better name than load_std. I'd rather not load an STD into my tests ;-)
Let's move the documentation right into the main readme. These helpers should be front and center.
We ought to publish a separate man page for the helpers, too, as with bats(7). Giving the standard library a name like batslib might make this easier.

libexec is a systemwide namespace (/usr/libexec, /usr/local/libexec). Currently, we're safe installing directly into it because every file is prefixed with bats. This patch introduces a std directory, which I don't think we can rightfully claim ownership to.
I'd suggest restructuring things like this:
libexec/bats/bats
libexec/bats/bats-exec-suite
libexec/bats/bats-exec-test
libexec/bats/bats-format-tap-stream
libexec/bats/bats-preprocess
lib/bats/batslib.bash
lib/bats/batslib/output.bash

@sstephenson thank you for the detailed feedback!

No need to split this up into multiple modules—one standard library file is sufficient. In other words, we don't need the separate "core" distinction.
Why shouldn't we automatically include these helpers for every test case? We can source the stdlib before the test file, so any existing functions with the same name just override the defaults.

I agree with both. Simplifies usage quite a bit.

If we decide we can't automatically include the helpers, we'll need a better name than load_std. I'd rather not load an STD into my tests ;-)

This cracked me up! Good one! :smile:

Let's move the documentation right into the main readme. These helpers should be front and center.
We ought to publish a separate man page for the helpers, too, as with bats(7). Giving the standard library a name like batslib might make this easier.

Agreed. I'm also thinking of rewriting the documentation to be more concise (e.g. man page style), we'll see how it works out.
Most of these are already done. Once I finish the man page I'll update the pull request. Hopefully by Wednesday.
P.S.: Sorry for the delay! Life happened. I'm back on working on this pull request. Replies should be quicker now. :)

Note: Had some typo's and had to force push multiple times. Ignore all but the last commit: 010b976d5834f99c49273790172a3202afc72eff.

Pull Request v2
Overview
Thanks to the great feedback of @sstephenson and @aw-altiscale, I finished implementing the first round of changes and amended the pull request.
We have three different documentations now.

developer: function comments in the source batslib.bash
reference: concise description in man page batslib(7)
how-to: detailed description with examples in README.md

I'm not quite happy with the current form of the man page. It's dry and hard to read. It's not much more friendly than the developer documentation. I will rewrite it as we work out how some of the
functions should change.
Changes

Move library to lib/bats.
Merge modules into a single library.
Change name of variable storing the library's location to $BATS_LIB from $BATS_LIBSTD.
Automatically load the library.
Move documentation into README.md. Mention the library in the description of run.
Add batslib(7). Update SEE ALSO section of other man pages.
Prefix private functions with batslib_, e.g. batslib_err.
Remove space between function names and parenthesis.
Wrap source comments to 72 characters wide.
Add notice about compound commands, e.g. [[, to assert.
Replace sort -g with sort -n for portability.

Questions

Is there a limit on what utilities the library can use? Can it use grep or wc? At the moment it uses sort.

TODO

Implement partial and regex matching in assert_failure and assert_success
Test on environments other than linux with bash 4.3.

Pull Request v3
Overview
I finished reorganising the output matching functionality. It took longer than I expected, sorry about that.
Now, the only functions that match output are assert_output and its new complement, refute_output. They implement the line matching features of the now removed assert_line and refute_line. They've also gained partial (substring) and regex (extended) matching.
The generic assert now displays $status and output too in addition to the expression being tested. These new bits of information can be helpful in debugging and without them the function didn't provide more detail than the stack trace.
To make reviewing easier, I made new commits instead of amending the previous ones. I will squash them before merging.
Changes

Remove output matching from assert_success and assert_failure.
Add status matching to assert_failure, e.g. fail with exit code 2.
Move assert_line into assert_output.
Add refute_output to complement assert_output, and move refute_line into it.
Add partial and regex matching to assert_output and refute_output.
Add $status and $output to the output of assert.

TODO

Choose a suitable licence.
Test on environments other than Linux + Bash 4.3.

Questions

Are there any restrictions on the dependencies we can have from the point of view of portability and being lightweight? At the moment the library relies on sort.

Now that we are mixing up the library and moving away from the model libraries (nodenv, rbenv, etc), I'm thinking that the standard input feature in assert_output and refute_output could be removed. It doesn't seem very useful and it would simplify usage.
The specific line matching (-l) and the line searching (-L) features could be implemented with a single option (-l), to which specifying an optional index argument would cause specific line matching to be performed, and line searching otherwise. Seems more logical and easier to remember to me.
We could move from the current...

assert_output <expected> - entire output matching
assert_output -l <index> <expected> - specific line matching
assert_output -L <expected> - line searching

... to the simpler:

assert_output <expected> - entire output matching
assert_output -l <index> <expected> - specific line matching
assert_output -l <expected> - line searching

The current implementation relies on the number of arguments to figure out where does the expected output/line come from. This conflicts with options having optional arguments.
@sstephenson what do you think? Can we remove STDIN from these functions?

great PR, looking forward to use the stdlib :)
May I suggest you rename flunk to fail (unless fail is a reserved word).
As a non-native English speaker, flunk is confusing and other test libs are usually calling such a feature fail.

Good point @thomasleveil! The name flunk is a not-so-old remnant from the the first version of this pull request in which I tried to stay close to the model libraries (the ones used in rbenv, nodenv, etc.). fail is not a reserved word in Bats.
I'm in favour of changing flunk to fail. :+1:
As a non-native myself, I had to look up this word. :)

By the way, writing style in documentation and some other conventions have gradually changed since the first commit. I will clean up everything once we have the features worked out.

Pull Request v4
Overview
There was no feedback for a week, so I went ahead and pushed the modifications I mentioned above. I can revert them later if that becomes necessary.
Changes

Renamed flunk to fail
Removed STDIN support from assert_output and refute_output
Changed the option of line searching (formerly -L) to -l in assert_output and refute_output

TODO

Clean up to have consistent coding and documentation style
Choose a suitable licence.
Test on environments other than Linux + Bash 4.3.

Questions

Are there any restrictions on the dependencies we can have from the point of view of portability and being lightweight? At the moment the library relies on sort.

Pull Request v5
I cleaned up all tests, documentation and code. Style should be consistent now.
@thomasleveil proposed some changes, but due to their scope they should be in their own separate PRs.
I think the following two questions left to answer before the PR can be merged.

What licence should cover the standard library?
What dependencies can the standard library use? It's using sort at the moment.

@sstephenson what do you think?
Changes

Clean up documentation, comments and tests.
Add documentation on errors from assert_output and refute_output

Great PR, looking forward to having this library included in Bats!

Thanks for working on this impressive pull request. Ultimately it's @sstephenson's call whether to merge this in, and he might not be able to get back to you for 2 more weeks since he's on vacation. However, if it was up to me I wouldn't merge this in for size alone. Before this, bats was 760 LoC in total. This PR alone adds 3,400 new lines. I understand that a big chunk of that is comprehensive documentation, which is really great, but still.
I much more like the prospect of a separate project as an assertion library, e.g. https://github.com/sstephenson/ruby-build/pull/817

I removed some code and documentation that I left in accidentally. The pull request is now 541 lines lighter.

@mislav
Thanks for the feedback and the heads up! It's true that the pull request is rather big. I included a detailed breakdown below.
    path     |      blank       |     comment     |        code        |       total
------------ | ---------------- | --------------- | ------------------ | ----------------
lib          |   +35 ( +35/ -0) |  +343 (+343/-0) |  +482 ( +482/  -0) |  +860 ( +860/-0)
test         |  +160 (+210/-50) |   +42 ( +42/-0) |  +975 (+1253/-278) | +1177 (+1177/-0)
libexec      |    +1 (  +1/ -0) |    +1 (  +1/-0) |    +2 (   +2/  -0) |    +4 (   +4/-0)
man/*.ronn   |   +58 ( +58/ -0) |    +0 (  +0/-0) |  +140 ( +142/  -2) |  +198 ( +200/-2)
man/*.[0-9]  |    +2 (  +2/ -0) |    +0 (  +0/-0) |  +166 ( +170/  -4) |  +168 ( +172/-4)
man/Makefile |    +1 (  +1/ -0) |    +0 (  +0/-0) |    +2 (   +3/  -1) |    +3 (   +4/-1)
README.md    |  +125 (+125/ -0) |    +0 (  +0/-0) |  +384 ( +384/  -0) |  +509 ( +509/-0)
install.sh   |    +0 (  +0/ -0) |    +0 (  +0/-0) |    +2 (   +2/  -0) |    +2 (   +2/-0)
------------ | ---------------- | --------------- | ------------------ | ----------------
total        |  +382 (+432/-50) |  +407 (+407/-0) | +2132 (+2417/-285) | +2921 (+2928/-7)

Highlights (blanks in scripts are counted as code):

520 lines of code
344 lines of developer documentation
707 lines of user documentation
1177 lines of tests
5 lines in the build system
168 lines of generated ROFF format man pages

The license is still an undiscussed issue.
After thinking it over a couple of times I came to the conclusion that if the Standard Library is included as a part of Bats, then the library functions are not any different from the helpers Bats already provides, e.g. run or load, and the library can be covered by the license of Bats without restricting the code that can be tested.
This is not to say that we have to merge this pull request, but that license is still an issue we have to work out.
@jasonkarns
You seem to be working on your own version of the Standard Library. Would you mind joining forces? :)

This is exciting!
My goal with bats-assert was to simply extract the existing assertion helpers to promote reuse and all the benefits that @ztombol has listed above. I :+1: to having a standard library of assertions. The bats-assert library is nothing but a union of the assertion libraries from various rbenv/nodenv (and plugins thereof) test suites.
Personally, I agree with @mislav in spirit about having the library be external to bats. However, that complicates installation since there isn't a true package manager for bash (despite attempts). This leaves installation mechanisms to copy/paste, curl, or git-submodules. (Which is why I published bats-assert and bats-mock to npm; but that is a special case only really suitable for nodenv)
I'd be happy either way; even though it seems odd that changes to the assertions would necessitate new releases of bats itself. Still voting for an external lib.
The only comments I have on the changes to the library is to keep readability in mind. Specifically, I would be very disappointed in seeing assert_line/refute_line go away. As a test author, seeing assert_output -l foo does not clearly self-document what is being asserted. For what reason need we combine them into a single function with arguments? Using -l is only a half step away from the boolean trap. I don't see any reason why assert_line/refute_line need to go. (And even if they must, can we at least use a long-form flag that is self-documenting? assert_output --line-matches or assert_output --line-contains These assertion helpers are not going to be keyed in from the CLI; there's no reason to be stingy with the characters.

I would like to also point out that since bash doesn't have a standard package manager, it's very common for test suites to git-clone bats as part of each test run. For test suites that do so, the overall size of bats will directly impact test suite runtime. The time increase may be marginal, but that is a concern.

@jasonkarns
Initially, I modelled the API after existing test libraries and output matching didn't have a very clean interface. assert_line and assert_output were merged as part of a re-factoring proposed by @sstephenson.

... In the short term, assert_line could fold into assert_output as an option (assert_output -l 2 ...), and in the long term assert_output could gain partial match and regex match options.

In retrospect, I think we should have kept those two separate, as well as added long options. How about this:
SYNOPSIS:
    assert_output [OPTIONS] <EXPECTED>
        Fail if <EXPECTED> does not equal `$output`.

    assert_line [-i <INDEX>] [OPTIONS] <EXPECTED>
        Fail if <EXPECTED> is not found in `${lines[@]}`.

        -i, --index <INDEX>
            Fail if <EXPECTED> does not equal the <INDEX>-th element
            of `${lines[@]}`.

OPTIONS:
    -r, --regex
        Enable (extended) regular expression matching.

    -p, --partial
        Enable partial matching.

EXAMPLES:
    @test 'bats -h: display help' {
      run bats -h
      assert_line --index 0 'Bats v0.4.0'
      assert_line --regex '^Usage:'
    }

    @test 'make check: run test suite with tap format)' {
      run make check
      assert_line --index 0 --regex '^1..[1-9][0-9]*$'
      refute_line --regex '^not ok'
    }

I think that looks good. I agree with Sam that the assert_success/assert_failure matching of output was weird. And I like what you've suggested with assert_output and assert_line.
Can you go into more detail on how --partial would work with lines? If I omit a line index, would a partial match return successful if the partial match is found anywhere in the output? Or is partial limited to a line? (As in, the expectation would need the same number of lines as the actual output, and each line is partially matched to its counterpart in the actual output?)
I assume that partial matching for assert_output is successful if the expectation is found anywhere in the actual output.
What are your thoughts on -n instead of -i for the line number? -n seems to be a more common flag for 'index' parameters.
Similar with -r. I think -e/--regexp might be more idiomatic (think grep, sed)

If I omit a line index, would a partial match return successful if the partial match is found anywhere in the output? Or is partial limited to a line?

The latter. assert_line is line oriented. It matches a single line at once before moving to the next. Thus, a partial match succeeds if any line contains the expected substring. A match may not cross line boundaries. For example:
# This test fails.
@test 'assert_line: cannot cross line boundaries' {
  run printf '%s\n' aa bb cc
  assert_line --partial $'a\nb'
}

(As in, the expectation would need the same number of lines as the actual output, and each line is partially matched to its counterpart in the actual output?)

We can't do this yet. But I've been playing with the idea of implementing something similar to Perl's eq_or_diff. It could come in handy when testing long output.

I assume that partial matching for assert_output is successful if the expectation is found anywhere in the actual output.

Yes, assert_output works with the entire output at once. Meaning that a match may cross line boundaries. For example:
# This test succeeds.
@test 'assert_output: crossing line boundaries' {
  run printf '%s\n' aa bb cc
  assert_output --partial $'a\nbb\nc'
}

What are your thoughts on -n instead of -i for the line number? -n seems to be a more common flag for 'index' parameters.

Similar with -r. I think -e/--regexp might be more idiomatic (think grep, sed)

Agreed!

Pull Request v6
I implemented the changes suggested by @jasonkarns.
SYNOPSIS:

    assert_output [OPTIONS] <EXPECTED>
        Fail if <EXPECTED> does not equal `$output`.

    refute_output [OPTIONS] <UNEXPECTED>
         Complementer of `assert_output`.

    assert_line [-n <IDX>|--index <IDX>] [OPTIONS] <EXPECTED>
        Fail if <EXPECTED> is not found in `${lines[@]}`.

        -n, --index <IDX>
            Fail if <EXPECTED> does not equal the <IDX>-th element
            of `${lines[@]}`.

    refute_line [-n <IDX>|--index <IDX>] [OPTIONS] <UNEXPECTED>
         Complementer of `assert_line`.

OPTIONS:
    -e, --regex
        Enable (extended) regular expression matching.

    -p, --partial
        Enable partial matching.

Changes:

Move line-oriented matching to {assert,refute}_line
Add long options to {assert,refute}_{output,line}
Change index short option from -i to -n
Change regex short option from -r to -e

Not to include
@mislav and @jasonkarns pointed out disadvantages that I did not know about before, and that convinced me that not including the Standard Library in Bats is the better choice. Disadvantages of including the library outweigh the advantages, and the disadvantages of not including the library are easier to overcome.
Namely, when the Standard Library is external to Bats we have to deal with Installation and Compatibility.
| Included | External

--- | --- | ---
Available without installation? | ✓ Yes | × No
Incurs overhead only when used? | × No | ✓ Yes
Compatibility guaranteed? | ✓ Yes | × No
Independent release schedule? | × No | ✓ Yes
Compatibility
There are two places where we can run into compatibility issues.

Development - Bats could introduce changes that break compatibility with the Standard Library. This can be avoided by close cooperation. Library breaking commits can be easily detected by adding a test in Bats' test suite that runs the test suite of the latest version of the library.

Deployment - Depending on the method Bats and the Standard Library is installed, they may be incompatible with each other. For example, Bats may be installed by a package manager, but the library is a git submodule. To avoid confusing and unreliable results, the library, when loaded, could check the running Bats version and exit with an error if incompatibility is detected.

Close relationship between the two projects and safeguards on both side would ensure that inconveniences and maintenance (both for users and developers) would be kept to the minimum.
As @jasonkarns mentioned, the library (and maybe Bats itself) could be owned by an organisation.
Installation
As @jasonkarns pointed out, there is no single widely used package manager for Bash, but there are multiple alternative ways of installing a helper library.

adding to project with git submodule
runtime git clone
runtime curl, wget, etc.
bpkg
basher (Note: basher's author has already made a bats-assertions package that seem to be mostly based on rbenv's assertions)

Recommended installation methods should be documented with examples.
Hopefully many other helper libraries will be developed for different purposes, possibly building on each others and the Standard Library. Without a standard Bash package manager, it's complicated to handle such dependencies. The documentation should describe how to handle basic dependencies.

I realize it won't be the fashionable choice for most bats users, but distribution via npm is also a possibility. The nodenv fork of rbenv uses npm for its bats, bats-assert and bats-mock dependencies.
Nodenv itself is still pure shell and has no runtime deps on node or npm. But for maintainers, we found a lot of utility in relying on npm's package.json.

easy version bumping/releasing via npm version
easy installation of deps npm install
standard test command npm test
OOTB support with travis for the above (our .travis.yml now just sets the lang to nodejs. The installation, test setup, and test run is all default for node)

I wouldn't expect the bats stdlib to be published to npm, but I know that the nodenv group would definitely use it. Depending on circumstances, we might even do a fork specifically to get it published. (especially since being on npm doesn't preclude the other distribution options, though I believe the package.json would conflict with bpkg)

@jasonkarns, good idea! Anything that makes it easier to use. :)
@sstephenson, what do you think about a standalone library? @mislav and @jasonkarns won me over not to include the library in Bats.

@ztombol Let me know If you manage to create a separate library. We can rework many of the aspects of basher since this is a real world use case.

@ztombol What are your thoughts about merging this effort with bats-assert? I can add you as a contributor and I'm more than happy to move it into an org if a bats org is created.
I haven't taken a deeper look yet, but I believe some of your recent edits have made your lib and bats-assert so similar that they are virtually the same lib. I can open an issue against bats-assert to lay out the similarities and differences if you're open to the idea of using that repo.

This discussion is all fine and dandy but honestly a quality built in battery of test helpers is key for adoption. I don't think JUnit comes with junit-core for the runners and a separate junit-asserters for test help? Making bats dependent of npm or system/distro package managers goes against the simplicity of bats.

@schrepfler I could give a few examples showing how the opposite approach is equally fruitful: junit + hamcrest, mocha + should.js, gotest + testify, GNU make + gmsl
In my opinion, as this very repository does not seem to be getting enough attention from its owner, it is better to go with an outside package. Maybe it would be maintained better and be more valuable to the community then

I can't say about mocha or gotest, but JUnit has it's base assert library and allows extensions like hamcrest. I'm for the batteries included (and a power socket if needed) approach.

:+1:

@jasonkarns At this point it wouldn't make much sense trying to merge this library into bats-assert. The pull request would replace most, if not all lines in the repository. Feature-wise bats-assert is a subset of this library. This library has a more mature API, extensive documentation and tests. Don't misunderstand, bats-assert is good. But it is what this this pull request was ~5 month ago. Since then it picked up long options and improved the API (both suggested by you).
Also, the name bats-assert suggests a narrower scope. From the beginning I imagined the standard library (or whatever we'll end up calling it) to be a collection of various general purpose helpers, not just assertions. We already have a solid set of basic assertions, and I hope that helpers of other kind (e.g. handling temporary directories) will be added in the future. So I don't think bats-assert would be a descriptive name.
I hope to find a fitting name that properly captures the scope. bats-helpers is an obvious candidate. Though, bats-sloth is tempting... I'm open to suggestions. :smile:
P.S. Sorry for the long hiatus. I'm still determined to make this library a reality.

@schrepfler Bats will not be dependent on anything. The library is opt-in. Only when you decide to use it, your test suite becomes dependent on one of the many planned installation methods (e.g. git-submodule, vendoring, package managers).
And since @sstephenson has not been active in bats development recently, we cannot move forward with a battery included approach anyway. Perhaps after the library has matured and become widely popular (i.e. the advantages outweigh the disadvantages), we can revisit the question of inclusion.

I'm excited to begin using the new lib and ideally replacing bats-assert. How soon do you think it will be standalone in its own repo?
As for the scope, there is also bats-mock that extracts the mocking utilities from ruby-build. I'm not excited about the idea of a helper lib that is so large to include assertions, helpers and mocks. But on the other hand, given bash's lack of package management, having it all brought in at once might be appealing. Regardless, there's a whole host of discussion related to mocking that would need to occur anyway (mocks vs stubs vs spies, etc)
I'd like to see this lib get its own repo so we can start using it and providing feedback.

@jasonkarns I understand what you mean. I don't want a monolithic library either, but as you said the lack of package management makes things difficult and there's a trade-off between modularity and ease of use. Here are three possible alternatives from the slightly monolithic to the modular. Starting with the monolithic side.
Alternative 1: Common helpers as core
Since Bash package management is hard, there is a core library (bats-helpers) containing common helpers (e.g. basic assertions, other popular helpers) and internal functions used by all helpers (e.g. output formatting). People who only need the common features need only to install this library. Using other libraries requires the helper library to be installed as they depend on the internal functions it provides. It's not an ideal solution, but it's simple.
This is what I proposed.
Usage
To use the assertions (also installs potentially unnecessary helpers):
install bats-helpers

To use another library (also installs potentially unnecessary helpers):
install bats-helpers
install bats-other-library

Alternative 2: Assertions as core
Same as alternative 1, except that the core library (bats-assert) would only contain assertions and internal functions. Other helpers would go into separate libraries and would depend on the assertion library to be installed. This is a more modular implementation, but it's counter intuitive why the assertion library has to be installed for using other libraries.
This what @jasonkarns suggested. (Am I correct?)
Usage
To use the assertions:
install bats-assert

To use another library (also installs potentially unnecessary helpers):
install bats-assert
install bats-other-library

Alternative 3: Fully modular architecture
Same as alternative 2, except that assertions (bats-assert) and internal functions (bats-core) are separated into their own libraries. The internal library has to be installed in order to use any user facing libraries, e.g. assertions, mocking. This is a completely modular implementation. It ensures that no unnecessary helpers are installed, but at the cost of slightly more complicated usage.
Usage
To use the assertions:
install bats-core
install bats-assert

To use another library:
install bats-core
install bats-other-library

Conclusion
There's a tread-off between ease of use and modularity. We already have an internal library that needs to be shared between libraries, which complicates the situation.
To be honest I would go with number 3, but I thought people would not like it because of the added complexity entailed by modularity.

TBH, I was thinking more along the lines of option 3, but not thinking about any core/internal helpers other than standard assertions.
I think 3 may be the way to go for organization, but it increases the complexity of managing all the projects. (Especially considering there won't be any simple way to handle versioning and compatibility between the libs.) Personally, my projects will need to use npm for these libs. They won't need published to npm itself; rather, I would expect they simply include a minimal package.json and I would reference them directly from github. (I'm hoping that we can actually use the same package.json to support both npm and bpkg.) But for anyone who doesn't use npm, resolving version compatibility between these various libs would be a manual effort. This theoretically makes option 1 more appealing, but it doesn't actually avoid the issue, it just reduces the number of libs to deal with.
OTOH, since I don't expect a lot of churn, there probably won't be many version compatibility issues in the first place. So I'm still voting for 3.

@jasonkarns Same here. While the handling of versioning and compatibility will not be a dream, I don't expect it to be a too heavy burden later on. Like you said, consolidating libraries would not help all that much.
I have a busy week ahead, but the standalone version should be ready by Friday (hopefully earlier). Most of the changes will be in documentation. Removing man pages, rewriting the section about loading libraries, and adding installation notes. I'll add git-submodule and git-clone as installation methods. The rest can be added by people more knowledgeable about npm, bpkg, etc.
It won't be super polished at first, but I want to release early and often. I will comment here when the repos are up.

There are more changes than I expected, but the standalone version is coming along nicely.
There's however one question that didn't get enough attention before. What licence should we use? I can't imagine anyone wanting to invest in using software that may later turn out to be incompatible with his/her project. Especially that many would want to use these libraries at work to test commercial software.
I think a suitable licence should be selected before releasing these libraries.
Things that would help:

comments from people knowledgeable on the topic
asking on Stack Overflow
writing to the FSF

Help is much appreciated. If nobody has the time, I'll go the Stack Overflow and FSF routes after finishing the standalone versions.

MIT ?

Bats itself is under MIT, so consistency would be nice. Though I believe @mislav generally prefers CC0

I was thinking about the licence compatibility issue.

However, when using test helper libraries, the licence of the libraries and the licence of the test files using them must be compatible.

Furthermore, if a test file sources a file of the project (for example to do unit tests on a library) the licences of the sourced file, the test helper library, and the test file must all be compatible.

Is this correct? If yes, the licence we use could forbid certain projects of using the test libraries. The more permissive the licence, the larger the selection of compatible licences. But my reasoning could be incorrect.

To my knowledge, CC0 is literally the most permissive license possible.
It's essentially public domain.
On Wed, Feb 3, 2016 at 1:00 PM, Zoltán Tömböl<EMAIL_ADDRESS>wrote:

I was thinking about the licence compatibility issue.
However, when using test helper libraries, the licence of the libraries
and the licence of the test files using them must be compatible.
Furthermore, if a test file sources a file of the project (for example to
do unit tests on a library) the licences of the sourced file, the test
helper library, and the test file must all be compatible.
Is this correct? If yes, the licence we use could forbid certain projects
of using the test libraries. The more permissive the licence, the larger
the selection of compatible licences. But my reasoning could be incorrect.
—
Reply to this email directly or view it on GitHub
https://github.com/sstephenson/bats/pull/110#issuecomment-179377636.

Consistency would be nice. Users of Bats would have to be familiar with only one licence instead of two. But we don't know whether the MIT licence would forbid testing software that is covered by a non-compatible licence, e.g. CC0. To be on the safe side, I vote for CC0.
The standalone version is not ready yet unfortunately. Hopefully I can finish it during the weekend. Until then, let's see if anybody else wants to chime in on the licence question.

Release
After more than 9 month of development and nearly 7 month of discussion the test helper libraries have finally been released!
The initially proposed Standard Library of Test Helpers have been broken up into two external libraries and an additional repository storing shared documentation.

bats-core - Supporting library for Bats test helpers. Limited to output formatting at the moment.
bats-assert - Common assertions for Bats. Functions that were the main focus of this discussion.
bats-docs - Shared documentation covering installation, loading and testing of libraries.

Features:

Unified and simple library loading that shields the user from the internal implementation and layout of the library.
Manual dependency loading to keep libraries simple.
Detailed documentation.
Thorough testing.
Licensed under CC0 for compatibility with tested software.

Moving forward all discussion should happen on the issue tracker of the respective repository.
@thomasleveil You opened some very interesting pull requests over at my fork of Bats. If you are still interested, would you please reopen them on the new repositories?
Thanks
Thanks to everyone who contributed to the discussion.
Special thanks to @sstephenson @mislav @thomasleveil @jasonkarns for their invaluable contribution. Without you guys, we wouldn't have the quality libraries we have now.

Awesome!! Looking forward to test them with basher when I'm back from the
holidays!
On Feb 9, 2016 11:20 PM, "Zoltán Tömböl"<EMAIL_ADDRESS>wrote:

Release
After more than 9 month of development and nearly 7 month of discussion
the test helper libraries have finally been released!
The initially proposed Standard Library of Test Helpers have been broken
up into two external libraries and an additional repository storing shared
documentation.

bats-core https://github.com/ztombol/bats-core - Supporting
library for Bats test helpers. Limited to output formatting at the moment.
bats-assert https://github.com/ztombol/bats-assert - Common
assertions for Bats. Functions that were the main focus of this discussion.
bats-docs https://github.com/ztombol/bats-docs - Shared
documentation covering installation, loading and testing of libraries.

Features:

Unified and simple library loading that shields the user from the
internal implementation and layout of the library.
Manual dependency loading to keep libraries simple.
Detailed documentation.
Thorough testing.
Licensed under CC0 for compatibility
https://github.com/sstephenson/bats/pull/110#issuecomment-17937763
with tested software.

Moving forward all discussion should happen on the issue tracker of the
respective repository.
@thomasleveil https://github.com/thomasleveil You opened some very
interesting pull requests https://github.com/ztombol/bats/pulls over at
my fork of Bats. If you are still interested, would you please reopen them
on the new repositories?
Thanks
Thanks to everyone who contributed to the discussion.
Special thanks to @sstephenson https://github.com/sstephenson @mislav
https://github.com/mislav @thomasleveil https://github.com/thomasleveil
@jasonkarns https://github.com/jasonkarns for their invaluable
contribution. Without you guys, we wouldn't have the quality libraries we
have now.
—
Reply to this email directly or view it on GitHub
https://github.com/sstephenson/bats/pull/110#issuecomment-182158121.

Notifications
@X1011 @nskforward @ivans @gwen21 @dmp1ce @jwilder @marcondesdddi @mudler
I noticed that a while ago you started using the Bats test helper library we've been developing in this pull request. Good news! The library's been finally released! Check out the announcement above to learn more!

@ztombol I will take a look at the pull requests later this week


Register first version

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/79356
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 4501841f360a1f6e5335003bb78e1d0156f6f485
git push origin v0.1.0


*: supports batch split

LGTM.

PTAL @disksing @Connor1996 @rleungx

PTAL @rleungx

Please update kvproto


chore(deps): upgrade to android API level 31

Description
Also upgrades java to 11, gradle to 7.3.3, AGP to 7.0.4.
Other changes
N/A
Tested
Manually building the app
How others should test
Run app on android and make sure the app loads successfully for both new and existing users
Related issues

Fixes ACT-442

Backwards compatibility
Yes

@satish-ravi can you add the podfile.lock to see if we run into the same issue with Detox on iOS?

@MuckT I've reverted the reanimated package bump, since we didn't need it for fixing android build. iOS passes now.

@satish-ravi I'll turn on Android #4 lets confirm it runs ok there. Then I think we're good to merge. Afterwards I can update Android 1 - 3 and we can have a follow up PR to charge the group to android-e2e-group.

Hey @MuckT we will cover the above PR while performing BVT's and Regression testing
Thanks!

Hey @MuckT we have verified the above task on latest Android internal release build and latest iOS Testflight build V:1.41.0 during BVT and regression testing and below are the links for BVT and regression
Test Rail links :
Bvt Link
Android 10: https://valoraapp.testrail.io/index.php?/runs/view/230&group_by=cases:section_id&group_order=asc
Android 12: https://valoraapp.testrail.io/index.php?/runs/view/231&group_by=cases:section_id&group_order=asc
iOS 14: https://valoraapp.testrail.io/index.php?/runs/view/229&group_by=cases:section_id&group_order=asc
iOS 12 : https://valoraapp.testrail.io/index.php?/runs/view/228&group_by=cases:section_id&group_order=asc
Regression Link
Android 12: https://valoraapp.testrail.io/index.php?/runs/view/236&group_by=cases:section_id&group_order=asc
iOS 12: https://valoraapp.testrail.io/index.php?/runs/view/237&group_by=cases:section_id&group_order=asc
CC: @satish-ravi


Update: KDE.kile version 2.9.93

Auto-updated by vedantmgoyal2009/winget-pkgs-automation in workflow run 454
Microsoft Reviewers: Open in CodeFlow

/azp run


Parents of MONDO:0018982 'Niemann-Pick disease type C'

Stemming from https://github.com/EBISPOT/efo/issues/292
Niemann-Pick disease type C is a metabolic disorder (a sphingolipidosis) that may result in severe phenotypes affecting several systems, especially neurological symptoms. However, in MONDO some of the current parents of the term (http://purl.obolibrary.org/obo/MONDO_0018982), presumably derived from Orphanet (http://www.orpha.net/ORDO/Orphanet_646), seem incorrect (e.g. 'unclassified primitive or secondary maculopathy', 'supranuclear oculomotor palsy'). The classification of the Orphanet term in EFO is not exactly the same but presents similar issues (https://www.ebi.ac.uk/ols/ontologies/efo/terms?iri=http%3A%2F%2Fwww.orpha.net%2FORDO%2FOrphanet_646). We've already removed the parentage to 'neoplasm', and would like to fix the other parents, and it would be better to do this consistently with MONDO. Could you please revise the hierarchy of MONDO:0018982 and let us know what you think of e.g. the maculopathy and palsy parents?
Thanks!

@nicolevasilevsky @cmungall
FYI, we may want to discuss this ticket at our next EFO-MONDO call, along with our EFO epic https://github.com/EBISPOT/efo/issues/322.

Same issue as broader topic in https://github.com/monarch-initiative/mondo/issues/834

@paolaroncaglia I realized I am not totally clear - which superclasses would you like to be removed from MONDO:0018982 'Niemann-Pick disease type C'?

'unclassified primitive or secondary maculopathy',
'supranuclear oculomotor palsy'

Any others?
Thanks!

@nicolevasilevsky (Happy Thanksgiving, no hurry...):

@paolaroncaglia I realized I am not totally clear - which superclasses would you like to be removed from MONDO:0018982 'Niemann-Pick disease type C'?
* 'unclassified primitive or secondary maculopathy',

* 'supranuclear oculomotor palsy'

Any others?
Thanks!

I think that all of the current parents are incorrect and should be removed, except for 'Niemann-Pick disease'. The ancestry to specific metabolic disorders is already inherent in the parentage of 'Niemann-Pick disease' itself. Thanks!


[BUG] Cannot add new line in Secrets/ConfigMaps when editing config over UI

Rancher Server Setup

Rancher version: 2.7.4

Information about the Cluster

Kubernetes version: 1.24.10

User Information

What is the role of the user logged in? Admin, but concerns every user.

Describe the bug
When one wants to edit a Secret or ConfigMap over the UI, this can be done either via Edit Config or Edit Yaml. Since we updated to Version 2.7.4 from 2.6.11, we cannot add new lines any more when we want to add a new line in the option Edit Config. This worked previously.
To Reproduce
Create a Secret or ConfigMap. Go to the UI and edit the Secret or ConfigMap by adding a new line somewhere.
Result
It should be possible to add new lines.
Expected Result
One should be able to add new lines when editing Secrets and ConfigMaps in the Option Edit Config

@Ujkugri Any solution that you found . Our Users also facing similar issue post upgrade .

The only help was to avoid Version 2.7.4. If you are on another Version, I would recommend a rollback.

@Ujkugri we have 2 environments and issue is on both of them .


make command "docker plugin inspect" complete

in inspect.go:
cmd := &cobra.Command{
	Use:   "inspect [OPTIONS] PLUGIN [PLUGIN...]",
	Short: "Display detailed information on one or more plugins",

LGTM 🐸
/cc @sfsmithcha @thaJeztah @SvenDowideit

LGTM - perhaps you could roll these up into one PR in future?

ok:)


Use numpy.longdouble instead of numpy.float128 in testing

numpy.float128 doesn't exist on all platforms, e.g., Windows 64-bit.
When numpy.float128 does exist (e.g., Linux 64-bit), it's typically an
alias for numpy.longdouble.
Fixes #316.

Coverage remained the same at 82.098% when pulling e1e319f844edb2e6a22aa815ca42806d47c6cf5f on roryyorke:master into 089936f5e41d031d5bbdee8e5971638246117b19 on python-control:master.

Coverage remained the same at 82.098% when pulling e1e319f844edb2e6a22aa815ca42806d47c6cf5f on roryyorke:master into 089936f5e41d031d5bbdee8e5971638246117b19 on python-control:master.