Expansion of constructor for Validate in IFileValidator

Description
In my app, I extract data from excel attachment that user has uploaded and validate certain data against modeldata/data.
Could you expand constructor for Validate method in IFileValidator to include data.

Additional Information
No response

I don't think it would make much sense to always fetch the current data model to run file validators, and when we start supporting multiple data models in the same task, it is unclear what data element we should fetch anyway.
The correct approach would be to use IDataClient instead, and just fetch the relevant data you need. Unfortunately the interface does not give you a reference to the Instance the user uploads to, so currently you would need to use IHttpContextAccessor to get the request url, and parse the instance and data guids from there.
Do you like the separation between IFileAnalyzer and IFileValidator, where you need to implement both, or would it be better to just have a single interface with no intermediate FileAnalysisResult?

Hmm... Didn't think of that before. Let me test og come back on it if it works.
No, I do like the separation of FileAnalyse and FileValidator. The code is more clear and follows the single responsibility principle.

What is the use case where you need to get the data in addition to the results from the analyzer?
The original thought behind the IFileAnalyzer and IFileValidator separation was to:

Avoid coupling of the two as they have different responsibilities and in some cases you don't want to validate against the file, just analyze it and read out some values to put in the data model.
Being able to run multiple analyzers in sequence and use the combined result for validation. Although this might something that seemed like a good idea in my head at the time:)

This schema is a schema that FT instantiate and dump in the users inbox. The app itself is quite simple, containing information about the report-periode and reportee information. The actual report is this excel-file that they have to attach to the instans (template from this page: excel-template.
We need to do some controll that the excel-file that they are uploading are correct, such as excel-file-versjon number , report periode in excel matches the report periode in datamodel and other controll that the reportee information in excel matches the one that is actual reporting.

Closing this as the IDataClient can be injected and used to fetch data on the instance.


Handle applyReplayProtection in RecvPacketV2

Summary
applyReplayProtection is temporarily commented out in RecvPacketV2.
This needs to be uncommented (which would require duplicate V2 functions to be added). Or we can wait until we fully use PacketV2 internally.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged/assigned
[ ] Estimate provided

Obsolete! (Replay protection currently exists https://github.com/cosmos/ibc-go/blob/2ca28242fb9354aa0612e763dfabdd8d803a9cb9/modules/core/04-channel/v2/keeper/packet.go#L125)


Lanelet2 pip wheel incompatible with GLIBC_2.28

The pypi wheel currently requires GLIBC_2.29 and auditwheel is not able to "repair" it to 2_28 if changed here:
https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/11e83fdd208e06fe1131cbf5aeaea7586a3d0a99/.github/workflows/cd.yaml#L73
Workable solution is a conan build as in https://github.com/jdrudolph/Lanelet2/blob/bb64b1a118c428c759cf86d7a48d58a5466fe4cc/Dockerfile_conan_cp38

And what exactly is the issue?

Hi,
The issue here is that current pip wheel is hard-coded to the glibc2.31 version. That means that if your system has an earlier version of glibc, the pip installation will not work (because of missing pip tags). Simply downloading and renaming the wheel file will allow for installation, but you would still require at least glibc2.29 version to run lanelet2. So if your system has glibc2.28 or earlier, the current wheel does not work. Either it is required to update glibc version or a workaround it is a conan build.

What I meant was: What is the original issue. I know we don't support older libc versions (and others) but which linux distributions are actually affected by this?

Hi,
The affected linux distributions that I am definitely aware are RedHat Linux versions 8.7 and below.
https://distrowatch.com/table.php?distribution=redhat
According to distrowatch, Ubuntu versions below 18.10 would be affected as well.
https://distrowatch.com/table.php?distribution=ubuntu


Manage & update Xcode installations

https://github.com/fastlane/ci/blob/master/docs/use_cases/update_xcode_installation.md

This could potentially be moved to the 1.0 milestone, however I think it should still be aimed for for Beta


OSSM-2203: adds dep update script

Sharing the script I used for aligning dependencies between istio/istio and this project.
The script takes into account replace and exclude directive from the upstream go.mod and modifies go.{mod,sum} as a result.

@jwendell as release-1.16 is a moving target we could think about setting up the job which would run this script periodically. WDYT?

Move it to a tools or bin directory rather than hack.

@jwendell following this reasoning shouldn't we move other scripts too? I thought the hack folder is for all kinds of scripts. At least that's what it is for in k8s projects IIRC.

Do you plan to have a cron (daily?) job on prow that runs this script periodically? Or the idea is to run it manually every time we will sync with upstream?

Do you mind to leave some general comments along the code ? So that we can understand what the code does more easily

@jwendell I added some in the not-so-obvious part of the code. Also --help explains what is going on.

Do you plan to have a cron (daily?) job on prow that runs this script periodically? Or the idea is to run it manually every time we will sync with upstream?

I was thinking to run it periodically to keep deps updated with the upstream branch we branched out from originally (in this case release-1.16). WDYT?
As we don't have it in place yet I opened another PR with new updates - #32

I was thinking to run it periodically to keep deps updated with the upstream branch we branched out from originally (in this case release-1.16). WDYT?

In that case you need to create a periodic job in prow. No rush though.


Change read_tmy3 parameter input order

[x] I am familiar with the contributing guidelines
[x] New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
[x] Pull request is nearly complete and ready for detailed review.
[x] Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Based on this https://github.com/pvlib/pvlib-python/pull/1779#discussion_r1243756573, it seems there is consensus that the map_variable parameter should be the last or second to last input parameters. This PR updates this for the read_tmy3 function (variable mapping of read_tmy3 has yet to be officially released, hence this PR is not a breaking change).

I think it might make sense for technical mumbo-jumbo parameters like url and encoding to always be at the end of the parameter list.  They aren't really "features" per se, they're just annoying "make it work" buttons that one resorts to using when something external to pvlib forces your hand.


Implement Search

Fixes #13
Basic implementation of the search functionality.
https://user-images.githubusercontent.com/34120932/121346345-9f726c00-c943-11eb-8172-db3add29bec2.mp4

LGTM
@sharmaaditya570191  can you check the functionality once?

everything else looks good


fix the preload headers for crossorigin requests

To fix the double requests when things are changed dynamically though requirejs hooks

Codecov Report

Merging #130 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #130      +/-   ##
==========================================
+ Coverage   92.24%   92.32%   +0.07%
==========================================
  Files          13       13
  Lines         503      508       +5
  Branches       89       90       +1
==========================================
+ Hits          464      469       +5
  Misses         39       39

Impacted Files
Coverage Δ

lib/request-handler.js
97% <100%> (+0.15%)
:white_check_mark:

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 5919006...be6a55e. Read the comment docs.


Ponyc seg faults in exhaustive match code gen

Latest master on MacOS 10.12.5.
Ponyc 0.14.0-a5ed8aa0 [release]
compiled with: llvm 3.9.1 -- Apple LLVM version 8.1.0 (clang-802.0.42)
The code demonstrating the problem is in the cli package in PR https://github.com/ponylang/ponyc/pull/1897 , source command_spec.pony lines 158-160 and 272-274
Building either of these 3-line workaround sections removed causes a segmentation fault during the Generating phase of ponyc.
The output I see is:
ponyc -V=4
Building builtin -> /Users/carl/ws/pony/cquinn/ponyc/packages/builtin
Building . -> /Users/carl/ws/pony/cquinn/ponyc/packages/cli
Building collections -> /Users/carl/ws/pony/cquinn/ponyc/packages/collections
Building ponytest -> /Users/carl/ws/pony/cquinn/ponyc/packages/ponytest
Building time -> /Users/carl/ws/pony/cquinn/ponyc/packages/time
Building buffered -> /Users/carl/ws/pony/cquinn/ponyc/packages/buffered
Generating
 Reachability
 Selector painting
 Data prototypes
 Data types
 Function prototypes
 Functions
Segmentation fault: 11

I will try to put together a smaller repro case, but in the meantime, I wanted to get an Issue in place to track it.

Here is a smaller repro case:
type Union is (Bool | String)

class val X
  new val bool(default': (Bool | None) = None) =>
    let u =
      match default'
      | None => None
      | let d: Union => d
      //else
        // Ponyc issue: else can't happen, but segfaults without it
        //None
      end

actor Main
  new create(env: Env) =>
    X.bool()

This (at least the reduced example) appears to be fixed as of pull https://github.com/ponylang/ponyc/pull/2049

@cquinn can you confirm?

Yes, this fixes the problem found in cli/command_spec.pony.


[flash_ctrl] Add flash invalid operation test

Add flash invalid operation test. Check that invalid operation
does not affect content of memory. Check all partitions.
Signed-off-by: Nikola Miladinovic<EMAIL_ADDRESS>

@jdonjdon Could you please retrigger CI private checks since I also do not have access to Azure?

@jdonjdon Could you please retrigger CI private checks since I also do not have access to Azure?

done

@jdonjdon Could you please retrigger CI private checks since I also do not have access to Azure?

done

Thanks! Now it is ready to be merged.


[WIP] convert jwt test into multicluster supported

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[X] Does not have any changes that may affect Istio users.

/test integ-security-multicluster-tests_istio

/test integ-security-multicluster-tests_istio

/test integ-security-multicluster-tests_istio

@jtrbs: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-multicluster-k8s-tests_istio
1d06b07e04c20389a9423c586801f169682036be
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-multicluster-k8s-tests_istio

/test integ-security-multicluster-tests_istio

/test integ-security-multicluster-tests_istio

@jtrbs: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
74512a914622f3135db8d9f3419ffccbf8955724
link
/test integ-pilot-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-security-multicluster-tests_istio

/retest

Test passed at https://prow.istio.io/view/gs/istio-prow/pr-logs/pull/istio_istio/28444/integ-security-multicluster-tests_istio/1322333520789508096

/test integ-security-multicluster-tests_istio

/test integ-security-multicluster-tests_istio

integ-security-multicluster-tests_istio passed at https://prow.istio.io/view/gs/istio-prow/pr-logs/pull/istio_istio/28444/integ-security-multicluster-tests_istio/1323325625913577472

looks good to me

/cherrypick release-1.8

@jtrbs: #28444 failed to apply on top of branch "release-1.8":
Applying: convert jwt test into multicluster supported
Using index info to reconstruct a base tree...
A	tests/integration/security/file_mounted_certs/main_test.go
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): tests/integration/security/file_mounted_certs/main_test.go deleted in HEAD and modified in convert jwt test into multicluster supported. Version convert jwt test into multicluster supported of tests/integration/security/file_mounted_certs/main_test.go left in tree.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 convert jwt test into multicluster supported
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherrypick release-1.8

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@jtrbs: new issue created for failed cherrypick: #28972

In response to this:

/cherrypick release-1.8

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


[BUG] Azure.ResourceManager 1.0.0-beta.3: DeploymentProperties has incorrect documentation

Describe the bug
The documentation of Azure.ResourceManager.Resources.Models.DeploymentProperties is incorrect. It states that the Template and Properties values should be either strings or JObjects, but neither is true (technically it can be a string, but that gets sent down the wire to the ARM backend as a JSON-encoded string, which is incorrect). It must actually be a Dictionary<string, object> (where the object values are also Dictionary<string, object> or JsonElement) or JsonElement.
Expected behavior
props.Template = File.ReadAllText("mytemplate.json");
props.Parameters = File.ReadAllText("myparams.json"); // or JsonSerializer.Serialize(myCustomParamsObject)

Actual behavior (include Exception or Stack Trace)
Upon issuing a CreateOrUpdateAsync when using string parameters, you will get an error similar to:
Unhandled exception. Azure.RequestFailedException: The request content was invalid and could not be deserialized: 'Error converting value "{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
...
}" to type 'Azure.Deployments.Core.Definitions.Schema.Template'. Path 'properties.template', line 1, position 4644.'

Similarly, when passing an arbitrary System.Text.Json-serializable object, you will get a System.NotSupportedException.
To Reproduce
Steps to reproduce the behavior (include a code snippet, screenshot, or any additional information that might help us reproduce the issue)

See above

Environment:

Name and version of the Library package used: Azure.ResourceManager.Resources 1.0.0-beta.3
Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): Windows 11 22489, .NET 6.0.11-rc SDK
IDE and version : Visual Studio 2022 preview 7

There were previous similar issues reported about the old Microsoft.Azure.Management.Resources SDK, but most were closed or irrelevant to the new packages. As far as I can tell, this code and documentation is generated with Autorest, so the backing swagger/cadl definitions may need to change to fix this.
But, since this was also a rough experience in previous versions of the SDK -- is there any way we can get a hand-written layer on top of this code that is more strongly typed? For instance, I am envisioning the SDK could provide the following class for parameters:
public class DeploymentParameterValue : IUtf8JsonSerializable
{
    public string Name { get; set; }
    public object Value { get; set; }
}
public class DeploymentParameterKeyVaultReference : IUtf8JsonSerializable
{
    public string Name { get; set; }
    public ResourceIdenfitier KeyVaultId { get; set; }
    public string SecretName { get; set; }
}
public class DeploymentParameters : IUtf8JsonSerializable
{
    public IList<DeploymentParameterValue> Values { get; }
    public IList<DeploymentParameterKeyVaultReference> KeyVaultReferences { get; }
}

This way, for people generating custom parameters (like our team), we wouldn't need to implement our own serialization logic to mimic the parameter file syntax (which is cumbersome for normal "myparam": { "value": "myvalue" } but even more cumbersome for key vault references)

I have reproduced the error using string on template or parameters to create a deployment. Since the descriptions come directly from swagger doc, I created a issue on swagger repo to track this problem: https://github.com/Azure/azure-rest-api-specs/issues/16759.
For JObject, could you @jackhorton please elaborate what specific object you used that caused this error, because "System.Text.Json-serializable object" seems general. Appreciate it if you can provider some code examples.

By "System.Text.Json-serializable object", I just meant any normal POCO: For example:
// For instance, if we are crafting our own parameters file in C#, we may like to pass an object in
// that would serialize down to a parameters file (where you get "paramName": { "value": "paramValue" })
JsonSerializer.Serialize(new { Foo = new { value = 1 } }); // works
deploymentProperties.Parameters = new { Foo = new { value = 1 } }; // assigns just fine, but causes CreateOrUpdateAsync to throw NotSupportedException

The Serialization logic existed in SDK is not the same as JsonSerializer. The current solution for this is to pass a JsonElement rather than a Object to Parameters:
string str= JsonSerializer.Serialize(new { Foo = new { value = 1 } });
JsonElement jsonElement = JsonDocument.Parse(str).RootElement;
tmpDeploymentProperties.Parameters = jsonElement;

If you are using .NET 6.0, then SerializeToElement function can help.
tmpDeploymentProperties.Parameters = JsonSerializer.SerializeToElement(new { Foo = new { value = 1 } });

We will add some more samples of creating Deployment in the Resource RP, and we will consider modifying Serialization logic in SDK so that can pass a Object to Parameters or Template in the future.

More examples would definitely be helpful. Instead of allowing more kinds of objects directly in the current structure, is there any chance this could get more strongly typed so consumers know what they can use without needing to look at the examples? In addition to the suggestion for a native DeploymentParameters type in my first comment, I could also imagine the following would allow for more natural intellisense discoverability:
public abstract class DeploymentTemplate
{
    public static DeploymentTemplate FromJson(System.Text.Json.JsonElement json) {}
    public static DeploymentTemplate FromJson(System.Text.Json.JsonNode json) {}
    public static DeploymentTemplate FromJson(string jsonText) {}
    public static DeploymentTemplate FromFile(FileInfo template) {}
    public static DeploymentTemplate FromSerializable(IUtf8JsonSerializable obj) {}
}

public class DeploymentProperties
{
-    public object Template { get; set; }
+    public DeploymentTemplate Template { get; set; }
}

Talked with the team. Below are our conclusions.

The description comes from swagger doc and it is shared by all SDKs. The reason of defining the Template and Parameters to be type "Object" is making sure they can take a string or JObject as input.

When using string on Template, it's SDK's job to convert it to a JObject first. However in c#,  the string just be serialized as a string, therefore causing error. So it is indeed an issue in c# SDK rather than in swagger doc. We will find a way to fix this.

The "JObject" in the description means certain types of JObject rather than general Object. In Java SDK it uses Object from "Jackson" and it also doesn't support general Object types. Therefore we will not modify c# SDK to accept any POCO Object, but we will add some sample code so that customers know what Object can be used here.

After discussion, we think using the proposed strong type solution might not be the best way. If there are 10 more cases like Template then there would be 10 more redundant classes like DeploymentTemplate generated, which all serve the same general purpose.


fps keyword doesn't work with scrubber

ALL software version info
(this library, plus any other relevant software, e.g. bokeh, python, notebook, OS, browser, etc)
hvplot version 0.5.2.
Description of expected behavior and the observed behavior
The fps keyword does not work when creating an xarray.hvplot with a scrubber.
Complete, minimal, self-contained example code that reproduces the issue
import xarray as xr
import hvplot.xarray  # noqa

air_ds = xr.tutorial.open_dataset('air_temperature').load()
air = air_ds.air
air.hvplot(groupby='time', width=600, widget_type='scrubber', widget_location='bottom',
           fps=5)

Gives the warning
WARNING:param.main: fps option not found for image plot; similar options include: []

In HoloViews fps is a renderer/output setting. In HoloViews the output settings don't have the same status as the other style/group options (see https://github.com/holoviz/hvplot/issues/519#issuecomment-1283564838) and as such aren't as easily controlled. widget_type and widget_location happen to also be output settings, except that they're explicitly handled by hvPlot.
In this particular case, using pure HoloViews and setting fps would not affect the video scrubber rate, as fps is only used when an animation file (e.g. a GIF) is created. The scrubber is implemented by with Player widget of Panel that has an interval parameter (its default value is 500 milliseconds i.e. 2 updates per second). So to get there:

[ ] offer a way in HoloViews to set the Player interval parameter
[ ] expose that control in hvPlot


Freshclam output changed -

Either the output of freshclam has changed (or was always wrong at the version deployed to prod)...
[root@clamav-2334659081-82n4v /]# freshclam
ClamAV update process started at Mon Mar  6 17:36:01 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 23177, sigs: 1728734, f-level: 63, builder: neo)
bytecode.cld is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
[root@clamav-2334659081-82n4v /]# clamdscan eicar.com
/eicar.com: Eicar-Test-Signature FOUND

----------- SCAN SUMMARY -----------
Infected files: 1
Time: 0.056 sec (0 m 0 s)
[root@clamav-2334659081-82n4v /]# /readyness.sh
freshclam not running
[root@clamav-2334659081-82n4v /]# freshclam
ClamAV update process started at Mon Mar  6 17:37:55 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 23177, sigs: 1728734, f-level: 63, builder: neo)
bytecode.cld is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
[root@clamav-2334659081-82n4v /]# freshclam | grep -q 'bytecode.cvd is up to date'
[root@clamav-2334659081-82n4v /]# echo $?
1

Essentially bytecode.cvd should be bytecode.cld
Update the check to work appropriately...

fixed in master and pushing to dev.

no longer an issue?!...closing


Question/Enhancement : Add support for selecting Access Provider version

Currently you can only use Access Database Engine 12.0 (2007 era) I cannot get update-database to work with any other Engine. I'd like to use 16.0 (2016 era) - https://www.microsoft.com/en-us/download/details.aspx?id=54920
Even if I set my DBContext.OnConfiguring() to use Provider=Microsoft.ACE.OLEDB.16.0 update-databse -Verbose shows me that it's still trying to use 12.0 even if I don't have it installed. And even if 12.0 references the real 16.0 when installed, update-database creates the db file if not present, but then fails to run any queries against the db and just leaves it empty

About using the right provider, the right property should be JetConfiguration.OleDbDefaultProvider (its static).
All the tests runs with 12 because the sets the connection directly (another way to use the provider you need).
You can also use App.Config to set the connection.
About DB creation and few other DDL statements the provider uses ADOX (dynamically referenced so if it's not present the provider raise an error but compiles) because Jet OLEDB provider does not implement different DDL statements (for example create DB and rename of objects). I don't know if your ADOX is the latest version (as well as I don't know if Microsoft updated it, it's ages that I don't use ADOX). Could your update-database issue related to this?
About update-database if you can't solve it if you send me the steps and the model I can try to reproduce it.
Thanks for the suggestions and for using the provider

@bubibubi could we get a nuget package with this fix in?

Just made a new release

Hi, I am trying to create a 2000 file format Access database to replicate our current version using EFC. I have tried using OLEDB.4 with OleDbDefaultProvider = "Microsoft.Jet.OLEDB.5.0;Jet OLEDB:Engine Type=4" without much success. Any suggestions? Thanks

Sorry - that should be Microsoft.Jet.OLEDB.4.0;Jet OLEDB!

Hi, I am trying to create a 2000 file format Access database to replicate our current version using EFC. I have tried using OLEDB.4 with OleDbDefaultProvider = "Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=4" without much success. Any suggestions? Thanks

You have to compile the app using 32bit configuration (Jet.OLEDB.4.0 is 32bit dll).
What is the error you receive?

Using optionsBuilder.UseJet("Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=4;Data Source=MY.MDB"); with your recompiled .jet source of public static string OleDbDefaultProvider = "Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=4"; (everything compiled with x86), it creates a Access 2002 format database, but I need 2000 file format. Thanks

From the engine’s perspective, Access 2000,2002,2003 format files all use the same engine. That is to say, Jet 4.0 will interact in the same way with any of those file formats.
The difference between Access 2000 and 2002-2003 formats come in with what the Gui Access Client can do. If you use any 2002/2003 features in that db file, then attempting to open the file with a 2000 client will cause issues. Hence why there is an arbitrary version difference in the 2 access file formats. But in reality the file formats are structurally the same.
If you are only accessing these files programmatically, using Jet, you should have no problems.
If you open these files with a Gui client, you will be restricted by the file format version. (You can always open the files with a newer-capable client, but you cannot open a 2002-2003 file with a 2000 Client)
Can you describe what it is that your doing with these files? What is the reason that the outputted files must be 2000 format?
Sent from Mail for Windows 10
From: alan-hardwick
Sent: Wednesday, February 20, 2019 11:48 AM
To: bubibubi/EntityFrameworkCore.Jet
Cc: SheepReaper; Author
Subject: Re: [bubibubi/EntityFrameworkCore.Jet] Question/Enhancement : Addsupport for selecting Access Provider version (#15)
Using optionsBuilder.UseJet("Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=4;Data Source=MY.MDB"); with your recompiled .jet source of public static string OleDbDefaultProvider = "Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=4"; (everything compiled with x86), it creates a Access 2002 format database, but I need 2000 file format. Thanks
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

If I use my version of MSAccess GUI (Office 2016) I can open one of our current 2000 format files. I cannot find how to use the EF Core to create the same 2000 format .MDB file. Using OLEDB.4, depending on the Engine Type I use, my GUI MSAccess says it cannot open it as it is a previous version (perhaps '97 although I do not know how to confirm this), or it opens as a 2002 format. At present we wish to maintain the 2000 format, soI am investigating using EF Core with this file type. Thanks

Engine Type 5 = Jet 4.0
using anything less results in a pre-2000 file.
Your problem stems from the fact that in Jet 4.0, when you create a new file, It will by default be the "current" version that that the engine supports.
I do not know of a way to create an mdb file in "2000" version mode. 2000 is essentially a "compatibility mode" version for 2002-2003.
2000 and 2002-2003 are structurally equivalent. You should only see a problem when using an Access 2000 Client.

Maybe try to install an old version of Jet OleDb Provider 4.0 (Older than SP1)
in 4.0 pre-SP1 2002-2003 didn't exist yet. Maybe that's your answer.... Find an Office 2000 disk without the service pack.

You can also try to use an empty mdb that you already have. In the migration process you can create only the tables using the already existing mdb.

Excellent - thanks for all your help.


Make sure include files are always fully qualified.

To make sure headers are unique, always use a path relative to the toplevel.

Codecov Report
Patch and project coverage have no change.

Comparison is base (de4211b) 93.13% compared to head (06c0ec6) 93.13%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1907   +/-   ##
=======================================
  Coverage   93.13%   93.13%
=======================================
  Files         355      355
  Lines       25843    25843
=======================================
  Hits        24069    24069
  Misses       1774     1774

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[Proposal] support for realtime multiple filters

I've tried to implement support for adding multiple filters to a real-time subscription.
After conducting some tests locally, I don't see any major issues. I wanted to understand if it's a feature that can be implemented.
I need this function in some projects, I have seen several requests for this here

Our Realtime server can only take one filter at the moment, so this update would not work unfortunately.

I tested it and it seemed to work:
    final query = client
        .schema(config.schema)
        .from(config.messagesTableName)
        .stream(primaryKey: ['id'])
        .eq('roomId', int.parse(room.id)).gt('createdAt',<PHONE_NUMBER>862) //<-----
        .order('createdAt', ascending: false);

@rickypid
Currently, Supabase Realtime simply does not have multi-filter support, and you certainly cannot just join multiple filter strings with & to make it work. Supabase Realtime simply does not have the API to accept multiple filters joined by &. If you think it works, then you haven't done enough testing.

@dshukertjr
I don't want to be insistent or suspicious but I would like to explain my situation to you.
To demonstrate how it works:

I have a demo app for a chat, I create two rooms without messages.

In both chats I send a message, in chat 1: Message from chat 1 and in chat 2: Message from chat 2

Chat 1:

Chat 2:

I have this function to get the message stream:
     final query = client
         .schema(config.schema)
         .from(config.messagesTableName)
         .stream(primaryKey: ['id'])
         .eq('roomId', int.parse(room.id)).gt('createdAt',<PHONE_NUMBER>862)
         .order('createdAt', ascending: false);

I therefore have a filter for the roomId and one for the creation date createdAt greater than x.
Up to here everything works. 😄
If I try to remove the roomId filter the messages in the chats get mixed up (As I expect):
     final query = client
         .schema(config.schema)
         .from(config.messagesTableName)
         .stream(primaryKey: ['id'])
         /*.eq('roomId', int.parse(room.id))*/.gt('createdAt',<PHONE_NUMBER>862)
         .order('createdAt', ascending: false);

The contents of chat 1:

Then both filters are applied.

I then carry out this test, restoring the original filters (So for both roomId and createdAt) and insert a query into the database with a message with a date greater than the createdAt filter and the correct roomId, so I expect to receive the real-time event:
INSERT INTO chats.messages("createdAt", "roomId", "status", "type", "authorId", "text")
VALUES<PHONE_NUMBER>000, 7, 'sent', 'text', '8af5a695-9e1f-4a0b-84d4-ec3ec1d1433d', 'Message from query');

Chat 1

Event received successfully!! 😄
Now I do the same thing with the date before the createdAt filter:
INSERT INTO chats.messages("createdAt", "roomId", "status", "type", "authorId", "text")
VALUES<PHONE_NUMBER>700, 7, 'sent', 'text', '8af5a695-9e1f-4a0b-84d4-ec3ec1d1433d', 'Message from query');

Chat 1

Event not received because the date does not match the filter. 🚀
In my opinion I don't see any problems, I don't know where I'm going wrong but everything works correctly.
I hope I performed the tests correctly.
Just for completeness: I performed the same tests done with inserting the message with a query from another client by sending the message with the supabase-flutter client.

@dshukertjr
I tested with the tests in packages/realtime_client/test/mock_test.dart, I added:

and the tests pass:

if I change the data and they don't respect the filters they don't pass:

I hope I did it correctly.

@rickypid
The mock test that you used just has a mock server that emits the payload of Realtime server, and passing the wrong configuration could still result in events coming through, so it's not a good indicator of whether your PR works (TBH, it's probably not a very good test code).
I want you to try applying multiple filters on a live Supabase instance using the onPostgresChanges() and see if you get Realtime events. The .stream() method uses the REST API and the Realtime events, and probably the reason why you thought you were getting the correct results was because you were seeing the REST API, which supports multiple filters, fetch the correct results.
Supabase Realtime server only supports a single filter currently. If you had tried it against an actual Supabase instance, you would have seen that it doesn't work.
Here is a video explaining and demonstrating how the code in this PR fails to subscribe to Realtime changes.
https://github.com/supabase/supabase-flutter/assets/18113850/3078ae30-8ecb-45c1-9988-ea4c577cc336
I appreciate the gesture that you wanted to make this library better, but perhaps we can channel the energy into something else as there is nothing we can do no the Flutter SDK side of things to add support for multiple filters at the moment. Note that our Realtime team is aware that users want more complex filters, and they do have future plans of supporting complex queries.

@rickypid
You probably could implement the chat feature without .stream(), and just use the combination of the REST API methods and onPostgresChanges method.
You can use the rest API methods to get the first
// Assuming you have the room ID
final myRoomId = 1;

// Get the past 20 messages in a chat room.
final chatData =  supabase.from('messages')
  .select()
  .eq('room_id', myRoomId)
  .order('created_at')
  .limit(20);

// Listen to new incoming chat messages
    supabase
        .channel('messages')
        .onPostgresChanges(
            event: PostgresChangeEvent.all,
            schema: 'public',
            table: 'messages',
            filter: PostgresChangeFilter(
              type: PostgresChangeFilterType.eq,
              column: 'room_id',
              value: myRoomId,
            ),
            callback: ((payload) {
              // Update state to add the new incoming messages to the UI
            }))
        .subscribe();

Then when the user scrolls up to see more past messages, you just need to get them using the REST API methods
final pastChatData =  supabase.from('messages')
  .select()
  .eq('room_id', myRoomId)
  .lt('created_at', chatData.last.createdAt)
  .order('created_at')
  .limit(20);

@dshukertjr
I like it, I can handle this with a StreamController and create equivalent logic for myself.
Thank you so much for the suggestion and support you provided for this PR.


Remove reply-to-address in missed message emails if you don't allow the message content

Hi,
Prerequisite
The user has configured and activated the incoming email integration
Problems
If you don't allow the message content in missed message mails, you get messages with the following ending:
—
You are receiving this because you have email notifications enabled for this stream.
Reply in Zulip, or manage email preferences.

Do not reply to this message. This Zulip server is not configured to accept incoming emails (help).

The last sentence is logically wrong, because the user can send and reply to this email and it will show up in zulip.

If you don't allow the mesage content, there should be no reply-to address in the email, because why should an user reply to a message with a unknown topic.

Possible solution
Remove the reply-to address from the email if allow content in missed message emails isn't checked.

I believe this is fixed in master and the fix has already been backported to the 2.1.x branch.  See https://github.com/zulip/zulip/pull/13773.

Hi Tim,
great, i didn't mentioned that i refer to to latest 2.1.2 relase.


Can't wire it all up properly

Hello, awesome project, just what we need! Great documentation and everything too.
But..
I can't get a hold of how to actually make it work. I understand the "big picture", compiling and everything but want to initialize my project with the Autowire configuration and RuntimeContainer. But I don't really get how the Compiler gets bundled with my classes to allow injections.
My tests are simple really, in my index file;
    class CompilerConfig extends \WoohooLabs\Zen\Config\AbstractCompilerConfig
    {
        public function getContainerNamespace(): string
        {
            return "App\\Container";
        }

        public function getContainerClassName(): string
        {
            return "Container";
        }

        public function useConstructorInjection(): bool
        {
            return true;
        }

        public function usePropertyInjection(): bool
        {
            return true;
        }

        public function getContainerConfigs(): array
        {
            return [
                new ContainerConfig()
            ];
        }
    }

    class ContainerConfig extends \WoohooLabs\Zen\Config\AbstractContainerConfig
    {
        protected function getEntryPoints(): array
        {
            return [
                // Define all classes in a PSR-4 namespace as Entry Points
				new Psr4NamespaceEntryPoint("App\Controllers"),
                new Psr4NamespaceEntryPoint("LCMS\Api"),
				new Psr4NamespaceEntryPoint("LCMS\Backbone"),
				new Psr4NamespaceEntryPoint("LCMS\Core")
            ];
        }

        protected function getDefinitionHints(): array
        {
            return [];
        }

        protected function getWildcardHints(): array
        {
            return [];
        }
    }

Then directly afterwards;
	$container = new RuntimeContainer(new CompilerConfig());

	pre($container->get("LCMS\Core\Request"));

	new \App\Controllers\Dashboard(); die("done");

And inside the Dashboard-controller, Im testing this;
	class Dashboard extends \LCMS\Backbone\Controller
	{
		function __construct(\LCMS\Core\Request $r)
		{
			pre($r);
			die("const");
		}

But it doesnt work. Just getting the most obvious error; "Fatal error: Uncaught ArgumentCountError: Too few arguments to function App\Controllers\Dashboard::__construct(), 0 passed in".
Im not grasping how to wire everything together really. The Container is up and running per the configuration, and I though the whole idea here is that I don't have to worry about passing objects into constructors of my wired classes/controllers (E.g in the Dashboard controller, just saying I want the Request class, would magically put it there thanks to the wiring?)
What am I doing wrong? Or am I maybe wishing for too much..
Thanks!

Okey sorry for this, I obviously got the idea backwards. I now understand that I have to use the container in order for the autowiring to work. E.g instead of initializing new \App\Controllers\Dashboard() I just call it with $container->get("App\Controllers\Dashboard") instead.


Can't amplify push due to "[googleClientId] do not exist in the template" error

Which Category is your question related to?
Auth
Amplify CLI Version
$ amplify -v
4.27.3
What AWS Services are you utilizing?
Cognito
Provide additional details e.g. code snippets
I fixed PostConfirmation function of  Cognito in multiple env and with Google's federation set up.
After that, when amplify push, I can't complete the push due to the "[googleClientId] do not exist in the template" error.
$ amplify push
✔ Successfully pulled backend environment dev from the cloud.

Current Environment: dev

| Category | Resource name               | Operation | Provider plugin   |
| -------- | --------------------------- | --------- | ----------------- |
| Function | webf542827dPostConfirmation | Update    | awscloudformation |
| Auth     | webf542827d                 | No Change | awscloudformation |

UPDATE_IN_PROGRESS          webf542827d        AWS::CloudFormation::Stack Sat Sep 26 2020 12:06:20 GMT+0000 (Coordinated Universal Time)
UPDATE_FAILED               webf542827d        AWS::CloudFormation::Stack Sat Sep 26 2020 12:06:20 GMT+0000 (Coordinated Universal Time)
Parameters: [googleClientId] do not exist in the template

Also, the process of removing the federation with amplify update auth gives me the same error as above and I can't do the update.
And, googleClientId is written in team-provider-info.json
    "categories": {
        "auth": {
            "webf542827d": {
                "hostedUIProviderCreds": "[{\"ProviderName\":\"Google\",\"client_id\":\"100222998699-gps3kohgkpibbbb72dr5c0jc712khf51.apps.googleusercontent.com\",\"client_secret\":\"Y8szeeee9_mUJdddQPlffffuP\"}]",
                "googleClientId": "100222998699-gps3kohgkpibbbb72dr5c0jc712khf51.apps.googleusercontent.com"
            }
        }

Could you please let me know if there is a workaround?

I resolved this problem.
Firstly, I remove Google specification from "Update OAuth social providers" and amplify push.
Secondly, I re-set Google specification by "Update OAuth social providers" and push.
Finally, modify funcation and push.
$ amplify update auth
  Walkthrough all the auth configurations
  Add/Edit signin and signout redirect URIs
❯ Update OAuth social providers
  Create or update Cognito user pool groups
  Create or update Admin queries API

❯ Update OAuth social providers

I dont have this option...

❯ Update OAuth social providers

I dont have this option...

Ohh...
1.) I had to 'amplify update auth' and add oauth manually and provide access key and secret key for both Facebook and google.
2.) And then i had to 'amplify update auth' AGAIN! And only then i saw this '❯ Update OAuth social providers' option. Click on it and u have to provide with Access key and Secret key for both Facebook and Google again!
3.) Now 'amplify push' - Should work now! Be happy!
resume: u have to provde Facebooks and Googles access key and secret key TWICE.


[kraken.js] (addOrder) returned an irrecoverable error: Order:Invalid price:Invalid price argument.

Note: for support questions, please join our Discord server

I'm submitting a ...
[ ] bug report
[ ] feature request
[ ] question about the decisions made in the repository

Action taken (what you did)
Checked the config, tested with development version. Read a lot of posts.

Expected result (what you hoped would happen)

Actual result (unexpected outcome)

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, etc)

Ik have this error on Kraken when trying to trad a live Gekko:
2018-02-23 21:09:46 (DEBUG):	[kraken.js] entering "setBalance" callback after kraken-api call, data: { error: [],
result:
{ ZUSD: '3.4638',
ZEUR: '0.1411',
XXBT: '0.0031235580',
XXRP: '0.00000541',
XXDG: '0.00008275',
XETH: '0.0000000000',
BCH: '0.0000005000' } }
2018-02-23 21:09:46 (INFO):	Attempting to BUY 4805.473846153845 XDG at kraken price: 0.000000640
2018-02-23 21:09:46 (DEBUG):	[kraken.js] (addOrder) BUY 4805.473846153845 XDG @ 6.4e-7 XBT
2018-02-23 21:09:47 (ERROR):	[kraken.js] (addOrder) returned an irrecoverable error: Order:Invalid price:Invalid price argument.
I am using the latest stable version.
I have tried to discover the reason without any result.  Paper trading and backtesting goes without any problem. I have tried the development version, this gives the same results.
Any help is appreciated!

This has since been fixed!


Quick Start v1

Hello!
And welcome to the HOPR Tech Support portal.  Here we will report issues coming in from our social media channels.

Remember, this is on GitHub so do not share any confidential information here.  Either of your own, or that of our users.

Just like our social channels themselves, the issues the community faces are open, not hidden, so if there is a need to share any personal information or handle a tech support issue that was requested to be kept private, please consult with me in our usual messaging channels.

Let's get started, shall we?!

Please DM your email address to me if you'd like to be added to my GitHub group so you can be tagged or get assigned.  This is optional.  It is helpful if this email address is the one associated with your GitHub account.
Our goal is to use the Telegram chats for instant communication, being sociable between ourselves, onboarding users, etc.  This platform is to report tech support issues which might arrive when the person who can check is not around, there is a longer term issue to resolve which might get lost in chat, we are onboarding many users are once (we can split duties between funding vs. reporting issues here then) etc.
Eventually we can start to identify trends and group them in 'epics', I think the organizational abilities will be ideal
Feel free to tag me when you wish here, @kitschbent

sent you a DM with my mail address


waitFor method is not stable

waitFor method does not work (driver.execute('flutter:waitFor', buttonFinder, 100))

not resolved


[ffmpeg-qsv] add avce playback_seek test case

Thanks for the feedback. I will refactor this file in the future to consolidate all the other duplicate code when I have time.
Additionally, there are some issues with seek_lp(AVCEncoderLPTest), and I will submit a PR focusing on that.


nbclassic 0.4.8

Jira ticket: PKG-300 (nbclassic-0.4.8)
The upstream data:
Github releases:  https://github.com/jupyterlab/nbclassic/releases
Diff between the latest and previous upstream releases
License: https://github.com/jupyterlab/nbclassic/blob/master/LICENSE
Changelog: https://github.com/jupyterlab/nbclassic/blob/main/CHANGELOG.md
Requirements:

setup.cfg:  https://github.com/jupyterlab/nbclassic/blob/v0.4.8/setup.cfg
setup.py:  https://github.com/jupyterlab/nbclassic/blob/v0.4.8/setup.py
pyproject.toml:  https://github.com/jupyterlab/nbclassic/blob/v0.4.8/pyproject.toml

Actions:

Notes:
*
Package's statistics

Priority B | effort: easy | Category: other | subcategory:  | pkg_type: python
Outdated platfroms: 'linux-64', 'linux-aarch64', 'linux-ppc64le', 'osx-64', 'osx-arm64', 'win-64'
Latest version: 0.4.8
Release on PyPi:

version: 0.4.8
date: 2022-11-03T11:14:44

PyPi history
Popularity:

3 months downloads: 430803.0
All time:  2203101 downloads -  nbclassic  0.4.8  A web-based notebook environment for interactive computing  copy

Other checks:

[ ] The upstream url error:
https://github.com/jupyterlab/nbclassic/tree/0.4.8
301

[ ] The upstream url error:
http://github.com/jupyterlab/nbclassic
301
The home url must have HTTPS!

[ ] Check the pinnings

[ ] Changelog url error:
https://github.com/jupyterlab/nbclassic/tree/0.4.8
301

[ ] Additional research
https://github.com/jupyterlab/nbclassic/issues
301

[ ] dev_url error:
https://github.com/jupyterlab/nbclassic
301

[ ] doc_url error:
https://github.com/jupyterlab/nbclassic/blob/main/README.md
301

[ ] Verify that the build_number is correct

[x] has setuptools

[x] has wheel

[x] pip in test

[ ] Verify the test section

[ ] Verify if the package is architecture specific or Noarch

[ ] Verify that private module are not mentioned on the recipe For example: (_private_module)

[x] license_file: LICENSE is present

[x] License: BSD-3-Clause
[ ] License is spdx compliant

Check if the license identifier has correct name from the SPDX License List

Identifier

BSD-3-Clause

BSD-3-Clause-Attribution

BSD-3-Clause-Clear

BSD-3-Clause-LBNL

BSD-3-Clause-Modification

BSD-3-Clause-No-Military-License

BSD-3-Clause-No-Nuclear-License

BSD-3-Clause-No-Nuclear-License-2014

BSD-3-Clause-No-Nuclear-Warranty

BSD-3-Clause-Open-MPI

[x] license_family BSD is present

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_f2mhwzyrbz/clone/recipe/meta.yaml:85: missing_doc_source_url: The recipe is missing a doc_source_url
WARNING: /tmp/abs_f2mhwzyrbz/clone/recipe/meta.yaml:85: missing_license_url: The recipe is missing a license_url
Warnings were found

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_25e05ugr9h/clone/recipe/meta.yaml:85: missing_doc_source_url: The recipe is missing a doc_source_url
WARNING: /tmp/abs_25e05ugr9h/clone/recipe/meta.yaml:85: missing_license_url: The recipe is missing a license_url
Warnings were found

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_3fxvepqud2/clone/recipe/meta.yaml:85: missing_license_url: The recipe is missing a license_url
WARNING: /tmp/abs_3fxvepqud2/clone/recipe/meta.yaml:85: missing_doc_source_url: The recipe is missing a doc_source_url
Warnings were found

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_1bt3psgjwd/clone/recipe/meta.yaml:85: missing_license_url: The recipe is missing a license_url
WARNING: /tmp/abs_1bt3psgjwd/clone/recipe/meta.yaml:85: missing_doc_source_url: The recipe is missing a doc_source_url
Warnings were found

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_ffao8wcojk/clone/recipe/meta.yaml:85: missing_doc_source_url: The recipe is missing a doc_source_url
WARNING: /tmp/abs_ffao8wcojk/clone/recipe/meta.yaml:85: missing_license_url: The recipe is missing a license_url
Warnings were found


Show entity annotations in error report from rasa_nlu.test

Results in errors.json current look like this:
    {
        "text": "hello i have a question. is there a mexican restaurant in paris?"
        ...
    }

Would be nice to have the entities annotated since that's how they look in the training data, i.e.
    {
        "text": "hello i have a question. is there a [mexican](cuisine) restaurant in [paris](location)?"
        ...
    }

hmm this raises the question of whether those are entity errors or intent errors though

Currently only intent errors are logged to errors_filename(default errors.json). Each entity extractor gets its own <extractor>_report.json with evaluation metrics from sklearn, but i don't think we currently have a list of error sentences for entity extraction 😬

@akelad I actually just had someone asking if it's possible to see the list of entity extraction errors, think that's something worth adding to my nlu test refactor? (i realize this is relatively unrelated to toms actual issue here)

@erohmensing let's focus on the refactor for now, if there's time and it's super easy to do, then sure :)

sounds good. i'll create a separate feature request for it

closing, duplicate of #1472


fix: Fix hardcoded strings in AddMedicationRoute

Reg: #136 Added hardcoded strings to strings.xml

Thank you for your contribution @muazzam27 but I'll have to close this in favor of #126 as it was submitted earlier :) Your efforts are truly appreciated though and I encourage you to continue contributing. :)

@waseefakhtar Sorry I did not know but thanks.


unstable channel hasn't updated for 14+ days

The unstable-channel is stuck at commit e916273209560b302ab231606babf5ce1c481f08, mostly because of test failures related to GNOME3, but several other tests have failed in an on/off fashion, too.

That's a bug preventing OpenGL in a 32-bit qemu (see e.g. discussion on #9983). We have bumps fixing this in staging IIRC, but staging failed completely due to full disk several days ago and noone has restarted the jobs yet, so there are no binaries in sight.

We might disable that test for a while on master.

I tried to restart those 40176 staging builds, but the Hydra web front can't do it. It constructs an SQL command that's too big for the database server to execute, and then all I get is "internal error".

cc @edolstra

Just for reference:
DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::Pg::st execute failed: ERROR: stack depth limit exceeded
HINT: Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack depth limit is adequate. [for Statement "UPDATE Builds SET busy = ?, finished = ?, iscachedbuild = ?, locker = ? WHERE ( ( id = ? ...

The staging thing is a separate issue. Right now, the only thing that blocks the unstable channel is nixos.tests.gnome3.i686-linux: http://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents

Well, word has it that staging contains a fix for the gnome3 test failure, so the fact we cannot merge it to master seems relevant for this issue.

Updated

I tried to restart those 40176 staging builds, but the Hydra web front-end can't do it.

Would you try restarting staging now? After some updates, there are <19k abortions.


Domain Admins can't create service offering in the UI

ISSUE TYPE

Bug Report

COMPONENT NAME

UI

CLOUDSTACK VERSION

Main

SUMMARY

Domain Admins can create service offering using the CloudMonkey but they can't create a service offering in the UI. I noticed that the domainid is missing in the API calls from the UI to the backend. When the domainid is missing, CloudStack tries to create a public service offering. The action that the DomainAdmins don't have the right to do.
(test)  > create serviceoffering name=Test displaytext=Test
🙈 Error: (HTTP 431, error code 4350) Unable to create public service offering by admin: 7785744c-3c07-429e-b908-a7184bafa288 because it is domain-admin
(test)  > create serviceoffering name=Test displaytext=Test domainid=47663737-3d73-442b-8392-cad78e162e36
{
  "serviceoffering": {
    "created": "2023-02-15T13:57:18+0000",
    "defaultuse": false,
    "diskofferingstrictness": false,
    "displaytext": "Test",
    "domain": "test",
    "domainid": "47663737-3d73-442b-8392-cad78e162e36",
    "dynamicscalingenabled": true,
    "hasannotations": false,
    "id": "66538687-e3e5-4fa6-ba0c-b723f74e3f72",
    "iscustomized": true,
    "issystem": false,
    "isvolatile": false,
    "limitcpuuse": false,
    "name": "Test",
    "offerha": false,
    "provisioningtype": "thin",
    "rootdisksize": 0,
    "serviceofferingdetails": {
      "domainid": "59"
    },
    "storagetype": "shared"
  }
}
(test)  >

STEPS TO REPRODUCE

1. Login as Domain Admin
2. Try to create a service offering, it fails

EXPECTED RESULTS

Service offering is created successfully

ACTUAL RESULTS

It fails with the error: "Unable to create public service offering by admin: .... because it is domain admin"

@DaanHoogland Please add this one to the 4.18 milestone.

Thanks @soreana, can you please verify the fix on #7261?

Thank @nvazquez. It fixes the issue 👍


TFlite IOS will not build when imported as part of a package. 100+ Undefined Symbols reported at link phase

Issue Type
Build/Install
System information
Mac OS 12.6.1
XCode 14.1
TFLite 2.9.1
Describe the problem
I am trying to add TFLite to a swift package that we have. Essentially our code runs its own tflite models, so it has a dependency on TFLite Swift, which depends on TFLiteC. Since this is a swift package, it is not an option to use pods.
Using information from this thread, I was able to add the TFLite dependencies, and successfully build my swift package as a standalone package.
However, once I add my package into an actual project, the linking phase completely breaks, with over 100 undefined symbols.

This also happens when using the examples at the end of the above thread.
For clarity, adding the package here, under Frameworks, Libraries, and Embeded content causes the linking failure.

Source code / logs
Here is a link to the test project that reproduces this error. (50mb so I cannot directly upload it here)
https://drive.google.com/file/d/1xV-qSxF7z94SqFSrf1QWBkwHesIug0wt/view?usp=sharing

@arctop-sk you appear to not have included the standard C++ library in your project. You can try to add libc++.tdb to your "Frameworks, Libraries, and Embedded Content" section:

Also, IIRC, this is only an issue if you build TFLite as static framework. Consider building them as dynamic frameworks if possible.
Your project appears to be in Swift. Swift cannot directly talk to C++, so you may need to deal with the complexity of writing some wrappers in Objective-C around the TFLite API. I would either make an Objective-C project instead of Swift, or consider getting TFLite into your project using Cocoa Pods: https://www.tensorflow.org/lite/guide/ios

@DwayneDuane
Thanks. In fact adding libc++ does solve the linking issue. This was a test, where ultimately i will be using TFLite swift as the API, it just depends on getting this part correctly compiling.
As stated, i need to have this work as a swift package until the team releases a working swift package as mentioned in the referenced thread. For now, this should work.


I want console functionality

Is your feature request related to a problem? Please describe.

Describe the solution you'd like:

Describe alternatives you've considered:

Additional context:

This would be amazing

If you launch the extension via the debugger workflow in VS Code, the Debug Console is the browser console.
Described in the docs here:
https://docs.microsoft.com/microsoft-edge/visual-studio-code/microsoft-edge-devtools-extension#console-integration
There's also a one minute video here.

If you launch the extension via the debugger workflow in VS Code, the Debug Console is the browser console.

No, you can easily see here that the Debug Console does not work with this extension.
https://user-images.githubusercontent.com/9962943/145381442-354f18b0-add5-4dd5-bd58-b589d2765034.mp4


Differentiate a tap from swipe

@irae can you please take a look?

Thank you for submitting this pull request, however I do not see a valid CLA on file for you. Before we can merge this request please visit https://yahoocla.herokuapp.com/ and agree to the terms. Thanks! :smile:

CLA is valid!

@yahoocla agreed to the CLA

This might be more suited to be fixed on vendor/zynga. Could you please double check if the same fix is possible there? Thanks.

Thanks for your contribution!


Improve documentation

Sorry about the delay in responding to your issue. Please feel free to open a pull request. I've been a bit busy.

Just a couple quick examples would be appreciated!

Documentation about my integration of this packer can be found here:
https://github.com/prcela/MessagePackReadme/wiki
Maybe it helps.

+1

+1

Thanks @prcela! I suggest putting your examples into the README of this project and creating a PR. I'm sure @a2 would appreciate this.


set up unittesting

add gitignore for node
install jest as dev-dependency
create test file for app.js

Is good


geocoding requires google api

Could you please add an API key input to the config file for the geocoding feature to work

Any Progress on this issue?

Recently merged in #53 thank you for your patience.


INFIX TO PREFIX conversion in C.

🚀 Feature
Have you read the Contributing Guidelines on Pull Requests?
Yes !
AIM :: INFIX TO PREFIX conversion in C.
Motivation
As i didn't found INFIX TO PREFIX conversion in C , So i am willing to contribute it...
Pitch
Hi I am GSSoC'21 participant,
"I am looking to work on the INFIX TO PREFIX conversion in C.
I will write the clean and optimized code , by keeping best case time and space complexity in mind and
with  brief commenting and algorithm.
I will use C language.
So i would to like @bhav09 , @HarshCasper sir to please review this issue , so that i can do PR ,
as i have already completed with coding :)
/assign

/assign


stop early exit from tutorial

can we get a time estimate for the following?
Can we remove the 'X' on the top right that closes the tutorial? This will force users to go through every screen until the get to the "Let's go" green button on the last page of the tutorial.

thanks!!!

@tingard @colin1715labs please close this if you don't need it

It's not needed, but potentially still valuable. Can we add a "low priority" flag of some kind?

@rogerhutchings the "it's not an issue" chat was referring to Tim's initial comment on 11 May (due to the mitigating action referenced in the reply below), rather than the original post, which is still an issue.


UI Step 2 - Issue no. 19

@FIN-casey
The third Information button states that:
"In the column "Class" of the functional group in which you wish to reallocate the species, press the Edit button and type the name of the class; suggestions will be provided to you as you start typing something. Once the class name is entered, the species belonging to that class will automatically appear in the "Species" column of the new functional group."
However, currently, if one starts typing the name of a class the available space, no suggestion is provided.
--> Could you please make sure that if the user starts typing the name of a class in the available space of the column "Class" of the functional group, suggestions are providing to them?
Many thanks!

@agruss2 The implementation of the autocompletion function when adding new class is almost the same as when adding new species. The difference is that the suggestion will appear after typing the 2nd letter. Suggested names are those that has a match within the name, not just the start of the name.
For example, when typing 'ac' in the Class column, the suggestions will be as follows:

Please verify the implementation.

@FIN-casey Many thanks! I just checked and the present issue has been solved; I can therefore close it now.


[opentelemetry-collector] add upgrade docs

add upgrade docs as https://github.com/open-telemetry/opentelemetry-helm-charts/pull/767#issuecomment-1531577321 discussed.
ref pr: https://github.com/open-telemetry/opentelemetry-helm-charts/pull/767

@TylerHelmuth Do I need to bump up chart version?

@JaredTan95 ya and regenerate the examples, but keep the upgrade doc version's like you have it.

@JaredTan95 ya and regenerate the examples, but keep the upgrade doc version's like you have it.

done


vscode extension updates

Status
Ready/In Progress/In Hold (Reason for hold)
Related Issues
fixes: link to the issue
Description
A few sentences describing the overall goals of the pull request's commits.
Screenshots
Paste here any images that will help the reviewer

@MichaelYochpaz Doc review completed.


Wrong colors with treesitter in php files on neovim 0.8.0

Description
After updating neovim from 0.7.2 to 0.8.0   the colors are wrong in php files.
Screenshots
Above neovim 0.8.0
Below neovim 0.7.2

Can you check the difference between the highlight groups being used (see here for details on how). With 0.8, they changed how treesitter highlight groups work would like to see the difference between the two versions. I have seen some other changes.

It looks like they are the same?
neovim 0.7.2

neovim 0.8.0

Could you check the latest nightfox, as there has been a pass to treesitter highlight groups in #251.

unfortunately it didnt change

Closing this as this is an issue more with the treesitter php grammer then nightfox's definition of the treesitter highlight groups.


Develop

Coverage remained the same at 79.435% when pulling 799a2cdeb46343083894f28782fc3178ab6800d8 on develop into 304a026a9630c8b8975b135e212a2219ef49e979 on master.


feat/fix(root): fix db schema change, introduce ORM versioning

Introduces ORM Versioning, starting with 1 Before this release 1-> BOOTSTRAP is this release, it starts the system at version 1 and immediately upgrades it to 2. In the future, this bootstrap will not be needed.

Summary by CodeRabbit

New Features

Introduced a new "Version" concept in the ORM system to track changes and facilitate efficient upgrade scripts.

Refactor

Added a new version variable in the Config class to match future DatabaseUtil.VERSION.
Upgraded the database schema in the DatabaseUtil class, including a new upgrade() method for handling version-based upgrades.

@coderabbitai review


"rasterize" vector geometry to unstructured grid and selection

An indirect route is rasterizing using GDAL to a raster, then using some regridding machinery.
Alternatively, we could use earcut: https://pypi.org/project/mapbox-earcut/ (ISC licensed, equivalent to MIT).
If we triangulate the polygons, they can be treated as a triangular unstructured grid. Then use the regridding machinery.

Other options:

just search the nodes or centroids using shapely
use pandamesh to turn the polygons into a mesh first, then overlap

Best to benchmark, probably depends on the use case, complexity of polygon, etc.

The GDAL docs on rasterize refer to "burning": https://gdal.org/programs/gdal_rasterize.html
So we could call it "burn_polygons", etc.


Support passing repositories to test

The list of repositories to test is hardcoded. There should be a way to specify them.

Can't assign myself here

The issue did not explain correctly what it meant for custom repositories, sorry. :sweat:
In regression-core there is a hardcoded list of repositories to download and use to test borges:
https://github.com/src-d/regression-core/blob/master/repositories.go#L19-L56
The idea is to be able to pass a text file with the repos to test instead of the hardcoded ones. I should have assigned it to me as I had already the loader done.
I've just added data retrieval team as admin.


Vendor Khiops with pyKhiops

Description
From Khiops 10.1.0, there will be no need of license to install it. This in theory would allow to vendor Khiops within the pyKhiops package.
Ideas / Questions

PI still asks to "accept" the license, is it possible to do it with pip?
What about installing MPI with it? Should we?
There will be two distributions: pykhiops (source and wheel) and pykhiops-full (wheel). The later will contain the vendored Khiops. pykhiops-full will depend on pykhiops.
Preliminary steps:
Parametrize setup.py with the platform and architecture. For each platform and architecture:
Dowload the Khiops packages / installers and decompress them
Copy the executables and launch script and include them in the packaging
Technical notes:
We'll need to customize the setup.py script probably overriding the install or build_ext steps.

Further questions:

regarding license acceptance: is any license acceptance tracing mechanism needed? If so, where should the license acceptance traces be stored?
regarding MPI installation: IMHO, one should do like other libraries do:
check if MPI is installed; if so, then continue; else, warn the user to install MPI system-wide, then stop.
For pykhiops, why do we need source and wheel? Wheel for consumers (potentially via pykhiops-full, but also by using a preexisting Khiops installation), and source for developers?
Regarding platform and architecture, should we support:
platform: Linux, Mac, Windows (which versions for each?)
architecture: x86_64, IA-32 (?), aarch64 (in the long run?)
question: for Windows, (how) can we extract binary file from the Windows installer?

First idea: override install, so that the Khiops package is retrieved when pip install-ing pyKhiops. However, as authenticated access to the artifactory is needed, a more doable way seems to be to override build_ext which can retrieve and embed Khiops within the pyKhiops wheel. Indeed, python setup.py bdist is done in controlled settings (in the Gitlab CI/CD) where authentication to the artifactory is not an issue.

Second idea: as we vendor Khiops at build time, we can build the Python package wheel within the pykhiops-cicd Docker image, where we have access to Khiops Debian repos, hence we can do apt-get download khiops-core=<relevant_version>.

To sum up between these two ideas:
1/ We override build_py's run method in setup.py to:

check and retrieve operating system platform and version
retrieve pykhiops version
search closest relevant and available (for the os platform and version) Khiops version: greatest Khiops version lower than or equal to the PyKhiops version, by looking at the major and minor numbers
attempt apt-get download of the determined Khiops version, according to the pyKhiops version and to the OS (platform, version), into the build directory; if this fails, then fail the build
extract, by means of dpkg-deb -R, the contents of the Khiops package and copy the scripts (khiops and khiops_coclustering), the binaries (MODL and MODL_Coclustering) and the jar files to the build directory, so that they are included in the binary distribution Wheel.

2/ We override the py-package job of the build CICD stage to do:setup.py sdist .
The bdist is done in the py-custom-release job of the publish stage.
Thus, a wheel package is generated, which contains the Khiops files (driver scripts, MODL binaries and jar files).
We need to add two entry points which have the same name and call the khiops (and khiops_coclustering) launch scripts. And perhaps another two entry points for the MODL and MODL_Coclustering binaries. The reason is that these launch scripts and binaries are installed in the package install directory (inside the virtualenv's lib/site-packages), but they need to be available in the path (inside the virtualenv's bin directory). The same goes for the two JARs: they need to be available in the virtualenv's share directory.
These actions take place within the pyKhiops CICD Docker image, hence the Khiops repositories are available.
3/ We override install's run method in setup.py to copy the Khiops scripts, binaries and jar files packaged during build, to the installation directory. Thus, we do not need to override the install setup.py stage.

Question: should we also support other Linux packaging options than dpkg/apt (e.g. yum, apk, pacman...)?

One important point: the Bash scripts khiops-env, khiops and khiops_coclustering assume that the Khiops package has been installed so that the binaries are available in /usr/bin and Java libraries in /usr/share (note the absolute paths in both cases). Or, this does not work with Pip-based vendored installs (usually inside virtualenvs).
Hence, the logic in these three scripts should be replicated in two Python entry-points (for setuptools), so that the appropriate environment is set-up, irrespective of the absolute paths where the MODL* binaries and Java JARs are located.

After further analysis and discussions, it might be better to replicate the logic of khiops-env into a Python entry-point which would:

manage the access to MPI
set the proper path to the Khiops binaries

Thus, the actual paths to the Khiops binaries can remain in the package's installation directory. The khiops and khiops_coclustering scripts are not needed. And neither are the two Khiops JAR libraries (as they are not required by MODL when used in batch mode - as it is the case with pyKhiops).

The entry point is not necessary, and I don't think we need to replicate exactly the script.
This is because the khiops-env is used in "dump" mode ; It writes the environment variables to the stdout and the pyKhiops runner parses this output.
So instead of an entry point, which would set the variables and then output them, a special method, such as _initialize_environment_from_vendored_khiops could do this job. Note that the relevant environment variables are all stored in the runner.

Yes, indeed, if there is consensus on changing the pykhiops (runner) code; and we thus can also set the appropriate path to the MODL and MODL_Coclustering binaries.
My suggestion of the entry point was assuming that the pykhiops proper code base would not be changed in any way (at least while in POC mode, pending the validation of the vendoring approach itself, including on other target operating systems).
As for the replication, IMHO the CPU and MPI-related logic and the path setting are all that it needs to be replicated (either in the special runner method or in the entry point).

The runner is the place where these changes must go because it is his responsability to set the execution environment. If you want to do it with an entry point as a prototype it is ok, but that code should go to the runner in the final version.

Yes.

Concerning replicating khiops-env functionality:

the KHIOPS_PROC_NUMBER can be determined (as the number of physical CPUs) via psutil.cpu_count(logical=False); but for this, we need to install psutil as an extra dependency!
Otherwise, we need to resort to doing subprocess.Popen with lscpu.

the KHIOPS_PATH should be set to the correct f"{os.path.dirname(sys.executable)}/lib/pythonx.y/site-packages/pykhiops/usr/bin" path;

similar to KHIOPS_CLASSPATH to the JAR files; we need to replicate this in order to support non-batch khiops launch from within pykhiops.core

the MPI-related functionality is trickier, as we need to make sure the appropriate MPI implementation library (the same version Khiops has been compiled with) is made available; and just extracting relevant parts from the OS mpich package will not do, as this package also has dependencies which would need to be handled. A potential solution is to rely on the Intel MPI library and its PIP packages: https://pypi.org/project/impi/, for Linux (https://www.intel.com/content/www/us/en/develop/documentation/installation-guide-for-intel-oneapi-toolkits-linux/top/installation/install-using-package-managers/pip.html#pip) and for Windows (https://www.intel.com/content/www/us/en/develop/documentation/installation-guide-for-intel-oneapi-toolkits-windows/top/installation/install-using-package-managers/pip.html).

Anyways, we could also build two packages:

python-khiops which would make the Khiops binaries pip-installable from a wheel.

pykhiops which would depend on python-khiops and install pykhiops itself; then, the pykhiops runner can detect if vendored Khiops exists in the current environment (virtualenv, venv, conda, ...) and, if so, properly set the variables indicated above.

The advantage of this is that the version of the python-khiops PIP package can exactly match the Khiops version itself, and that pykhiops can depend on specific versions (or version minimum values) of python-khiops. Thus, no hack would be necessary to determine the compatible Khiops version for a specific version of pykhiops.

I still would name it pykhiops-bin.

Ok for pykhiops-bin

Roadmap of a potential solution for windows:

Use a windows runner
Decompress with 7zip the Khiops installer
Requires having the Khiops installer and 7zip available somewhere (artifactory? S3 bucket?)
The 7zip installation must be run silently (research the flags of the installer, which depend of his type (NSIS, MSI, etc).
Decopress the MS MPI installer within the contents of the Khiops installer
Copy the Khiops binaries and the MS MPI to a bin subdirectory which will be copied as data by setuptools
A DLL in the same directory of an application is prioritary
If it is already loaded does still have priority ?
The runner intialization accordingly (because the dll is in the same place that the MODL executables
Do not forget to vendor the licences as well

Meeting with LAG:
Defined the roadmap for a first version of the solution to this issue

Vendored binaries have priority over system-wide installations
Windows:
Follow the roadmap above and fully vendor MPI
Linux:
Vendor only Khiops binaries
Clearly state in the installation that MPI version X is necessary to fully use all cores
Expand pk-status to show this info
Vendor also for CentOS
Mac:
Only Docker will be available at the moment, see below
Docker:
Very similar to our pykhiops-cicd docker
Propose as a second option for Linux and as the option for Mac

Technically, for the Linux packaging story, this is what remains to be done:

finalise khiops-env script functionality replication the the "environment initialisation" code of PyKhiops (when vendored Khiops installation is detected);
parse Linux (Debian, RedHat - see below) package metadata to detect the precise version of the MPI(CH) dependency;
add MPI dependency presence detection and warning (if MPI is missing) in the "environment initialisation" code of PyKhiops (just after the detection vendored / non-vendored Khiops is done); replicate this presence detection in the pk-status entry point script;
add the "no-MPI" run logic to PyKhiops: even though the number of CPU cores is greater than 1, if running vendored Khiops and MPI support is lacking, launch the MODL and MODL_Coclustering executables sequentially and issue warning to the user that this is so (and why);
replicate the Khiops binaries extraction logic from the Debian packages, to the RedHat (centOS) RPMs.

Meeting with LAG, BG, SG, VP: Redefined again the short-term roadmap

We abandon the vendoring with pip in favor of a conda packaging (VP leads the exploration)
The reason is that the user would have to install MPI beforehand anyway (at least in Linux) so it defeats the purpose
Now the associated MR !95 would close #30
Questions/Unknowns:
Can we depend of the .deb linux packages ?
It would be again a package-surgery option because conda does not perform system-wide installations
Should we make another packaging option within the Khiops besides Ubuntu, RedHat, Windows x Archi
This would be in the Khiops packaging repo
Has conda and conda-forge enough dependencies for our purpose (MPI and Java?)
Are there any troubles linking any available MPI in the conda repositories.
Can we distribute in conda-forge or should be have our own repository (does GitHub have this option?)
Should we vendor also Khiops Visualization ?
Should python-only code still be available in PyPI ?
I think we should still have it available internally for development (diod repos)
User Instructions:
Install anaconda or miniconda
conda install khiops or conda install pykhiops

On the PyKhiops side, IMHO the short-term roadmap could be:

Build and deliver Conda package for vanilla (Python only) PyKhiops
[Temporary step, pending the availability of a Khiops Conda package] Vendor Khiops binaries by surgery on the Debian package (as explored until now for Pip-based vendoring); the purpose of this is to test 3. below. In the longer run, the vanilla PyKhiops Conda package should depend on the Khiops Conda package
Install the correct OpenMPI version through Conda, by using the existing OpenMPI Conda package. The correct version of the OpenMPI package would be, at first, extracted from the control file of the Debian package (see step 2. above). In the longer run, the correct version of the OpenMPI package would be specified by the Khiops Conda package.

Also, the (py)Khiops Pip package can be installed inside the Conda environment. The Pip package can vendor the Khiops binaries. The right OpenMPI can be installed inside the Conda environment. The right version of OpenMPI can be present in the installation documentation.

Apparently, OpenMPI can be statically built (although the default is to build it dynamically): https://www.open-mpi.org/faq/?category=building#static-build.

What is the impact of this?

I expect this to facilitate vendoring MPI on Linux as well: AFAIU, Khiops would have its own copy of statically-linked OpenMPI which could be vendored without needing a system-wide install.

AFAIU, this is a possibility, but IMHO we would to change the Khiops release (and compilation) process itself:

compile OpenMPI as a static library
Compile Khiops and statically link it to the compiled OpenMPI library
Thus the Khiops binary would be bigger, but it would be self-contained as far as MPI support is concerned.

However, we should check if there is any obstacle to statically linking Khiops to OpenMPI (some code changes would be needed AFAIK, as DLL calling is more involved than statically-linked library calling which is seamless).

Note that compiling statically MPI has drawbacks and it is discouraged
https://docs.open-mpi.org/en/v5.0.x/building-apps/building-static-apps.html
Notably it would make the application fatter and so it would be each spawned process (but maybe it is not an issue)

Yep. I'am also considering keeping the dynamic link to libmpich and, at build time:

from DEBIAN/control, check the minimal libmpich12 version required, as well as the mpich version required (this last one is required for doing mpiexec in khiops-env or equivalent Python port in the LocalRunner)
from apt-cache show libmpich, grep Filename and extract the actual full name of the libmpich12 Debian package
get and "unzip" the libmpich12 .deb file of the package (as done for the khiops-core package)
extract and put libmpich.so.12.x.y shared library in the virtualenv; create symlink libmpich.so.12 to the actual DLL
in the PyKhiopsLocalRunner, set LD_LIBRARY_PATH to point to the virtualenv location where the libmpich12 DLL has been put, so that the MODL executable can find the DLL
a similar manipulation would be done to the mpiexec binary extracted from the mpich Debian package, with the difference that this time the PATH variable would be set to point to the location of the mpiexec binary (e.g. through the env argument passed to Popen).

Using conda, we can have:
0/ Activate conda environment: conda activate <environment_name>
1/ conda install mpich
This installs ~/miniconda3/bin/mpiexec and ~/miniconda3/lib/libmpich.so (among other MPI-related DLLs that AFAIU are not needed, e.g. for Fortran etc.)
2/ Inside ~/miniconda/lib/ we need to create a symlink from libmpich.so to libmpich.so.12: ln -s libmpich.so libmpich.so.12, because MODL expects libmpich.so.12
3/ Launch MODL with the LD_LIBRARY_PATH set to /absolute/path/to/miniconda3/lib. Otherwise, unless libmpich.so.12 exists in /lib/<arch>/ system-wide, the link fails. This is true, whether we are "inside" the conda environment or not. What being inside the conda environment brings us is that mpiexec is readily in the path.

Yes, they are stored in the conda environment, but the MODL binary doesn't look them up in there by default. It's like the conda environment sets the PATH but not the LD_LIBRARY_PATH.
What the conda environment certainly brings us though, is the mpiexec executable, which is the one in the conda environment.

Ok, so it is possible to set LD_LIBRARY_PATH via the conda script ?

Or at least modify khiops-env at install time so everything is ok ?

First off, conda does not set the LD_LIBRARY_PATH by default upon activating the environment.
However, there are two possibilities:
1/ [not applicable in our case in its own] tweaking the environment itself, by adding activate.d/env_vars.sh (for variable set-up) and deactivate.d/env_vars.sh (for variable unset) to the environment (see https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html#macos-and-linux)
2/ [applicable in our case, IMHO, by also leveraging 1/] customizing the installation process, by adding pre-link / post-link scripts for variable setup upon package installation, and post-unlink scripts for variable unset after uninstall (see https://docs.conda.io/projects/conda-build/en/latest/resources/link-scripts.html).
I would go for using:

post-link for tweaking the current conda environment (given by CONDA_PREFIX) for adding the
{activate,deactivate}.d/env_vars.sh, just after installing the khiops package.
post-unlink for canceling the env_vars.sh tweaks just before uninstalling the package.

For a discussion, see also https://stackoverflow.com/q/46826497.

Regarding the khiops-env, khiops and khiops_coclustering scripts, IMHO there are two options:
1/ tweaking the three scripts from the post-link script (which is run on conda install so that the LD_LIBRARY_PATH is set); this is the most conservative approach with respect to the current status, but:

it is not portable as it only works for Linux (although Windows versions could be tweaked in the same way); the most portable approach would be to code the khiops* script tweaking logic in a Python function that would be called from the Linux and Windows versions of the post-link script;
we would still need to include, in the PyKhiopsLocalRunner, code for distinguishing between system-wide Khiops installation (e.g. via the Debian / Ubuntu package or the Windows installer) and vendored Khiops installation via conda.

2/ [as written in the previous comment] we only tweak the conda environment, make do without the three khiops* scripts and replicate their logic in Python as needed (this had already been started previously); this requires adding more logic to the local runner, but IMHO it is more portable between OSes and less involved from the Conda scripts perspective.

First trial:

upon building the Conda package (by packaging the Pip package into the Conda package):

install build-time dependencies: conda-verify, python, setuptools, wheel

build the package wheel

"install" the package wheel into the Conda package

upon installing conda package:

install run-time dependency: mpich

unpack the package wheel

do some post-install actions, in the post-link.sh script:

symlink $PREFIX/lib/libmpich.so (installed by the mpich conda package) to $PREFIX/lib/libmpich.so.12 (required by MODL):

create and make executable the $PREFIX/bin/MODL shell script which just does LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH $STDLIB_DIR/site-packages/pykhiops-bin/MODL "$@"

do the same thing for MODL_Coclustering

As of now, Conda packaging has been implemented for PyKhiops + vendored Khiops, which supports Ubuntu Linux.
Two Conda packages have been implemented for this:

pykhiops-bin, which:

provides support for vendoring Khiops

at build time:

depends on the python, setuptools and wheel Conda packages

builds the setuptools/ Pip wheel file of the package; to this end, it uses the setup.py file to:

download, from the DIOD cetral repository, the Ubuntu Debian package of khiops-core whose version most closely matches the version of the specified pykhiops-bin Conda package (which is the same as the version of the latest PyKhiops release)

extract, from the downloaded Khiops Debian / Ubuntu package, the MODL and MODL_Coclustering binaries

Pip-installs (without Pip dependencies) the wheel file into the pykhiops-bin Conda package

at run time:

depends on the mpich and python Conda packages

installs the pykhiops-bin Conda package in the current Conda environment

provides the MODL and MODL_Coclustering executables in the current PATH of the current Conda environment

provides proper MPI(CH) support in the current Conda environment

pykhiops, which:

provides support for the PyKhiops Python library

at build time:

depends on the python and setuptools Conda packages

source-builds the Pip package of pykhiops

source-installs the pykhiops Pip package into the eponymous Conda package

at run time:

depends on the pykhiops-bin Conda package, as well as on the other Python Conda packages (scikit-learn and pandas)

installs the pykhiops Conda package in the current Conda environment

Note 1 The current setup of having the Conda packages based on the Pip/setuptools mechanics has the advantage that it allows for three installation scenarios:
1/ the user already has Khiops and MPI support installed system-wide via the Ubuntu / Debian package; in this case pip install pykhiops just performs a source-install of the PyKhiops Python library in the current Python virtualenv; this is the current officially supported scenario, which will continue to be supported
2/ the user already has MPI support installed system-wide via the Ubuntu / Debian mpich package; in this case, pip install pykhiops-bin installs vendored Khiops binaries in the current Python virtualenv, and pip install pykhiops installs the PyKhiops Python library as in scenario 1/. Please note that pykhiops-bin is not a dependency of the pykhiops Pip package, so that scenario 1/ is also supported with the same pykhiops Pip package; vendored Khiops support must be explicitly installed
3/ the user has neither Khiops, nor MPI installed system-wide; in this case, conda install pykhiops installs the mpich Conda package that provides MPI support within the Conda environment, pykhiops-bin which provides vendored Khiops support within the Conda environment, as well as PyKhiops Conda dependencies pandas and scikit-learn.
Note 2 The vendored Khiops installed in a Python virtualenv or in a Conda environment always takes precedence over any system-wide Khiops installation. Likewise, the MPI support installed in a Conda environment always takes precedence over any system-wide MPICH installation.

Meeting with Bruno G.:

package Khiops on Conda => Conda package artifacts would be built according to a per-architecture CHANGELOG.md class Coclustering.khc doc gitlab_ids_to_github_numbers.csv gitlab_token.txt issue_comments_github_2.csv issue_comments_github.csv issue_comments_gitlab.csv issue_ids_gitlab.csv issue_numbers_github.csv khiops-pykhiops-meta-pykhiops_issues_2023-07-03.csv LICENSE.md MANIFEST.in open_issue_ids.txt pk_samples pycache pykhiops pykhiops.egg-info pyproject.toml README.md resources script.awk scripts setup.cfg setup.py test-requirements.txt tests token.txt versioneer.py per-OS build matrix; the Khiops Conda package would provide the MODL and MODL_Coclustering binaries, plus the MPI support
pykhiops-bin (which currently relies on the OS packages, viz. Ubuntu / Debian Linux) would be superseded by the Khiops conda package (see previous point)
the pykhiops Conda package would depend on the Khiops Conda package; the version of this dependency can be specified in a standard way in Conda pykhiops package's metadata; this would be less brittle than the current heuristic that is used for finding the "closest" version of the OS package that matches the current pykhiops version
one point to untangle: optional dependencies, namely boto3 and the like, for remote access: unlike Pip (or Debian, for that matter), Conda does not support these directly; however, Conda outputs could be used [this needs to be explored]; see https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#outputs-section
other point: CentOS / RedHat packages: for these, there is a package build and install constraint than an MPI-enabled executable contain the _mpi* string in its name, viz. MODL should be called MODL_mpich_...; question: where can the khiops RPMs be found?
a last point: Mac OS support: currently, there is no GitLab runner supporting Mac OS, and no Mac OS package that could be used for getting the Mac OS binaries

With respect to optional dependencies, if no mechanism equally convenient as pip's extras is available I would just let the khiops conda package as the only option and document which of those options would be available by default.

What does "by default" mean here? In the Conda world, normally, a dependency is either required or it is not at all; AFAIK, there is no default behavior vs. customizable behavior. What we can do however, AFAIU, is to specify a package, plus metapackages on top of it, which aggregate it with other Conda packages.

Experiment attempted today: installing the pykhiops (with the pykhiops-bin Conda dependency) Conda packages on CentOS Stream 8.
Conclusions:

the Conda package installation itself works as on Ubuntu

however, as expected, the MODL and MODL_Coclustering executables fail, because they have been obtained from the Ubuntu / Debian package and are thus not suited for running on CentOS; more precisely:

MODL -v yields:

``/<path/to/conda/environment>/lib/python3.11/site-packages/pykhiops-bin/usr/bin/MODL: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /<path/to/conda/environment>/lib/python3.11/site-packages/pykhiops-bin/usr/bin/MODL)

thus, MODL is not linked to the appropriate LIBC, which is expected, as the LIBC is not the same on Ubuntu vs CentOS

however, if Khiops is built within Conda, the proper libc will be selected by Conda according to the Linux distribution it is compiled on

can we cross-compile Khiops (compile it on Ubuntu, targetting CentOS) from within Conda (using the Conda-based workflow)? See https://medium.com/@Amet13/building-a-cross-platform-python-installer-using-conda-constructor-f91b70d393 and https://conda.github.io/constructor/howto/ for a starting point

Isn't easier to have a CentOS image to make the CentOS build ?

It should be, AFAIU. And it should be doable in a Docker container IMHO (if all we need is cmake, libc, mpich, plus conda of course).

But the cross-compilation path could be potentially interesting for other, less accessible targets, like Windows or MacOS.

Cross-compilation seems easier for unix-likes. For Windows it seems very difficult.

Right, apparently even in the article referenced above, the Windows installer needs to be built on Windows. The advantage of Conda constructor however, seems to be that it abstracts away much of the nitty-gritty details of building the Conda installer.

The PyKhiops Conda package seems to work with the native (Ubuntu) khiops-bin Conda package provided here by @bruno.guerraz : https://repos.tech.orange/ui/native/khiops-virt-conda-stable/
The executables are in place, pk-status works; all pykhiops sklearn end-to-end tests are green, with fixture-based mocks disabled and native Khiops calls enabled.
Thus, with the native khiops-bin package we obtain the same behaviour, on Ubuntu, as with the pykhiops-bin package (which is extracting the binaries from the Debian package). The only difference is in the Khiops version (10.1.1 for pykhiops-bin because of the version finding heuristic, 10.1.3 for khiops-bin). This is OK for the pykhiops package, as it only needs to specify that the khiops-bin>=10.1.1 (that is, the version of pykhiops itself).

The pykhiops Conda package works, along with the khiops-bin Conda package, on both Ubuntu 22.04 and CentOS Stream 7 Docker containers: python -m tests.test_samples works as expected in both containers, both with the two Conda packages installed in a Conda environment.
Hence, the khiops-bin package (as built by @bruno.guerraz on Ubuntu) transparently works in both the Ubuntu and CentOS Docker containers. AFAIU, this is because Conda does some patchelfs on the MODL and MODL_Coclustering binaires, so that they work with the Conda-provided dynamic library dependencies, like GLIBC, MPICH, etc.
Now we need to industrialize all this:
1/ Create relevant Khiops repository on the artifactory; perhaps https://repos.tech.orange/ui/native/khiops-virt-conda-{stable,unstable}/ will do?
2/ Create Conda channel in this repository; AFAIU, this is supported by JFrog.
3/ Push, via cURL, the *.bz2 packages to this channel; this should allow to regenerate the Conda channel index here.

Following this week discussions, the following steps are to be done:
1/ Precisely list the supported target platforms:

architectures: 64 bit
OSes:
Mac OS (version minimale: ??)
Ubuntu Linux (version minimale: 20.04 ?)
Windows (version minimale: ??)
2/ Solve the runner availability issue, notably:
Windows runners: available on GitLab DIOD and GitLab.com;
MAC OS runners: not available on GitLab DIOD; available as beta on GitLab.com; provision dedicated hardware for the runner?

3/ Push current khiops-bin Conda package on khiops-labs-virt-conda-unstable, so that we can: CI/CD-ize the current pykhiops, pykhiops.s3 and pykhiops.gcs Conda package manufacture and pushing on the khiops-labs-virt-conda-unstable repository (the khiops-bin package is needed even for manufacturing the pykhiops* packages)
4/ Add vendored Khiops support for Windows and Mac OS in the PyKhiops Python runner; to this end:

check how the relevant environment variables (notably, for CPU counting) are computed on these platforms
check what the MPI command is on these platforms

5/ Sync-up with @bruno.guerraz on Khiops releases: should both khiops-bin and pykhiops Conda packages be hosted on the same channel, khiops-virt-conda-{stable,unstable} (not khiops-labs-virt-conda-*)?

regarding architecture, should it be compatible with both x86 and arm on MacOS ? ARM is "obvious", but x86 Macs were still manufactured last year...

Finally the vendoring is achieved with one self-contained conda-package that we create.