Wrong base64 encoding when retrieved back using Filesystem.readFile()

Hi.
First of all thank you for creating this great library. I have a requirement of storing big audio files on which Capacitor FileSystem.writeFile() failed on android devices (crashes when the file is too big) that this library seems to handle very well.
Now the issue I am facing is when I try to load it back:
const { data } = await Filesystem.readFile({
    path,
    directory: Directory.Documents
  });

const blob2 = new Blob([data], contentType);
const blob3 = (await fetch(`data:${contentType};base64,${data}`)).blob();

/**
 *  blob2 -> Failed to construct 'Blob': cannot convert to dictionary.
 *  blob3 ->TypeError: Failed to fetch
 */

Filesystem.readFile() suppose to load a base64 encoded data which I need to pass to an audio player, but as it failed to read it, blob2 and blob3 here are just my attempts to re-construct the blob with the loaded base64 to ensure it is correct.
What is strange to me, is while both failed on web and iOS environments, blob3 worked fine on android and re-converted base64 from it did also work in the player.
I have no idea if it is related to the way this library is storing the blob, if it is related to the way Filesystem.readFile() is reading it, or if it is something else I am doing wrong.
I made a live sandbox to reproduce it here.
Any help is appreciated. Thank you.

Capacitor is capable of reading large files without encoding them as strings. All you need is the URI of the file on disk, which can be obtained with Filesystem.getUri.
write_blob({path, directory, blob}).then(function (uri) {
    audio_element.src = Capacitor.convertFileSrc(uri);
});

Thank you very much.
That worked fine on Android. Unfortunately it did not work under web or iOs as I did only get a full path (starting with file:// ) on Android.
For web it looks like a known issue, but for some reasons Filesystem.getUri is returning an empty object on iOs and a dynamic path when using Filesystem.stat:

That is the related output on iOS of this code (got exact same output for stats and stats2):
return {
  path,
  src: Capacitor.convertFileSrc(path),
  stats: await Filesystem.stat({
    path,
  }),
  stats2: await Filesystem.stat({
    directory: Directory.Documents, // tried also External and Data
    path: 'downloads/' + uuid,
  }),
}

This looks like a bug in Filesystem.getUri, which this plugin uses under the hood. Can you report it to the Capacitor maintainers?

Yes I'll do. It is strange that I have only seen one similar case to mine here. I suspect it has something to do with my Nuxt app being generated as a PWA. I'll investigate it a bit more, make a mini repo to reproduce it and open an issue there. Thanks.

I just realised, Capacitor.convertFileSrc expects an absolute path on iOS, not a file:// URL. So there should be no problem?

A figured it out. It happens when you enable WKAppBoundDomains on iOS (see https://github.com/ionic-team/capacitor/issues/4721#issuecomment-873183407). Removing that key fixed it. Thank you;

Hi - I raised an issue (here) and then saw this one which is almost a duplicate.
This library is great and working well for me on Android (thank you!). I can't find a way to get it to work on web though. At the moment according to https://github.com/ionic-team/capacitor/issues/3491 the ConvertFileSrc function doesn't work with the web so even though I can write a large file to local storage I can't find any way to read it back again. Using Filesystem.readFile does generate a string which looks like base64 but it doesn't work. I found out that if I paste this string into a repair utility (https://base64.guru/tools/repair) then it can be repaired and in fact the repair splits the string into two parts and the first part is correct. Maybe that could give a clue to what is happening?
It would be even better to skip base64 conversion completely and avoid using Filesystem.readFile but I can't find a way to get at the file stored in web storage (indexDB) which looks like /DATA/xxxxxxxx - is there a way to read this directly as a file or blob?
thanks for any pointers
Marcus

Yes it is tricky. I only use the web platform for development of my app, so I was able to use the FileSystem API, which has poor browser support.
If you need to support all major browsers, you could try writing your Blob to IndexedDB, and then using the URL.createObjectURL function to access it as a URL.

Please report back if you find a solution, @mrobst .

Hi - I've spent some more time looking into this and I can give a better description now of where I think the issue is....
When using capacitor-blob-writer in the browser the logic checks for Capacitor platform and triggers the write_file_via_bridge function which in turn calls append_blob. This function splits up the binary file into multiple base64 strings and calls Capacitor Filesystem.appendFile to save the blob into local storage.
I took the same file and first wrote it to local storage with Filesystem.writeFile then again with capacitor-blob-writer (which falls back to Filesystem.appendFile as it should). The resulting two files end up different with the latter being slightly larger in size (screenshot 1).
I then used Filesystem.readFile on both files. The one saved with Filesystem.writeFile returns valid base64. The one saved with append_blob/Filesystem.appendFile returns invalid base64. If I take this string and put it into an online repair utility ( https://base64.guru/tools/repair ) I get information that the file contains incorrect padding and multiple base64 values (screenshot 2).
My conclusion is that either Filesystem.writeFile behaves differently to Filesystem.appendFile (there is one line of code different between them in how the data / encoding is handled) or more probably the logic in append_blob here isn't quite chunking a blob into base64 correctly?  Let me know if this is enough info to have a look at append_blob or if I should try and create a plnkr to reproduce the issue?
thanks!
Marcus


device: add constructor from devnum

In cases where you have a device open or only have the /dev path, this lets us open up the device much more conveniently.

Thanks


MySQL/HowTo: Fix small formatting

So it can be easily maintained in the future

thanks @kevinbowman-aiven I've fixed now!


Improved docs - readme , contributing and hacktoberfest files

Improved README, CONTRIBUTING, HACKTOBERFEST md files by adding necessary 15+ links for navigation to users easily.
Kindly review and merge the same.
Thank you!

@holopin-bot @GuptaPratik02


Multiregion deployment !

I have a question about deploying subutai in diffrent geo zones, I am working on deploying a usergrid stack alongside cassandra+elasticsearch, when I use the cli or the webconsole for deployment, are cassandra and  UG in Multi-DC config ?

Hi @aminesig !
Well, that depends on the settings you put into cassandra.yaml file.
Are you using our Cassandra plugin or doing the deployment manually?
If the plugin is used, it configures the cluster in a simplest way similar to described in this article: https://www.digitalocean.com/community/tutorials/how-to-run-a-multi-node-cluster-database-with-cassandra-on-ubuntu-14-04

I am using the plugin from Subutai, I think It will do for my use case, Thank you !


Installation on Mac M1 Processor fails

Pip install fails on Mac M1 chip with the error
FileNotFoundError: [Errno 2] No such file or directory: 'README.md'
when it tries to install ecos==2.0.11
https://github.com/embotech/ecos-python/issues/33
Workaround for this issue is to install ecos 2.0.5 version before installing empyrial
pip install ecos==2.0.5
@ssantoshp Can we add it to the installation docs for people using Mac M1 processor or adding this requirement in requirement.txt ?

Thanks for reporting it, will do!


1.0.5 release?

I realize that this project is winding down due to the release of Bootstrap 4... but for those of us still using it, would it be possible to mint a 1.0.5 release? 1.0.4 came out in 2014, and there seems to have been significant development in master since then; it would be nice to be able to take advantage of this through Bower, for example.

<EMAIL_ADDRESS>

@mpnkhan, I see 1.0.6 on NPM (https://libraries.io/npm/bootstrap-accessibility-plugin/1.0.6), but it does not appear to be tagged in this repository, and I cannot load it through Bower. Am I missing something?

I was not sure why it didn't list. $ git show v1.0.6 listed the changes and npm install also worked.
Now have updated bower.json and manually tagged to 1.0.7.
This should work:
bower install bootstrapaccessibilityplugin#1.0.7

Thanks, @mpnkhan, it is working now. I appreciate the help!


Reserve Motocyle - FRONTEND (REACT)

Consume API from Backend Reserve Motocycle
Reserve Motorcycle (Backend) #6
Ensure that the requirements are followed
To reserve an motorcycle, the user has to select a date and city (username and selected item are autofilled).
Use the design based on the "Book a vespa test-ride" and add all necessary inputs.
The user can also access the "Reserve" page from the navigation panel. In that case only username is autofilled.

This task is assigned to Victor


Edit Property Value - textbox does not expand vertically with the window

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Problem
For an Azure table if you edit an entity and then click to edit one of the values. When resizing the window, the property value textbox does not resize vertically, only horizontally.
Desired Solution
I'd like the property value textbox on the "Edit Property Value" screen to also expand vertically when resizing the window.
Alternatives and Workarounds
No response

Additional Context
When the property value is large and multi-line it is difficult to view/edit the value as the textbox remains quite small.

Thanks!


twister: setup soc/arch roots based on module settings

Get data for various roots from modules and do not hardcode location
when retrieving list of boards in testplan.
Fixes #71761
Signed-off-by: Anas Nashif<EMAIL_ADDRESS>

@PerMac  @hakehuang @gchwier @golowanow Please review!


Add Season invite page

Add a page to invite users to a season you are the draft owner of. Should auto create a new team for each invitee.

Done in https://github.com/mawilson/survivor_draft/pull/163


[Q] TSP dektec input plugin blocks the process if the port is not connected to any ASI stream

Hi,
We are trying to control the tsp's dektec input plugin via the control port to switch between channels on some user input. What we observe is, if we start the tsp dektec input plugin with channel where no input is connected, then the plugin simply blocks the process and controlling from the tspcontrol will not work (connection refused). I think the tsp hasn't started the server yet. In this case we are left with no choice but to restart the entire process manually.
So can you help us on any way to properly handle this situation? Below are the debug log of running the tsp with the dektec input plugin on the channel where no input is connected,
$ tsp --debug --control-port 5050 -I dektec --device 1 --channel 0
tsp: Debug: debug level set to 1
tsp: Debug: ====> tsp --debug --control-port 5050
* Debug: debug level set to 1
* Debug: dektec: debug level set to 1
* Debug: dektec: ====> tsp -I dektec --device 1 --channel 0
* Debug: file: debug level set to 1
* Debug: file: ====> tsp -O file
* Debug: tsp: buffer size: 89,240 TS packets, 16,777,120 bytes
* dektec: using Dektec device 1, input channel 0 (DTA-2144B port 1)
* Debug: dektec: attaching to device DTA-2144B serial 0x000000007FCB0BC5
* Debug: dektec: attaching to port 1
* Debug: dektec: resetting channel, mode: 1
* Debug: dektec: setting RxControl, mode: 0
* Debug: dektec: clearing FIFO and flags
* Debug: dektec: getting FIFO max size
* Debug: dektec: max FIFO size: 33,554,432 bytes
* Debug: dektec: using FIFO size: 33,554,432 bytes
* Debug: dektec: setting RxMode, mode: 17
* Debug: dektec: setting RxControl, mode: 1

Hi @sathish25071992
Yes, your observations are correct. The first thing that tsp does is initializing the input and trying to read the initial load. The idea is to avoid starting / creating / locking other resources when there is nothing to read from input or the input is invalid / incorrect.
In the case of a Dektec ASI board, if reading from an unplugged cable blocks forever, then the tsp initialization will wait forever. The initial behavior really depends on the input plugin and device.
TSDuck is a generic lab tool for experimentation. All input/output plugins have the same generic interface and basic expected behavior. If you want a precise behavior which depends on specificities of an input device, then you have to develop your own specialized application.

If you want the details of the tsp initialization sequence, you may have look at the source code here. The initial load from the input plugin is performed around the middle, after all plugins are initialized, but before starting them. The control server is started at the very end, when all plugin threads are in a stable state.

Thank you for the quick response @lelegard . Will go through the code further on understanding the flow. Actually, we are planning to use the TSDuck library for the customized application. So as per the code, if we write our custom sub-class derived from TSProcessor and create a custom start method where we start the server as very first thing then we start plugin should be able to handle this condition right?.

So as per the code, if we write our custom sub-class derived from TSProcessor and create a custom start method where we start the server as very first thing then we start plugin should be able to handle this condition right

Not really. This is not as simple as that. The interactions between the plugins, their executor thread and the global buffer are rather complex. I do not recommend changing the order of things or you would risk diving into an endless debugging cycle. Moreover, if reading from the Dektec ASI board blocks when there is no stream, restarting the input won't do anything since the previous input operation still blocks the input thread (note that in the current scheme, all initializations are done even before the plugin threads are started).
The Dektec input and output plugin were designed to interface the generic Dektec API. However, distinct types of devices have distinct behaviors : ASI, modulators, demodulators, Ethernet, etc.
If your really want to address specific behaviors of the ASI boards, you may need to directly interface DTAPI, the Dektec-API.
Alternatively, instead of using tsp, you may have a look at tsswitch. This application takes several input plugins. You may start it using multiple Dektec plugins, one per port, and then switch between them. Note that I am not 100% sure that accessing the same Dektec boards at the same time works. You need to test.

Ok got it. Let me check the tsswitch option.
Also as I check the source there is a timeout based dektec read which gets executed if the user provides --receive-timeout option. Using that makes the entire tsp process to exit if it timesout. Since we use custom application that invokes the tsProcessor::start, I think if it exits with error I can intimate the user and wait for proper channel input from user or retry.

Closing this issue as the --receive-timeout was able to get us going. Thank you for your support @lelegard


Please export a jar

Please modify the build system (and ideally source layout) such that it is easy to build a JAR which other tests can easily depend on.

Do you need just the test cases or also the test runners?

I think we'd need the runners as well.

We can build and upload a JAR to Maven.

This won't actually solve my problem.  I really need a build-target which outputs the jar.

Pinging this again. I have some code which I really want to test with Wycheproof, but for various reasons it is much easier for this code to consume Wycheproof as a test dependency than have Wycheproof depend on it. I experimented, and it seems a tad tricky to get bazel to include junit as a normal dependency (so that it can just build a jar containing all of the tests and runners). It looks like we could build an empty test case and then use the jar generated by that as the artifact.

Quan, could you please take a look?

I'm sorry, I'm pretty overwhelmed right now. I don't have cycles to work on it in a month or two

Just bumping this as it's been a while and we could really use a consumable version of this to test various libraries.


Add a Warning to the page: You may be blocked forever if you are not in the whitelist

Hi,
Once the Access List is set, only Whitelisted IPs can make further requests. So in case, you have no longer access to the whitelisted location, you will be blocked forever and you will no longer be able to update or delete the list.
Please add a BIG WARNING ABOUT THIS or explain if we need to open a support request so that MS unblocks it (If supported).

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: fb833fb7-abf9-432d-ab67-8b94c445407d
Version Independent ID: 082b9e2c-aabd-1ff2-6782-1014ecfaa5ba
Content: IP access lists - Azure Databricks
Content Source: databricks/security/network/ip-access-list.md
Service: azure-databricks
GitHub Login: @mssaperla
Microsoft Alias: saperla

@SamirFarhat
Thanks for your feedback! We will investigate and update as appropriate.

@SamirFarhat
Thanks for your contribution. Please add your ideas in below link, so our production team can review it and update the same.
Ideas · Community (azure.com)


Slim term order

This issue originates from an alliance / ribbon requirement.
Problem description:
2 years ago, the Alliance slim was hard coded in the ribbon, probably due to the need of having   a specific ordering and also because some terms label were changed: https://github.com/geneontology/ribbon/blob/master/src/data/agr.js
After discussing with @cmungall some time ago of this ordering requirement, since the problem seemed to come only from the alliance, we aimed for a temporary simple but unclean solution: the hard coded alliance slim was moved from the ribbon to the GO API, so at least any external user / tool will receive the same slim.
Proposal: add a property to slim term in the ontology so that the ordering can be derived from a unique and clean source (the ontology) and not hardcoded later.
@pgaudet

We could do this by annotating each class-slim triple with the order. We
could either have a rank, or a linked list structure. With the former it's
tedious to insert into the list without giving editors more tooling. Either
way it's a bit of a faff to edit in Protege,
Maybe the source should be an external file and we turn this into owl and
inject into ontology?
On Wed, Oct 2, 2019 at 10:14 AM lpalbou<EMAIL_ADDRESS>wrote:

This issue originates from an alliance / ribbon requirement.
Problem description:
2 years ago, the Alliance slim was hard coded in the ribbon, probably due
to the need of having a specific ordering and also because some terms label
were changed:
https://github.com/geneontology/ribbon/blob/master/src/data/agr.js
After discussing with @cmungall https://github.com/cmungall some time
ago of this ordering requirement, since the problem seemed to come only
from the alliance, we aimed for a temporary simple but unclean solution:
the hard coded alliance slim was moved from the ribbon to the GO API, so at
least any external user / tool will receive the same slim.
Proposal: add a property to slim term in the ontology so that the
ordering can be derived from a unique and clean source (the ontology) and
not hardcoded later.
@pgaudet https://github.com/pgaudet
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/geneontology/go-ontology/issues/17943?email_source=notifications&email_token=AAAMMON47QCS2XX6XR3IPM3QMTJH5A5CNFSM4I4ZDGKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HPGC45A,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAMMOMWGZ7LJOOQHLX2TV3QMTJH5ANCNFSM4I4ZDGKA
.

Another import?

Decision by ontology editor is to create a separate tab delimited file
@cmungall


Update COT001: add suffixes and fix text elements

Mirroring https://github.com/Citavi/C6-Citation-Style-Scripts/commit/b56192c02fa1a02e7bf1617f14ebe8dbdcc796f9

Superseded by https://github.com/Citavi/C6-Citation-Style-Scripts/commit/fa9f5ab456274d437249a78eeb79aac7cf9d3945


Is there a way that the Dashboard can open an existing workspace?

Basically I am wishing there was a 'workspace' project type that just had the path for the workspace configuration file, and then did a workbench.action.openWorkspaceInNewWindow or workbench.action.openWorkspace for that file.

Do you mean multi-folder workspaces which are then saved as a WorkspaceName.code-workspace file?

Yes, by workspace I mean the the stuff that is saved in the .code-workspace file.  But that file is more then just a way to just have a project with multiple folders. It can act as a scope for configuration settings.
So lets say I want to have various personal settings for a project, but not modify the .vscode/settings.json since that is included in our VCS so everyone has some settings that are identical for everyone.  But everyone doesn't want to be forced to use my theme for a given project, and I want different themes for a couple projects. I apply my theme in the workspace. I also have various other configuration settings to make vscode work my way, but other members of team don't like, so can't be added to the folder settings.

I understand! I'm using them myself. :-)
I was just asking because the dashboard already includes that option. When adding a project, select the project type File or Multi-Root Project and pick the .code-workspace file. When you open that project via the dashboard, all workspace settings are applied as usual. I just tested it out by setting the theme in the workspace settings and opening the workspace project. Is this the functionality you are asking for?
I'll probably rename that project type to Workspace or File Project makes more sense.

Yes, that does what I want.  Sorry for time wasting.

I'll probably rename that project type to Workspace or File Project, makes more sense

Renaming it might help.  Or perhaps just adding a note about what the different project do in the in the configuration section of your README.

Yes, that does what I want. Sorry for time wasting.

No problem! This was just an indicator that the function is not clear.

I'll probably rename that project type to Workspace or File Project, makes more sense

Renaming it might help. Or perhaps just adding a note about what the different project do in the in the configuration section of your README.

I guess I'll stick with renaming. Hardly anybody reads READMEs anyway. ;)


Fix/object hash

Description
Fix a critical issue regarding the computation of Object hash, this is used as index keys to avoid persisting many times the object part of triples.
Issue details
In the case of a named node Object, the value part of the node wasn't taken into account in the hash computation, which results in considering equal two different Objects having the same namespace.

size-limit report 📦

Path
Size

target/wasm32-unknown-unknown/release/okp4_objectarium.wasm
402.55 KB (0%)

target/wasm32-unknown-unknown/release/okp4_law_stone.wasm
650.74 KB (0%)

target/wasm32-unknown-unknown/release/okp4_cognitarium.wasm
769.3 KB (-0.01% 🔽)


[Doc] : Visual Enhancements , Fostering Contact Channel in README

Issue Description
Problem: A poorly structured or visually unappealing README can create confusion and hinder user engagement with a project.

This can lead to:

Difficulty understanding the project: Newcomers may struggle to grasp

Reduced contributions: Potential contributors may be deterred by a lack of clear information

Negative first impression: An unprofessional README can reflect poorly on the project and discourage users from
exploring further.

Description :

To enhance communication and provide direct access to Project Guidance, I plan to include a dedicated Contact section 👤. This section will feature the LinkedIn and GitHub profiles of each mentors and Admin⚡ enabling contributors to readily connect with them and address any project-related queries.

Additionally, to improve readability and organization, I Planned to implement clear visual separations between each section of the contributor documentation, ensuring a user-friendly and easily navigable 🚏 experience.

Finally, to foster a welcoming 🙏🏻 and inclusive environment, I will incorporate personalized welcome messages for our Repository.

To effectively convey the essence of our project and its objectives, I propose creating a customized cover image for the repository.

Kindly Assign me this Issue Under 🌸 Gssoc, ☘ hacktoberfest . I'm grateful to work with Talented Crews ✨.

Issue Description
Problem: A poorly structured or visually unappealing README can create confusion and hinder user engagement with a project.
This can lead to:

Difficulty understanding the project: Newcomers may struggle to grasp
Reduced contributions: Potential contributors may be deterred by a lack of clear information
Negative first impression: An unprofessional README can reflect poorly on the project and discourage users from
exploring further.

Description :

To enhance communication and provide direct access to Project Guidance, I plan to include a dedicated Contact section 👤. This section will feature the LinkedIn and GitHub profiles of each mentors and Admin⚡ enabling contributors to readily connect with them and address any project-related queries.

Additionally, to improve readability and organization, I Planned to implement clear visual separations between each section of the contributor documentation, ensuring a user-friendly and easily navigable 🚏 experience.

Finally, to foster a welcoming 🙏🏻 and inclusive environment, I will incorporate personalized welcome messages for our Repository.

To effectively convey the essence of our project and its objectives, I propose creating a customized cover image for the repository.

Kindly Assign me this Issue Under 🌸 Gssoc, ☘ hacktoberfest . I'm grateful to work with Talented Crews ✨.

Not needed


🚀 Feature: Separate templating engine from options parsing

Bug Report Checklist

[X] I have pulled the latest main branch of the repository.
[X] I have searched for related issues and found none that matched my issue.

Overview
Right now, create joins roughly two big engine-y areas:

Options: defining in a schema, parsing from disk + user input, passing to a Template
Templating: the Blocks approach

But, the two don't have to be linked. And long-term I don't think they should be. Most users are going to want to start with very basic templating. A full system of Blocks and Presets is very heavyweight.
Long term I want to split the two. A Template should be able to define its Options as a Zod schema, then once create tells it to run, it does whatever it needs to. I think there are at least two kinds of templating engines that I can see implementers wanting to choose from:

Handlebars: essentially what most existing solutions such as Plop and Yeoman do
The current Blocks approach

The concept of a "Preset" might end up being completely unique to the latter. Maybe the two templating approaches might even be their own separate projects and docs sites, if not just separate packages in the monorepo. TBD.
Additional Info
This is going to happen until after milestone/2 Blocks Launch. I'm going to get the create engine working for create-typescript-app, then expand to other use cases.
💖

I had a think on this and I think it's absolutely the right way to go. Three axioms:

create itself should be as straightforward to get started with as possible
The Creation engine of outputting files, requests, scripts, and suggestions should be the core way Templates express themselves
Blocks are the best way to build complex Templates like CTA

So I'd like to rework the docs and packages structure to reflect that. The core root docs and packages for building Templates won't include the Blocks system at all. To start users off, they'll just show a straightforward Template:
import { createTemplate } from "create";

export default createTemplate({
  about: { name: "My Template" },
  produce() {
    return {
      files: {
        "tsconfig.json": JSON.stringify(
          {
            compilerOptions: {
              module: "NodeNext",
              moduleResolution: "NodeNext",
              strict: true,
            },
            include: ["src"],
          },
          null,
          "\t"
        ),
      },
    };
  },
});

Templates should also be able to have their own Options. That'll allow systems like Presets, but can be more flexible and just directly allow different settings.
For example, a Template might let you choose your package.json "type":
import { createTemplate } from "create";
import { z } from "zod";

export default createTemplate({
  about: { name: "My Package Template" },
  options: {
    name: z.string(),
    owner: z.string(),
    type: z.union([z.literal("module"), z.literal("script")]).default("module"),
  },
  produce({ options }) {
    return {
      files: {
        "package.json": JSON.stringify(
          {
            type,
            name: options.name,
            type: options.type,
            repository: {
              type: "git",
              url: `https://github.com/${options.owner}/${options.name}`,
            },
          },
          null,
          "\t"
        ),
      },
    };
  },
});

Here we see a change in terminology. Previously I'd been calling create an "engine" rather than a "framework" or "library". But now the term "engine" is really superseded by a Templating Engine.
Anyway, that's just the 'getting started' side.
For real-world usage I expect most users will want to choose a Templating Engine.
Two such Engine possibilities have been top of mind for me:

Blocks: the whole reason I made create in the first place!
Handlebars-from-disk: much closer to how existing solutions like Plop and Yeoman

Either way, the Templating Engine can generally provide folks a way to build their Template.
Here's how the Handlebars one might roughly look:
import { createTemplateHandlebars } from "create-template-handlebars";
import path from "node:path";

export default createTemplateHandlebars({
  about: { name: "My Package Template" },
  options: {
    description: z.string(),
    owner: z.string(),
    repository: z.string(),
    title: z.string(),
  },
  source: path.join(import.meta.dirname, "src"),
});

Here's a similarly revamped version of Blocks:
import { createTemplateBlocks } from "create-template-blocks";
import path from "node:path";

export default createTemplateBlocks({
  about: { name: "My Package Template" },
  presets: [presetMinimal, presetCommon, presetEverything],
  suggested: presetCommon,
});

The one unresolved sticking point in that design work is Options.
I'm not sure yet how I want them to be declared.
Especially given #71:

Who defines which Options along with how to fill in defaults?
How will the core create CLI prompt for Options defined by a Template?

TBD.

Feel like I'm jacked into Joshtrix 😅
I like this. The work I'm doing on Avalanche is likely to lean on Handlebars for templating initially as it's simple. I can see occasions where I'd want something more complex - I wouldn't mind the ability to mix and match perhaps?  But I probably won't know how useful that would be until later


Update the README to mention the backends

Hi,
the current (master) README does not mention the different DB backend (Redis, Mongo, Cassandra…). This would be a good improvement.

Yeah, recently i'm overworked with other stuff, but i will find some time next month to finish wiki and improve a little bit new version according to users feedback.
Cheers!


Edited up to line 10k.

You're 25% there :thumbsup:

Yay!
I should be able to pick things up a bit, at least for a few weeks, since the new quarter just began here.
HB

On Mar 30, 2015, at 8:50 AM, Kyle P. Johnson<EMAIL_ADDRESS>wrote:
You're 25% there
—
Reply to this email directly or view it on GitHub https://github.com/cltk/latin_proper_names_cltk/pull/3#issuecomment-87731217.


FFmpeg recording process exited with error! (null) since 5.0.12

Since 5.0.12 update I receive a lot of FFmpeg recording process exited with error! (null) for multiple cams.  My last proper recordings are from this Sunday 3 pm CET everything later was not recorded because of this error for all cams:
[24.1.2022, 07:17:19] [CameraUI] camera.ui v5.0.14 is listening on port 8081 (http)
[24.1.2022, 07:17:32] [CameraUI] VIDEOANALYSIS: New message: Data: [{"zone":"region0","percent":7.012152671813965,"sensitivity":94,"dwell":60,"forceClose":3}] - Motion: detected - Camera: CAM-02
[24.1.2022, 07:17:32] [CameraUI] CAM-02: Motion ON
[24.1.2022, 07:17:33] [CameraUI] CAM-02: FFmpeg recording process exited with error! (null)
[24.1.2022, 07:17:40] [CameraUI] CAM-02: Closing recording process
[HDS ::ffff:<IP_ADDRESS>] Recording download stream 1 is still awaiting generator although stream was closed 10s ago! This is a programming mistake by the camera implementation which prevents freeing up resources.
[24.1.2022, 07:17:52] [CameraUI] CAM-02: Motion OFF - Motion handler timeout.

My config is
                {
                    "name": "CAM-02",
                    "manufacturer": "Reolink",
                    "model": "RLC-810A",
                    "serialNumber": "CAM-02",
                    "motion": true,
                    "doorbell": false,
                    "switches": true,
                    "motionTimeout": 20,
                    "unbridge": true,
                    "hsv": true,
                    "prebuffering": true,
                    "forcePrebuffering": false,
                    "prebufferLength": 4,
                    "videoConfig": {
                        "source": "-i rtmp://XXX/bcs/channel0_ext.bcs?channel=0&stream=2&user=XXX&password=XXX -map 0 -an -dn -flags -global_header",
                        "subSource": "-i rtmp://XXX/bcs/channel0_ext.bcs?channel=0&stream=2&user=XXX&password=XXX -map 0 -an -dn -flags -global_header",
                        "stillImageSource": "-i http://XXX/cgi-bin/api.cgi?cmd=Snap&channel=1&rs=XXX&user=XXX&password=XXX",
                        "maxStreams": 10,
                        "maxWidth": 1280,
                        "maxHeight": 720,
                        "maxFPS": 30,
                        "forceMax": false,
                        "audio": false,
                        "debug": false,
                        "vcodec": "copy"
                    },
                    "videoanalysis": {
                        "active": true
                    },
                    "smtp": {
                        "email": "CAM-02"
                    },
                    "mqtt": {}
                }

Since 5.0.1N update I receive a lot of FFmpeg recording process exited with error! (null) for multiple cams. My last proper recordings are from this Sunday 3 pm CET everything later was not recorded because of this error for all cams:
[24.1.2022, 07:17:19] [CameraUI] camera.ui v5.0.14 is listening on port 8081 (http)
[24.1.2022, 07:17:32] [CameraUI] VIDEOANALYSIS: New message: Data: [{"zone":"region0","percent":7.012152671813965,"sensitivity":94,"dwell":60,"forceClose":3}] - Motion: detected - Camera: CAM-02
[24.1.2022, 07:17:32] [CameraUI] CAM-02: Motion ON
[24.1.2022, 07:17:33] [CameraUI] CAM-02: FFmpeg recording process exited with error! (null)
[24.1.2022, 07:17:40] [CameraUI] CAM-02: Closing recording process
[HDS ::ffff:<IP_ADDRESS>] Recording download stream 1 is still awaiting generator although stream was closed 10s ago! This is a programming mistake by the camera implementation which prevents freeing up resources.
[24.1.2022, 07:17:52] [CameraUI] CAM-02: Motion OFF - Motion handler timeout.

My config is
                {
                    "name": "CAM-02",
                    "manufacturer": "Reolink",
                    "model": "RLC-810A",
                    "serialNumber": "CAM-02",
                    "motion": true,
                    "doorbell": false,
                    "switches": true,
                    "motionTimeout": 20,
                    "unbridge": true,
                    "hsv": true,
                    "prebuffering": true,
                    "forcePrebuffering": false,
                    "prebufferLength": 4,
                    "videoConfig": {
                        "source": "-i rtmp://XXX/bcs/channel0_ext.bcs?channel=0&stream=2&user=XXX&password=XXX -map 0 -an -dn -flags -global_header",
                        "subSource": "-i rtmp://XXX/bcs/channel0_ext.bcs?channel=0&stream=2&user=XXX&password=XXX -map 0 -an -dn -flags -global_header",
                        "stillImageSource": "-i http://XXX/cgi-bin/api.cgi?cmd=Snap&channel=1&rs=XXX&user=XXX&password=XXX",
                        "maxStreams": 10,
                        "maxWidth": 1280,
                        "maxHeight": 720,
                        "maxFPS": 30,
                        "forceMax": false,
                        "audio": false,
                        "debug": false,
                        "vcodec": "copy"
                    },
                    "videoanalysis": {
                        "active": true
                    },
                    "smtp": {
                        "email": "CAM-02"
                    },
                    "mqtt": {}
                }

Add `"rtspTransport": "tcp" to the videoConfig

@seydx This doesn't help for me, interestingly, it went well a long time but broke yesterday:
[24.1.2022, 09:01:56] [CameraUI] camera.ui v5.0.14 is listening on port 8081 (http)
[24.1.2022, 09:02:03] [CameraUI] CAM-02: FFmpeg prebuffer process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:03] [CameraUI] CAM-02: Prebufferring process closed
[24.1.2022, 09:02:03] [CameraUI] CAM-02: Restart prebuffer session..
[24.1.2022, 09:02:03] [CameraUI] CAM-02: Videoanalysis scheduled for restart at 4AM: 1138 minutes
[24.1.2022, 09:02:05] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:05] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:05] [CameraUI] CAM-02: Restart videoanalysis session..
[24.1.2022, 09:02:15] [CameraUI] CAM-02: FFmpeg prebuffer process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:15] [CameraUI] CAM-02: Prebufferring process closed
[24.1.2022, 09:02:15] [CameraUI] CAM-02: Restart prebuffer session..
[24.1.2022, 09:02:15] [CameraUI] CAM-02: Videoanalysis scheduled for restart at 4AM: 1138 minutes
[24.1.2022, 09:02:17] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:17] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:17] [CameraUI] CAM-02: Restart videoanalysis session..

@seydx This doesn't help for me, interestingly, it went well a long time but broke yesterday:
[24.1.2022, 09:01:56] [CameraUI] camera.ui v5.0.14 is listening on port 8081 (http)
[24.1.2022, 09:02:03] [CameraUI] CAM-02: FFmpeg prebuffer process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:03] [CameraUI] CAM-02: Prebufferring process closed
[24.1.2022, 09:02:03] [CameraUI] CAM-02: Restart prebuffer session..
[24.1.2022, 09:02:03] [CameraUI] CAM-02: Videoanalysis scheduled for restart at 4AM: 1138 minutes
[24.1.2022, 09:02:05] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:05] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:05] [CameraUI] CAM-02: Restart videoanalysis session..
[24.1.2022, 09:02:15] [CameraUI] CAM-02: FFmpeg prebuffer process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:15] [CameraUI] CAM-02: Prebufferring process closed
[24.1.2022, 09:02:15] [CameraUI] CAM-02: Restart prebuffer session..
[24.1.2022, 09:02:15] [CameraUI] CAM-02: Videoanalysis scheduled for restart at 4AM: 1138 minutes
[24.1.2022, 09:02:17] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:17] [CameraUI] CAM-02: FFmpeg videoanalysis process exited with error! (null) - Option rtsp_transport not found. -
[24.1.2022, 09:02:17] [CameraUI] CAM-02: Restart videoanalysis session..

remove rtspTransport again, its not supported by the camera
Can you check if the stream still works through eg VLC ?

The stream works fine via VLC, no issue, no change on camera & network side, the difference is only the plugin update.

The stream works fine via VLC, no issue, no change on camera & network side, the difference is only the plugin update.

Hmm, when you downgrade again, everything works normally?

I tried this already: sudo npm i -g<EMAIL_ADDRESS>[24.1.2022, 09:18:22] [Config] Initializing config platform...
[24.1.2022, 09:18:22] [Config] Running in Service Mode
[24.1.2022, 09:18:22] [CameraUI] Initializing CameraUI platform...
[24.1.2022, 09:18:22] TypeError: Cannot read properties of undefined (reading 'once')
    at Function.createUiLogger (file:///usr/lib/node_modules/homebridge-camera-ui/services/logger/logger.service.js:47:29)
    at new LoggerService (file:///usr/lib/node_modules/homebridge-camera-ui/node_modules/camera.ui/src/services/logger/logger.service.js:121:14)
    at new CameraUI (file:///usr/lib/node_modules/homebridge-camera-ui/node_modules/camera.ui/src/index.js:52:17)
    at new HomebridgeCameraUI (file:///usr/lib/node_modules/homebridge-camera-ui/src/platform.js:47:21)
    at /usr/lib/node_modules/homebridge/src/server.ts:440:40
    at Array.forEach (<anonymous>)
    at Server.loadPlatforms (/usr/lib/node_modules/homebridge/src/server.ts:372:27)
    at Server.start (/usr/lib/node_modules/homebridge/src/server.ts:159:29)
[24.1.2022, 09:18:22] Got SIGTERM, shutting down Homebridge...

I tried also this: sudo npm i -g<EMAIL_ADDRESS>[24.1.2022, 09:22:50] [CameraUI] camera.ui v5.0.12 is listening on port 8081 (http)
[24.1.2022, 09:22:51] [CameraUI] VIDEOANALYSIS: New message: Data: [{"zone":"region0","percent":5.04774284362793,"sensitivity":96,"dwell":60,"forceClose":3}] - Motion: detected - Camera: CAM-02
[24.1.2022, 09:22:51] [CameraUI] CAM-02: Motion ON
[24.1.2022, 09:22:55] [CameraUI] CAM-02: FFmpeg recording process exited with error! (null)
[24.1.2022, 09:23:01] [CameraUI] CAM-02: Closing recording process
[24.1.2022, 09:23:11] [CameraUI] CAM-02: Motion OFF - Motion handler timeout.
[HDS ::ffff:<IP_ADDRESS>] Recording download stream 1 is still awaiting generator although stream was closed 10s ago! This is a programming mistake by the camera implementation which prevents freeing up resources.

@iuliusmaximilian
Is the stream running in parallel anywhere else?

I have an NVR from Reolink that records (still) on top 24h but this was always the case nothing changed, that's the only stream from that camera nothing else.

@iuliusmaximilian
you wrote "since 5.0.12"
is it working with eg v5.0.9 ?

@seydx see https://github.com/seydx/homebridge-camera-ui/issues/364 first it was broken and then fixed

@seydx see #364 first it was broken and then fixed

everything working now?

No - it was working in 5.0.7, not in 5.0.9 and fixed in 5.0.10 again.

@seydx Unfortunately not and I am not able to downgrade to 5.0.9 or below to test.

@seydx Unfortunately not and I am not able to downgrade to 5.0.9 or below to test.

v5.0.15-beta.1 is online, can you give it a try pls

I just found the error, somehow during one of the updates the config was modified and the wrong native ffmpeg was used instead of the homebridge one. I manually added again what solved it:
            "options": {
                "videoProcessor": "/usr/lib/node_modules/homebridge-camera-ui/node_modules/ffmpeg-for-homebridge/ffmpeg"
            },


validate infra configs in flutter/flutter

following steps in https://g3doc.corp.google.com/company/teams/flutter/release/workflows.md?cl=head to validate infra config. added a new line

We can ack Mac gradle_plugin_light_apk_test not running as it was removed from tip of tree

Thanks for the instructions! Does it sound right if I cherrypick the newest commit from blasten?(https://github.com/flutter/flutter/commit/b7a64b76fa7362e6985fe0e8e9f53766dc9d5153)

No, as we still want to run it in post-submit

No, as we still want to run it in post-submit
Thanks for the reply! I might be wrong since I still need to learn what are qualified as post submits, but I deleted the gradle_plugin_light_apk_test manually in a newest commit

Please revert https://github.com/flutter/flutter/pull/100108/commits/9596a315a2f7c90aac73d552838dbc2b6371ca96 as it's not necessary:

You're diverging the branch
We'll need to regenerate the flutter/infra configs

Once your flutter/engine PR lands, you'll need to update the pinned version with the merged commit. Other than that, this lgtm

See https://cs.opensource.google/flutter/flutter/+/master:bin/internal/engine.version

Any issues with this? You need to roll https://github.com/flutter/engine/pull/32025 in to be able to release it


1.2

This adds the ability to customise the potential model (currently we only support forcefields that take two variables). Also there is now less reliance on the compiled modules

This most recent push gets rid of the need for only 2 constants


Error:-17168 :: MBEDTLS_ERR_RSA_PRIVATE_FAILED

Hi,
We are using mbedTLS in our platform while connecting to AWS Cloud we are seeing error "-17168" (-0x4300-0x000A) RSA error.
[MBEDTLS_ERR_RSA_PRIVATE_FAILED + MBEDTLS_ERR_MPI_NEGATIVE_VALUE]
We are storing the certificates in const buffers and accessing them.
We are seeing this issue very often when we are power cycle the hardware (remove the power supply, and connect it), and rarely during the reset.
Please suggest me how to resolve this issue.

This error alone does not give enough information to determine where the error occurs.
The error itself indicates something is wrong (memory wise most likely.
Can you let us know / verify:

Does this also occur when connecting to other servers? (Is it AWS Cloud related?)
Can you provide a debug log (debug_level=5) to show the context of when the error happens?
What version of mbed TLS are you using?
Do you have  multi-threaded operation?

Our application is a multi-threaded one, latest version of mbedTLS we are using.
For testing I am starting other tasks after ssl success, we are not seeing this error. What is the dynamic  memory requirement during ssl connection?
mbedtls_ssl_handshake() is taking longer time to connect to server, its around 10 sec. No other tasks are running during this. How can we reduce this time.

Can you provide a debug log (debug_level=5) to show the context of when the error happens?

Hi pjbakker,
After allocating sufficient memory, the issue got resolved for us.
Do you have any timing statistics for the "mbedtls_ssl_handshake()" for connecting to a secure server (aws.amazon.com), how much time it is really taking.
For us it is taking around 15 seconds, but for a battery powered sleepy node it is considerably long. Is it possible to reduce this time by any means?

That's good to hear.
Timing statistics are dependent on a number of factors, such as Ciphersuite / Public Key mechanism used. Size of public key. mbed TLS compile time configuration. And of course on the performance of the relevant MCU.
So there is no generic answer.
Reducing time often requires: more memory consumption, smaller key sizes, or smarter ciphersuite choices.
I'll close this issue. For your question on performance I suggest you look into our KB articles, or ask on the discussion forum (while providing some additional information on your situation).

Hi,
we are using mbedTLS in our platform while connecting to AWS Cloud we are seeing error "-0x7200"
#define MBEDTLS_ERR_SSL_INVALID_RECORD                    -0x7200  /**< An invalid SSL record was received. */
followiing is the debug log:
ssl_tls.c:6313: => handshake
ssl_cli.c:3264: client state: 0
ssl_tls.c:2429: => flush output
ssl_tls.c:2441: <= flush output
ssl_cli.c:3264: client state: 1
ssl_tls.c:2429: => flush output
ssl_tls.c:2441: <= flush output
ssl_cli.c:0712: => write client hello
ssl_cli.c:0750: client hello, max version: [3:3]
ssl_cli.c:0759: dumping 'client hello, random bytes' (32 bytes)
ssl_cli.c:0759: 0000:  13 82 ef 31 b5 7d d7 d3 8a db 13 49 3b cb c0 32  ...1.}.....I;..2
ssl_cli.c:0759: 0010:  fb 32 93 27 0a a8 01 55 36 ae 6c bd ee ca 08 0a  .2.'...U6.l.....
ssl_cli.c:0812: client hello, session id len.: 0
ssl_cli.c:0813: dumping 'client hello, session id' (0 bytes)
ssl_cli.c:0880: client hello, add ciphersuite: 003d
ssl_cli.c:0880: client hello, add ciphersuite: 0035
ssl_cli.c:0880: client hello, add ciphersuite: 003c
ssl_cli.c:0880: client hello, add ciphersuite: 002f
ssl_cli.c:0880: client hello, add ciphersuite: 00b7
ssl_cli.c:0880: client hello, add ciphersuite: 0095
ssl_cli.c:0880: client hello, add ciphersuite: 00b6
ssl_cli.c:0880: client hello, add ciphersuite: 0094
ssl_cli.c:0913: client hello, got 9 ciphersuites
ssl_cli.c:0944: client hello, compress len.: 1
ssl_cli.c:0946: client hello, compress alg.: 0
ssl_cli.c:0072: client hello, adding server name extension: a2slq08v8uk221.iot.us-east-1.amazonaws.com
ssl_cli.c:0078: buffer too small
ssl_cli.c:0178: client hello, adding signature_algorithms extension
ssl_cli.c:0192: buffer too small
ssl_cli.c:1018: client hello, total extension length: 0
ssl_tls.c:2714: => write record
ssl_tls.c:2849: output record: msgtype = 22, version = [3:1], msglen = 61
ssl_tls.c:2852: dumping 'output record sent to network' (66 bytes)
ssl_tls.c:2852: 0000:  16 03 01 00 3d 01 00 00 39 03 03 13 82 ef 31 b5  ....=...9.....1.
ssl_tls.c:2852: 0010:  7d d7 d3 8a db 13 49 3b cb c0 32 fb 32 93 27 0a  }.....I;..2.2.'.
ssl_tls.c:2852: 0020:  a8 01 55 36 ae 6c bd ee ca 08 0a 00 00 12 00 3d  ..U6.l.........=
ssl_tls.c:2852: 0030:  00 35 00 3c 00 2f 00 b7 00 95 00 b6 00 94 00 ff  .5.<./..........
ssl_tls.c:2852: 0040:  01 00                                            ..
ssl_tls.c:2429: => flush output
ssl_tls.c:2448: message length: 66, out_left: 66
ssl_tls.c:2454: ssl->f_send() returned 66 (-0xffffffbe)
ssl_tls.c:2473: <= flush output
ssl_tls.c:2861: <= write record
ssl_cli.c:1044: <= write client hello
ssl_cli.c:3264: client state: 2
ssl_tls.c:2429: => flush output
ssl_tls.c:2441: <= flush output
ssl_cli.c:1396: => parse server hello
ssl_tls.c:3739: => read record
ssl_tls.c:2221: => fetch input
ssl_tls.c:2379: in_left: 0, nb_want: 5
ssl_tls.c:2403: in_left: 0, nb_want: 5
ssl_tls.c:2404: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
ssl_tls.c:2416: <= fetch input
ssl_tls.c:3486: dumping 'input record header' (5 bytes)
ssl_tls.c:3486: 0000:  16 03 03 0b e1                                   .....
ssl_tls.c:3495: input record: msgtype = 22, version = [3:3], msglen = 3041
ssl_tls.c:3532: bad message length
ssl_cli.c:1402: mbedtls_ssl_read_record() returned -29184 (-0x7200)
ssl_tls.c:6323: <= handshake

I am getting the same error as @NOA-Vernon. I will open this in a separate issue


Don't do whitelist inspections for java8 runtime standard apps

fixes #1368

Without <runtime>java8</runtime>:

With <runtime>java8</runtime>:


Bug with Open XML SDK

Describe the bug
A clear and concise description of what the bug is.
Screenshots
If applicable, add screenshots to help explain your problem.
To Reproduce
// Please add a self-contained, minimum viable repro of the issue.
// If you require external resources, please provide a gist or GitHub repro
// An Xunit style test is preferred, but a console application would work too.
Steps to reproduce the behavior:

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

Observed behavior
A clear and concise description of what you expected to happen.
Expected behavior
A clear and concise description of what you expected to happen.
Desktop (please complete the following information):

OS: [e.g. Windows]
Office version [e.g. 16.0.15427.20178]
.NET Target: (e.g. .NET Framework, .NET Core, UWP, Xamarin...)
DocumentFormat.OpenXml Version: (e.g. 2.11.0)

Additional context
Add any other context about the problem here.

@sukumara701 did you intend to add some notes here about a problem or bug? This is just the template. If this was just an accidental bug submission, we'll close it.

nothing actionable here, closing


Added a flag to support a single sampling of iTunes Connect status

In order to avoid hanging of the script, the pull request allow u to use --sample_only_once flag and watchbuild will sample iTunes Connect only once.
The previous behaviour (without the new flag) stay cool as it was :-}

Could you clarify on why this is useful and what you need it for?

Oh, so you just call watchbuild to see if the build is ready basically?

Yes, with this flag I don't wait to iTunes Connect to processing the build, it's like question-answer relationship :)
I use it n order to free my CI machine (the machine isn't stay in busy waiting so other builds can run).

Cool, I added some comments, however: how do you receive the return value? You don't provide an exit code, maybe that would be a nice thing :+1:

Thanks for the comments, I changed the code.
About the exit code, which exit code should return for:

Build still processing

Build finished processing

I didn't notice that watchbuild have some return value defines. Is it right?

The exit code is optional, thanks for updating the PR :+1: Have you tested this change locally for both use cases (build still processing and build already done)? If so, please squash the commits to one and let me know when you're ready :+1:

I squash alkl the changes, but the build didn't pass :/
Can u help with this?
https://circleci.com/gh/fastlane/fastlane/600

Sorry about that, could you rebase from master, squash the commits and see if that resolves the problem? We've had some problems with bundler on Circle, which should be resolved now :+1:

Hi (and Happy birthday @KrauseFx :),
Still same issue.
https://circleci.com/gh/fastlane/fastlane/600

Looks great, thanks @gran33 :+1:


feat: add shrinked target in linknet + dilation in postprocessing

Similarly to the DB, this PR includes a shrink of the polygons in the target and a dilation in the postprocessing of the linknet, to prevent boxes to be merged on the heatmap because their boundaries are too close.
After some experiments, this lead to much better results.
Any feedback is welcome!

I modified the typo, for the code duplicates there is only the polygon_to_box part in common, I suggest refactoring that in another PR


new stable tagged release

Hi!
would it be possible to make a new stable release and tag it? Currently there is just a 1.1alpha and before that a very old 1.0 version. We typically only use stable versions, unfortunately, in this case the 1.0 is broken (due to the data download not working, move from S3 to git I presume).
thanks a lot!

Any chance this could happen?

First of all, thanks for the great package.
Also thanks @MichaelMarien for the conda package.  It really simplifies the installation of libpostal.
A new tagged release really would be very helpful.
The upshot for the original package maintainers is that with a working conda package, most users on most platforms can simply be directed to do conda install -c conda-forge libpostal to get the package installed, which would hopefully significantly reduce the amount of support needed for users.

tag's changed to v1.1


Redfish DateTime Automation: Verify Set DateTime With Offset Using Redfish

To automate below test case

[x] Verify Set DateTime With Offset Using Redfish

@sivassrr @gkeishin
At present, it seems that redfish specifies iso does not support the function of automatically adding a day after more than 24 hours? Is this test item wrong? Because the date-time setting range is only 0-23


update Ops Manager and Elastic Runtime Versions

Updated Ops Manager and Elastic Runtime Versions.

Thank you, luckyj5


calling pylibdmtx.decode on certain images kills the Python process

Description
I have noticed that when attempting to decode a particular image (which does not contain a Datamatrix) that calling pylibdmtx.decode will kill the Python process with exit code 40.
Steps to reproduce
Run the following in a Python interpreter:
from PIL import Image
from pylibdmtx import pylibdmtx
pylibdmtx.decode(Image.open('bad_image.png'))

with the following image saved as bad_image.png in the current working directory;

System info
OS: Debian GNU/Linux testing (buster) x86_64
libdmtx version: 0.7.4 (installed from the Debian repositories and reported by apt info as 0.7.4-2+b1)
Python version: 3.6.0
pylibdmtx version:  0.1.7
PIL version: 5.0.0
Expected behavior
An error  should be raised, as the image does not contain a datamatrix
Observed Behavior
Python process exits with code 40
Additional information
While this is almost certainly a bug in the underlying libdmtx (I have already opened a bug report there), it is perhaps possible that this error could be caught before it hits libdmtx, which would allow us to work around the issue for the time being. I have not looked in to the root cause sufficiently deeply to be able to tell if this is possible.

Hi
I need to decode the numbers from a Datamatrix.
This is my code
import cv2
from pylibdmtx.pylibdmtx import decode
a = decode(cv2.imread(suganth.jpg'))
when trying to print using print(a), it gives me an empty matrix.
I couldn't understand the decode function.
Can you help me in decoding any Datamatrix in numbers?

@ondraga this is not the correct place to ask general questions about using pylibdmtx. Please remove your comment and ask through a more appropriate channel.

This has been fixed upstream by https://github.com/dmtx/libdmtx/pull/17, which will be included into the upstream v0.7.6 release.

So I'll close the issue here.

This has been fixed upstream by dmtx/libdmtx#17, which will be included into the upstream v0.7.6 release.

0.7.6 hasn't been released yet? Or before the next release, how can we handle this issue?

Sorry for long reaction.
I just pushed 0.7.7 tag, so it can be taken by downstream maintainers to build packaged versions.


Github Workflow Failing at Azure login

While deploying the pipeline I am getting below error.

I'm not sure why I'm encountering this issue. Any help or guidance would be greatly appreciated.
Here is my work flow:

Hi @Logeswari25, please follow this example:
  - uses: azure/login@v2
    with:
      creds: '{"clientId":"${{ secrets.AZURE_CLIENT_ID }}","clientSecret":"${{ secrets.AZURE_CLIENT_SECRET }}","subscriptionId":"${{ secrets.AZURE_SUBSCRIPTION_ID }}","tenantId":"${{ secrets.AZURE_TENANT_ID }}"}'

And please consider using OIDC instead of SP+secret. Check here.

Same error pops up when using OIDC. Seems like an Az.Accounts problem

I also encountered the same error.
https://www.powershellgallery.com/packages/Az.Accounts/3.0.0
Recently, the version of Az.Account has been increased.
I think this is the effect.

Hi @k3-yasuda
could you please try below commands with the latest Az.Accounts to see if any errors are thrown?
$psLoginSecrets = ConvertTo-SecureString '<clientSecret>' -AsPlainText -Force
$psLoginCredential = New-Object System.Management.Automation.PSCredential('<clientId>', $psLoginSecrets)
Connect-AzAccount -ServicePrincipal -Environment 'azurecloud' -Tenant '<clientId>' -Subscription '<subscriptionId>' -Credential $psLoginCredential

We are encountering the same error across many GH action workflows trying to login to Azure (azure/login@v1). These builds were working yesterday.
Attempting Azure PowerShell login by using service principal with secret...
Error: Login failed with SyntaxError: Unexpected token R in JSON at position 0. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.

With @v2 we are seeing some more info:
Login failed with SyntaxError: Unexpected token 'R', "Retrieving"... is not valid JSON. Double check if the 'auth-type' is correct.
Maybe we are not following redirects?

We are also facing same issue Azure login with few gihub action step but some of the steps executed successfully. Please find below logs of both the execution (failed and sucessfull)
------------Failed Logs ---------------
Run azure/login@v2
Running Azure CLI Login.
/usr/bin/az cloud set -n azurecloud
Done setting cloud: "azurecloud"
Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*******/-azure-bicep:environment:
Attempting Azure CLI login by using OIDC...
Subscription is set successfully.
Azure CLI login succeeds by using OIDC.
Running Azure PowerShell Login.

### Result: '/home/runner/.local/share/powershell/Modules/Az.Accounts/3.0.0/Az.Accounts.psd1',
Success: true

Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*******/-azure-bicep:environment:cu8
Attempting Azure PowerShell login by using OIDC...
Error: Login failed with SyntaxError: Unexpected token 'R', "Retrieving"... is not valid JSON. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.
------------ Successful Logs ---------------
Run azure/login@v2
Running Azure CLI Login.
/usr/bin/az cloud set -n azurecloud
Done setting cloud: "azurecloud"
Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*********/-azure-bicep:environment:**
Attempting Azure CLI login by using OIDC...
Subscription is set successfully.
Azure CLI login succeeds by using OIDC.
Running Azure PowerShell Login.

Result: '/usr/share/az_11.3.1/Az.Accounts/2.19.0/Az.Accounts.psd1',
Success: true

Federated token details:
issuer - https://token.actions.githubusercontent.com
subject claim - repo:*******************/**-azure-bicep:environment:
Attempting Azure PowerShell login by using OIDC...
*** Success: true, Result: '' ***
Running Azure PowerShell Login successfully.

Login failed with SyntaxError: Unexpected token 'R', "Retrieving"... is not valid JSON. Double check if the 'auth-type' is correct.
we are seeing same issue as above, Most of our critical workflows are failing. Is anyone working to resolve this ?

I am using "ubuntu-latest" and have one workflow that is running into this issue.  Any other ideas on how to address this?

Can confirm this issue with a high number of affected workflows.
Why is this issue still not fixed and why are Az PowerShell modules not tested before they are released?

We are also seeing issues, and my self-hosted runners have not been updated to Az.Accounts yet.  Still using 2.19.0 and I am getting this issue.

Would this have something to do with the issue.
https://learn.microsoft.com/en-us/powershell/azure/release-notes-azureps?view=azps-11.6.0
Important
Preannouncement: The default interactive login experience will change from browser based to Web Account Manager (WAM) based on supported platforms, learn more. Only interactive login flow is influeced by WAM. This will take effect from the release of May 21st.

@sentara-cshannah
But these are all non-interactive logins, so either azure/login is doing something wrong or Az.Accounts is broken.
it seems that azure/login is searching for the latest version of Az.Accounts, so make sure that you only have 2.19.0 installed.

Workaround: The issue is caused by Az.Accounts PS module. We had latest (3.0.0) installed on our self-hosted github runners and this was causing a problem. I've realized the azure/login github action works fine on managed (ubuntu-latest) runners where Az.Account ver. 2.19.0 is installed. Downgrading the version solves the issue.

@sentara-cshannah - Can you detail how you instruct your Runner to use a specific version of said dependency? Is that something you prescribe in the .yml somewhere?

@mblaschke-daimlertruck , your right, my eyes glossed over the interactive part.  I just confirmed that 3.0.0 is on my runner, though I wondering how it got installed since the image this runner is build on is a week or so old.  Does the Azure/login action update that?   And if so I also and curious how we role back and stay roled back.

By installing an older version of Az module you will end up installing Az.Accounts 3.0.0 because the dependency is defined as Az.Accounts (>= 2.19.0)
see https://www.powershellgallery.com/packages/Az/11.6.0
Workaround after installing Az module:
Uninstall-Module -Name Az.Accounts
Install-Module -Name Az.Accounts -RequiredVersion 2.19.0

yeah no good for me.  I removed 3.0.0 and reran my job.  1st login worked fine, 2nd login failed same error.  And it looks like it re-downloaded 3.0.0

@sentara-cshannah
I would recommend ephemeral runners, so throw them away after each job.
If you're running a Kubernetes cluster it's worth looking at https://github.com/actions/actions-runner-controller

@mblaschke-daimlertruck  thanks for the advice, I'd add it to my backlog. :)

Same issue, although I only see it in a workflow triggered by workflow_call.

Okay, I can confirm that rolling back to 2.x allows login to work again.  However, anytime I load another Az module with a dependency on Az.Accounts, even if I specify a very old version of it, the version of Az.Accounts is bumped to 3.0.0 again.  I've identified several scenarios now that bump the version of Az.Accounts silently and were preventing workarounds from working for us until now.  I'm appalled by this kind of behavior, but thankfully I'm not responsible for powershell supply-chain attack security.

Hi all,
It's caused by the upgrade of Az.Accounts to version 3.0.0.
Here is the workaround of this issue.
Please update the below line in your workflow file
uses: azure/login@v1

or
uses: azure/login@v2

to
uses: azure/login@hf_447_release

We'll prepare a new release to fix this issue.
Sorry for your inconvenience and thanks for your patience!

Thank you, testing it now.

I just tested the workaround release on a test workflow that was impacted by this issue, and it worked.

Above workaround has worked for me. Thank you.

Above workaround has also worked for me. Thank You.

Working for me as well. Thank you

we are also facing the same issue, After changing the azure/login@v2 with azure/login@hf_447_release issue fixed, Thank you @YanaXu for the quick fix on this

azure/login@hf_447_release has fixed our login issues as well! thanks for the quick turn around on this!

I have an instance where the downgrade to a previous release allows the login, but the next step has a dependency on Az.Account 3.0.0
Ultimately this makes it a blocker for other stations where there are other Microsoft owned actions that require the newer version of Az.Accounts
Note mostly to accommodate those of us that can't leverage the login work-around because we are contingent on other pieces of the workflow that need to have the upgraded dependency. In my situation, my subsequent action is the Enterprise Policy as Code action process to plan/deploy policy from a repository. I assume this won't be the only situation where this will be problematic, but it's my current block for testing new policies in the environments that I need to deploy to.

@YanaXu azure/login@hf_447_release worked for us. Please keep us posted when the release version is available on marketplace with this fix.

@YanaXu azure/login@hf_447_release worked for us. Please keep us posted when the release version is available on marketplace with this fix.

I'd subscribe for updates to the pull request to see when it's merged. I assume an immediate fix release is created once it's merged. https://github.com/Azure/login/pull/448

I have an instance where the downgrade to a previous release allows the login, but the next step has a dependency on Az.Accounts 3.0.0
Ultimately this makes it a blocker for other stations where there are other Microsoft owned actions that require the newer version of Az.Accounts
Note mostly to accommodate those of us that can't leverage the login work-around because we are contingent on other pieces of the workflow that need to have the upgraded dependency. In my situation, my subsequent action is the Enterprise Policy as Code action process to plan/deploy policy from a repository. I assume this won't be the only situation where this will be problematic, but it's my current block for testing new policies in the environments that I need to deploy to.

Hi @crypticraven, correct me if I'm wrong.

Your workflow file depends on Az.Accounts 3.0.0 which means downgrade of Az.Accounts is not OK for your situation.
Your workflow file has policy check which will disallow you to use the workaround azure/login@hf_447_release.

If yes to both the questions, the only workaround is login with Azure PowerShell directly instead of Azure Login Action.
You can check my example here for OIDC login with Azure PowerShell in GitHub Action.

immediate fix release

Hi @brendanlafond and @apalich , I'm planing the release but it will take some time. I'll update the status of the fix release in this issue and keep you all posted.

I have the  same issue, i think  i could solve it by using OIDC, but still gives the same issue. I aint know how to go on.

* Your workflow file depends on `Az.Accounts 3.0.0` which means downgrade of Az.Accounts is not OK for your situation.

No, there are other PowerShell modules that rely on Az.Accounts 3.0.0 that are used later in my action workflow. I tried downgrading to a version that didn't require Az.Accounts 3.0.0 and it allowed the login to be successful without an error. The Enterprise Policy-as-Code module relies on newer versions of the Az module as a whole.

* Your workflow file has policy check which will disallow you to use the workaround `azure/login@hf_447_release`.

I don't have a policy check process in my workflow. I don't want to limit use of this because it makes work-arounds harder to implement later. I was hoping to spread the message that downgrading may not be an option for everyone if there are other parts of the workflow process that need the updated components. This error currently prevents me from being able to manage Azure Policy (this is something I need to do every day). I acknowledge that I may be a minority here. I will be patiently waiting for the next release in hopes that it will resolve the issues presented today in the workflow.

We are explicitly downgrading Az.Accounts to 2.19 before the azure/login action, and then installing/importing modules as needed after that, since any such action auto-updates Az.Accounts to 3.0.0.  We haven't found a way to pin versions to prevent this behavior, which is a significant risk to our supply chain controls.  Using a non-release version of the action in our production environment would take longer to get approval for, assuming our Risk dept allowed it through.
We're disturbed that the action was not tested against new api releases (is this a potential problem with every update of the pwsh modules?) and that we don't have adequate control over versioning (there's going to be a lot of discussion with our package management server team).

@YanaXu @crypticraven
I've confirmed that the workaround for EPAC of explicitly getting the token and running connect-azaccount works. However, if you're using the something similar to the standard EPAC workflows from the starter kit, you will need to explicitly install az.accounts so it gets the correct version. Otherwise, it'll still throw the same error about needing 3.0.0, even though it clearly shows 3.0.0 is being installed.
It's annoying and doesn't make sense, but it works. It also doesn't make sense, because the code for the EPAC module specifically calls out needing v2.19.0... But whatever. It works.

Hi @Logeswari25, @k3-yasuda, @svenski, @kornel-lugosi-lab49, @Abhijitk914, @sandeep5234, @ealasgarov, @joannewilsonRel, @paulanguiano, @mblaschke-daimlertruck, @sentara-cshannah, @tim-chaffin , @DanielTillmannTR, @VillaDaniele, @haflidif, @wesco-prathapmotupalli, @crypticraven, @apalich, @brendanlafond, @wangrandk,
The fix is released in v2.1.1 and v2 is agligned with v2.1.1.
Please try
uses: azure/login@v2

or
uses<EMAIL_ADDRESS>
in your workflow file.
Feel free to create an issue in this repo if you met any problems. Thanks!

We are explicitly downgrading Az.Accounts to 2.19 before the azure/login action, and then installing/importing modules as needed after that, since any such action auto-updates Az.Accounts to 3.0.0. We haven't found a way to pin versions to prevent this behavior, which is a significant risk to our supply chain controls. Using a non-release version of the action in our production environment would take longer to get approval for, assuming our Risk dept allowed it through.
We're disturbed that the action was not tested against new api releases (is this a potential problem with every update of the pwsh modules?) and that we don't have adequate control over versioning (there's going to be a lot of discussion with our package management server team).

Hi @paulanguiano,
I fully understand your ask, which is caused by the current implementation mechanism. Whenever a new version of Az.Accounts is released, the GitHub Action runner will automatically use it. In rare cases, it will cause incompatibility issues with Azure Login Action. But this situation is indeed very rare, and both from the perspective of Azure Login Action and Azure PowerShell, we are trying to avoid this kind of thing. But in the unlikely event that it does happen, just like this issue, we will fix it as quickly as possible at all levels. No worries. In the future, we will also look at areas that can be improved in the entire workflow to improve the stability of everyone's workflow.

ing v2.19.0... But whatever

Hi @camfarris,
I think you're talking about another thing. Could you please open a new issue for this? We'd like to keep one issue for one topic.  Thanks.

Hi,
I have tested a workflow both with v2 and v2.1.1 (in different runs) and it worked as intended with both versions.

Whenever a new version of Az.Accounts is released, the GitHub Action runner will automatically use it. In rare cases, it will cause incompatibility issues with Azure Login Action. But this situation is indeed very rare, and both from the perspective of Azure Login Action and Azure PowerShell, we are trying to avoid this kind of thing. But in the unlikely event that it does happen, just like this issue, we will fix it as quickly as possible at all levels. No worries. In the future, we will also look at areas that can be improved in the entire workflow to improve the stability of everyone's workflow.

I was using v1 and everything suddenly stopped working. I had to hunt down this GitHub post to figure out what went wrong and how to fix it by updating the azure/login part in our setup. This was a surprise for folks who've been using the same setup for a long time without any issues. The thing is, if I choose to upgrade to the new version and it doesn't work, I should be able to just go back to the old version and have it work like before. But this time, nothing was changed and still, everything broke. I get that you guys can fix things fast when there's a problem, but we really need to make sure old setups don't get messed up when new things come out. Could we do something about that? Thanks.

Whenever a new version of Az.Accounts is released, the GitHub Action runner will automatically use it. In rare cases, it will cause incompatibility issues with Azure Login Action. But this situation is indeed very rare, and both from the perspective of Azure Login Action and Azure PowerShell, we are trying to avoid this kind of thing. But in the unlikely event that it does happen, just like this issue, we will fix it as quickly as possible at all levels. No worries. In the future, we will also look at areas that can be improved in the entire workflow to improve the stability of everyone's workflow.

I was using v1 and everything suddenly stopped working. I had to hunt down this GitHub post to figure out what went wrong and how to fix it by updating the azure/login part in our setup. This was a surprise for folks who've been using the same setup for a long time without any issues. The thing is, if I choose to upgrade to the new version and it doesn't work, I should be able to just go back to the old version and have it work like before. But this time, nothing was changed and still, everything broke. I get that you guys can fix things fast when there's a problem, but we really need to make sure old setups don't get messed up when new things come out. Could we do something about that? Thanks.

Hi @FreddyAyala , sorry for your bad experience. Most of the time, the issues are introduced by Login Action itself and downgrade/upgrade of the action version works. But in rare cases, the action itself does not change but it may have compatibility issues with the platform it works with. In this case, downgrade/upgrade of the action version will not work. We are aware of this kind of problems and are continuously working on improving it. Feel free to open issues whenever you find an error or want to provide suggestions. Thanks.

It seems there still is a problem. We are encountering this error with 2.1.1
Error: Login failed with SyntaxError: Expected double-quoted property name in JSON at position 240. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information.

Just started using GitHub Actions today - and followed this example exactly including the workflow
https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-secret
Received the same error as @larsmaes-sogeti
[error]Login failed with SyntaxError: Expected double-quoted property name in JSON at position 240. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information
Not a great start is it! And it's August now - what is the fix?

Just started using GitHub Actions today - and followed this example exactly including the workflow
https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure-secret
Received the same error as @larsmaes-sogeti
[error]Login failed with SyntaxError: Expected double-quoted property name in JSON at position 240. Double check if the 'auth-type' is correct. Refer to https://github.com/Azure/login#readme for more information
Not a great start is it! And it's August now - what is the fix?
Using<EMAIL_ADDRESS>does not work either

Hi @neilmca-inc , it's a closed issue with fix. I don't think it's your case. Please open a new issue for your case. Provide your secrets.AZURE_CREDENTIALS value (mask the json property values) in the new issue. I think you may put a wrong json value in the GitHub secrets.

Thanks @YanaXu
I've fixed this now @larsmaes-sogeti  - the official documentation contains invalid JSON ! There is a comma at the end of the last line

Thanks @neilmca-inc ! We'll see if we can update it.


Missing Import

In powerdnsadmin/models/user.py:
import pyotp
is missing.
ERROR in app: Exception on /login [POST] Traceback (most recent call last): ... powerdnsadmin/models/user.py", line 86, in verify_totp     def verify_totp(self, token): NameError: name 'pyotp' is not defined

Nice catch! I missed it in the code refactoring. Fixed it with the above commit.

@ngoduykhanh user.py is also missing an import traceback.

Added it. Thanks @nfantone


Add PowerPC support for GCC and XLC

This is a big addition... track it.

Cleared at Commit 4e70020f96a4.


SUNDIALS feature request

Hi,
I see @gardner48 is rewriting the sundials interface for Sundials 4/5 compatability.
Currently there's no way to invoke KINSetMAA (enabling Anderson acceleration for KIN_FP/KIN_PICARD) through the MFEM interface. If it's all being rewritten anyway, I won't make a pr against master to enable this (it's a few lines as far as I can tell).
Also -- my current method of using the picard solver interface involves a bit of a hack to provide a linear operator (and just make 'GetGradient' a no-op). The interface in MFEM for providing a linear operator is quite tailored to the newton method. If using one with KIN_PICARD could be streamlined/documented in the next iteration of the interface that would be fantastic.
Happy to code these and provide a patch once the new interface is merged,
Thanks for all the great work on this library!
Ian

@gardner48, can you comment on @ianabel's questions?

@ianabel I'll add a wrapper for KINSetMAA in the new Sundials interface (you're right that this will only take a couple of lines to do). In the mean time you can use the SundialsMem method to get the KINSOL memory structure and call KINSetMAA directly.
The KINSOL interface was written with a focus on using Newton's method and I've followed this design in the new interface but I'll take a look at making it easier to use the Picard solver. What's your current hack for providing the linear operator?

So, you can't just call KINSetMAA on the object directly, as the KINSOL interface specifies that SetMAA should be called between SetMaxIters and KinInit() so you want to call it inside SetOperator(). I am using a patched branch anyway, so I've patched the old interface.
As for KIN_PICARD, I had a strange hack set up along the following lines, but it doesn't work now. I'm surprised it ever did to be honest:
I'm feeding a Solver object to KinSolver::SetSolver that has a dummy SetOperator method, which does nothing, and my nonlinear Operator object has 'GetGradient' return a dummy Operator object so KinSolver sets its internal jacobian pointer to the dummy object and then doesn't use it.
I also added a check in LinSysSolve so if we're doing Picard iterations then we just return instead of trying to calculate norms.
It looks like a little more work to get this working perhaps. Certainly the KINSOL interface will just interpret the linear operator it is given as the one to use in the picard iterations.
As an alternative, i'm just doing fixed point iterations and directly applying the linear inversion myself.

One more query.  For the new interface, where a linear solver is required (both for newton and Picard), is there a more appropriate class in mfem than Solver? As far as I have discerned, Solver encapsulates the concept of a solver that can solve a generic linear problem. However, when interfacing with KINSOL, we are expected to pass a solver that solves only the specific problem at hand (be it muliplication by the inverse Jacobian, or inversion of the linear part of the nonlinear operator in a Picard inversion).
I'm not sure what class would be more appropriate however. Perhaps 'Operator' or something that can return an Operator reference when you set the point at which you want the Jacobian inverted?
I may be completely off-base, and this may be too awkward within the existing mfem class hierarchy, which i'm only gradually getting to grips with.

@gardner48 and @ianabel -- can we close this or is there an outstanding action item for SUNDIALS and/or MFEM?

Now that Sundials 5.0.0 has been officially released, I'll test this interface out and close the bug hopefully.

Well, given that the new sundials interface doesn't compile without MPI, we can't close this :)
@gardner48 -- there is some initialization done inside if(Parallel()) { .. } blocks that refers to MPI functions without being inside #ifdef MFEM_MPI. I guess most sundials builds will use MPI, and my test rig is a little odd.

Thanks for pointing this out -- I guess we forgot to check the serial build + SUNDIALS -- I'll make a PR to fix this.

Good catch, we will have to add serial+SUNDIALS to our testing suite.

@ianabel -- can you check if #1147 with SUNDIALS 5.0 works for you?

Compiles and the KINSolver class works well.
However, there seems to be a bug in the Anderson Acceleration. Don't know if it's in the interface or sundials itself.
I think we should close this bug and if I can produce a nice minimal test case, I'll raise a new bug.

OK, so it's a quirk of the Anderson Acceleration algorithm itself, and the SUNDIALS implementation is at worst mildly non-robust. :)
I'll bring this up with the KINSol team, and close this.