base: Remove sfctl from the base image

Even after the removal of this tool from the image, users can still install sfctl manually by running the command:
pip install sfctl

@surajssd this tools is documented as pre-installed in cloud-shell, so we need to update the docs: https://learn.microsoft.com/en-us/azure/cloud-shell/features#azure-tools


Display account in app nav whenever signing via API

Some more testing revealed that this https://github.com/leather-wallet/extension/issues/4599 has different has a different result on Stacks compared to Bitcoin.
Reproduction steps on Bitcoin dapps

Sign in to gamma.io on account 1
Then on the leather extension switch to account 2
Try to buy an ordinal or create an inscription
See the screen pop up with Account 2 top left (expected is account 1).

A user reported that using unisat they signed transactions with another account than expected. I think it is caused by this. When you mint an inscription the transaction is signed with the active account on the wallet rather than the account signed in with on the dapp:

Trying the same thing buying an ordinal with unisat (signed in with account 1 and account 2 active will throw an error):

Trying the same thing on Magic Eden and Gamma resulted in no transmission of the transaction.
I tested minting a text inscription on Magic Eden after clicking confirm, the confirm screen closes but nothing is transmitted.

On Gamma I tested buying a print and the result was similar as on Magic Eden, clicking confirm closes the confirm screen but no transaction is transmitted.

Possible solutions: (a) better error handling, (b) the ME and gamma can show similar errors (c) (perhaps suggest them to make sure the active account on the extension is the same), (d) and allow trying again (not possible on ME without a refresh). (f) It would be great if the wallet could detect users who are trying to send with a different wallet and then allow an easy way for the user to switch.

Gamma.io doesn't seem to require a specific account index on sign in:
https://github.com/leather-wallet/extension/assets/22010816/9d8e792d-9a82-4d33-a93a-b882fbcb2bcc
cc @314159265359879

with bitcoin it will sign in with the account that is active in the extension when you click connect. Then a user can switch in the extension and be surprised the transactions are being signed by a different address then expected. @edgarkhanzadian
Related stuff also due to reaching API limits

The same name can be displayed with different account numbers.
The active account (what ever is shown in the extension modal) is displayed in the top of the popup to sign. But what should be shown is the account the dapp is connected with. And that should be the only account that can be signed with (as is the case with Stacks network).

@314159265359879 does this fix require an API implementation change on the app side, or is it wallet side purely?

Ping @314159265359879

@markmhendrickson This is partially wallet side, when it comes to the visual issue https://github.com/leather-wallet/extension/issues/4859#issuecomment-1982070964 possibly fixed with https://github.com/leather-wallet/extension/pull/4923
However I believe that bitcoin issue (title) requires API implementation changes to prevent. It could be covered by the modern wallet API SIP if this is scoped in https://github.com/stacksgov/sips/pull/166#issuecomment-2023848006

@314159265359879 is this still causing a problem or has it been fixed by https://github.com/leather-io/extension/pull/4923 ?

@pete-watters After a recent redesign you can nolonger see the account number/name on the approve transaction screen. So you can only know if you're signing with the right account after confirming.
The transaction is not signed. When I am signed in on Gamma with Account 1, and have Account 2 active in the extension. This is not fixed. The result is just different now.
(current) Reproduction steps
0. Switch extension to account 1

Sign in to gamma.io (you will sign in with the active account = account 1)

Then on the leather extension switch to account 2

Try to buy an ordinal or create an inscription: for example one of these https://gamma.io/prints/c5528f39379cbaa6380a38c129c2788d4ca97259f15ddf27e6b0bc3a4568a569i0?tab=presale

See this popup (without an account number or name)

Click confirm and see

I propose the following solutions:
0. short-term fix, let the user sign with the signed in account rather than the active account.

Warn users when they're not signed in on the right account, this likely requires additional API's: https://github.com/leather-io/extension/issues/4891, Whenever there is a difference between the active account (on Leather extension) compared to what they are signed in with on the dapp, warn the user and ask for their intent (did they mean to sign with account 1 or account 2, then let them switch to it).

Let users choose an account when they connect to a bitcoin dapp (as we have with Stacks connections): https://github.com/leather-io/extension/issues/4182

Show the account name/number + addresses and balances on every screen especially on the approval screen because then users can identify if they're on the account intended. @mica000 @fabric-8

Let's implement your third suggestion as a quick fix of sorts, reverting to the app nav's display of the account used for signing?

short-term fix, let the user sign with the signed in account rather than the active account?

As far as this solution, we already provide it. However, the app needs to indicate the "signed in account" while triggering API calls for signing transactions, and it seems Gamma isn't doing this. So we'd need them to upgrade their implementation to use that parameter?

I linked this bug as it relates to the same thing.
I will make a change so that instead of showing the logo on these screens we show the users account

I noticed the same issue on Luminex.io when signing a runes transfer transaction. Connected with account 1 on the dapp. Switched extension to account 2. And the transaction gets rejected on device. After switching back to account 1 I was able to sign the transfer transaction normally.

short-term fix, let the user sign with the signed in account rather than the active account?

As far as this solution, we already provide it. However, the app needs to indicate the "signed in account" while triggering API calls for signing transactions, and it seems Gamma isn't doing this. So we'd need them to upgrade their implementation to use that parameter?

@markmhendrickson want to add a link to docs where devs can read more about how to resolve this issue?

See https://leather.gitbook.io/developers/methods/getaddresses#accounts

I've made a small change here so that instead of showing the logo on the sign PSBT screen we show the users account and allow them to change the account.
We are still just showing the logo on the initial message signing screen:

Do I need to update that also? When implementing the global header, it was unclear how some headers should display so I may have made more mistakes. I believe it a good idea to audit these when working on approval UX

Do I need to update that also?

Yep! Let's update there, too 🙏 The general idea is that we should show the account in the top nav wherever the user is signing something (transaction or message).

@fabric-8 @mica000 could one of you review the previous comment that @pete-watters links here (https://github.com/leather-io/extension/issues/4371#issuecomment-1919114939) in case there requires any further design input on how the header details work?

@fabric-8 @mica000 could one of you review the previous comment that @pete-watters links here (#4371 (comment)) in case there requires any further design input on how the header details work?

Thanks @markmhendrickson . That comment is a bit outdated now so I will gather some info on the current state of things so we can review it. I've updated my PR so that it handles the first signing step also.
My code works by configuring the Header to show items based on the RouteUrl.
Before we were showing account info only on:

RouteUrls.TransactionRequest: /transaction
RouteUrls.ProfileUpdateRequest: /update-profile
RouteUrls.RpcSendTransfer: /send-transfer

I have updated it to also include:

RouteUrls.RpcSignPsbt: /sign-psbt(That's the APPROVE TRANSACTION popup first reported here)
RouteUrls.RpcSignBip322Message: /sign-bip322-message (That's the SIGN MESSAGE popup I later mentioned)

There are other places I'm not sure if we need to show it, for example on the summary / choose fee pages:

Based on the route names, these six routes appear to pertain to screens during transaction or message-signing flows. So yes, let's show the account in the nav there, too.

These may be a good opportunity to ensure all of these relevant routes / views are included in our views database. If you could include a screenshot of each per entry, that'd help evaluate them.

These may be a good opportunity to ensure all of these relevant routes / views are included in our views database. If you could include a screenshot of each per entry, that'd help evaluate them.

Yes I think that's a good idea. I'll work on gathering that info and documenting it as I go. We have about 16 popup routes so it seems like we want to show that account info more often than not. I'll do an audit and take notes and we can decide on it.

@markmhendrickson - FYI I merged my code that updates the header for sign-psbt and sign-bip322-message.
I will audit the others but I opened a separate task for that here https://github.com/leather-io/issues/issues/157 .
That way we can get this more urgent improvement out first and fix the others once I have documented and tested them all


Selenide throws ElementNotFound exception on not related  WebDriverException e.g. element is not clickable

Guy from slack chat ran into issue.
When he tried to click to the element he got ElementNotFound exception BUT element exists on the page

com.codeborne.selenide.ex.ElementNotFound:
Element not found {By.linkText: Выбрать контрагента}
Expected: exist
at ru.BlrwblTest.createBlrwbl(BlrwblTest.java:43)
Caused by: org.openqa.selenium.WebDriverException:
unknown error: Element ... is not clickable at point (1195, 32). Other element would receive the click: ...

It is not ok. Need fix this and research other possible cases

I've updated Selenide recently from older version and today saw similar problem.
Element not found {By.xpath<EMAIL_ADDRESS>Expected: exist         ... Caused by: WebDriverException: unknown error: Element is not clickable at point (1055, 1820) 	... Caused by: org.openqa.selenium.WebDriverException: unknown error: Element is not clickable at point (1055, 1820)   (Session info: chrome=61.0.3163.100)
For HTML:
`

`
And for select:
span.hover().click();
In Chrome page didn't scrolled down to element, left stood on header and so element was not clickable. Tried without hover and waiting for element be visible - all had the same trace.

@robben1234 have you tried to update chromedriver to the latest version? Try it. It may help you.

@BorisOsipov yeah, seems that it was the issue for me. Thanks for your help.

@BorisOsipov I faced the same issue. Unfortunately this bug goes to Selenium itself. Because there is Caused by: org.openqa.selenium.WebDriverException: unknown error:

@simple-elf yep.
But problem that Selenide says "Element not found" in such a case - it's wrong.

    else if (lastError instanceof WebDriverException) {
      if (lastError.getMessage().contains("is not clickable at point"))
        throw new UIAssertionError(lastError.getMessage().replace("unknown error: ", "").split("\n")[0], lastError);
      else
        throw webElementSource.createElementNotFoundError(exist, lastError);
    }

There is an example, how we can throw different exception. But here we need new exception class - ElementNotClickable

If this is happening in Chrome with the error "element not clickable" I found this solution:
    public void click(WebElement element) {
        js.executeScript("arguments[0].click();", element);
        //this alternate click method can fix the Chrome driver issue "Element is not clickable"
        //https://stackoverflow.com/questions/11908249/debugging-element-is-not-clickable-at-point-error
    }

@jpratt2 Thank you. Actually you can enable this mode with this setting: Configuration.clickViaJs = true;

Or how about extending .click with a try catch?
Something like
try {
      element.click();
    }catch(Exception ex){
      executeJavaScript("arguments[0].click();",element);//sometimes Chrome requires this for the "element not clickable" error
    }

Something to consider
try {
      element.click();
    }catch(Exception ex){
      executeJavaScript("arguments[0].click();",element);
    }

@jpratt2 As write before - to click via JS just pass configuration parameter.
It calls method:
protected void click(WebElement element) {
    if (clickViaJs) {
      executeJavaScript("arguments[0].click()", element);
    }
    else {
      element.click();
    }
  }
``
Solution that you provide bad, because if exception will thrown for click method - you can't handle it, and represent for user. Same for catch block. What if something goes wrong inside JS executor.

agreed; l think this ticket can be marked complete.

nope. it still should be fixed in selenide.

@simple-elf yes it is.


Service 'refresh_vehicle_data': API error. 'refresh_data' works but does not update

Using HA core-2021.12.7 I activated the audiconnect service to regularly update the data, using the VIN.
Contrary the description on this GitHub' site only service 'audiconnect.refresh_data' replies with data. I used NodeRed to verify response, which is a Unix timestamp, nicely updating when I call the service:

The node itself is set up like this:

When I created a LoveLace card, like the one on 'GitHub', it worked fine for the first day. But since two days no updating takes place anymore, with my HA Log showing the following:

Any idea whether this is a bug or suggestions for a different setup?
Moreover: is 'refresh_vehicle_data' deprecated or changed?

Probably related to #107

Just wanted to bump this -- as of 1.0.0 this is still some kind of problem. The docs say that the service is audiconnect.refresh_vehicle_data, but this fails. audiconnect.refresh_data does work, but it is unclear to me if it actually does anything (last update time is not changing).
The Spook integration monitoring the configuration is complaining that the audiconnect.refresh_data service does not exist.

Just wanted to bump this -- as of 1.0.0 this is still some kind of problem. The docs say that the service is audiconnect.refresh_vehicle_data, but this fails. audiconnect.refresh_data does work, but it is unclear to me if it actually does anything (last update time is not changing).
The Spook integration monitoring the configuration is complaining that the audiconnect.refresh_data service does not exist.

refresh_cloud_data will update data from the cloud, but as you noted, it will not force a vehicle refresh. It only pulls the latest data that the cloud received when the vehicle last 'checked-in'. Last_update reflects the last time the vehicle checked-in.
#330 is for refresh_vehicle_data issue catch all.
Closing this issue but please let me know if I'm missing another issue in here.


Wrong menu item underlined

Go to: https://react-hook-form.com/api/#useWatch
useFieldArray menu item is underlined instead of useWatch

Go to: https://react-hook-form.com/api#useFieldArray
useWatch menu item is underlined instead of useFieldArray

thanks @michalbundyra

you taking care of this one Mr.Bill?

could you take a look at this one? @pmaier983 it's not trivial

The following PR fixes the issue: https://github.com/react-hook-form/documentation/pull/376


Circle Constructor (Circle, ThickCircle, SolidCircle)

Something along these lines...

So pathDrawer needs Points. This is going to be like rectangle, isn't it?

Is there anything you'd like me to fix between 544-568 of Driver.hs? I know they're not really used, but...

Yeah, we can clean up the properties later, as we talked about in the last meeting.


Create a new website for Onix developers

Success Definition for Beckn-ONIX website

Visiting https://onix.developers.becknprotocol.io should open web page
This webpage will be part of becknprotocol.io website sitemap. This is not a separate website
Look and feel of website will be like a typical SaaS product. It will have hero image, screen shots etc.(lifesight.io and brandflow.io as examples of SPA. One more reference - https://web.archive.org/web/20230714040657/https://www.getmoda.io/).
It has to have the following links
a. Link to github repository of beckn-onix
b. Link to the user guide and other docs in beckn-onix
c. It has to get contents from user guide but not redirect. (As if the user guide is part of the site). There should be single source of truth for content.
d. Link to the demo video (The one Sonam's team is creating now)
Clear call to action for
a. asking community support
b. wanting to contribute
Should have a FAQ section

Features to be planned for future releases :

Testimonials (Mulearn, Akhil ??)
Newsroom section
New release section
Marketing video for ONIX (sub one minute)

Dates:
April 3 - Figma iteration 1 - Send to Sujith and Ravi
April 3 - Feedback incorporated in Figma for review
April 4 EOD - Staging implementation - Sujith and Ravi
April 5 EOD - Final website
Todos:

Ravi will clarify on the final URL to use for the landing page.
Content for FAQ - Venkat/Ravi
Sonam to get additional landing page content from Ravi

Sonam has been given all the required data.

Same as #16


add lsp tests for redeclaring instance/class variables

Motivation

I am getting bizarre results for these tests locally and want to make sure I'm not missing something fundamental.
Test plan

See included automated tests.

(I don't understand why we're getting such bad locations for these error messages)


Too many system sound streams created while this extension is enabled

After installing you extension, I noticed Firefox started creating many audio streams in Pulseaudio (system sound server on Linux) which weren't producing any sound. After about 40 of them, Pulseaudio started having problems mixing the streams.
The problem seem to be the creation of the new AudioContext here https://github.com/magic-FE/translate-man/blob/66e47140b71b4f405c485e51f18ec3b262c8a2ca/src/store/index.js#L56 that is created for every loaded page, even for pages in an iframe!
Can you refactor it somehow so that AudioContext is created just before the extension needs to play sound and the context has not been created already?!

The problem has been fixed in next version.
thx for your feedback.


Clarify that O.C. members have authority over team membership

We have had a couple recent cases where a member of the oversight
committee saw a need for adjustments to team membership and made those
changes without going through the formalities discussed in our
CONTRIBUTOR_ROLES document.
We believe that is acceptable at this early stage of the
project. Update the document to make it clear that this is an expected
and approved part of our governance at this time.
Signed-off-by: Russell Bryant<EMAIL_ADDRESS>

LGTM as well.
Minor bit feedback that is non-blocking: should we notify elsewhere than just oversight committee that team membership has changed? I think this may be overkill but an FYI only post in #admin in InstructLab Slack is also likely useful for communicating well and widely. My .02 EUR.

LGTM as well.
Minor bit feedback that is non-blocking: should we notify elsewhere than just oversight committee that team membership has changed? I think this may be overkill but an FYI only post in #admin in InstructLab Slack is also likely useful for communicating well and widely. My .02 EUR.

sounds reasonable, depending on the nature of the change.


Default for --geopm-ctl command line option.

When using geopmlaunch, if the --geopm-ctl option is not provided, launch the controller with the process mode.  The current implementation does not launch the controller unless this option is provided, effectively passing the command line to the underlying job scheduler.

Make a default report as well.


add a property for animation in commands json template

improve this section https://github.com/twitter/cli-guide.js/blob/develop/src/cli-guide.js#L581

this issue is part of #75

done!


Added option to output probability map from CLI

All CI tests ran fine, but Im also running some local tests first to verify that setting threshold -1, which the tests do not cover, works as intended.
Adding this to the tests will just make the full CI runtime MUCH slower, so I will not do this at this time.


Refactor scripts to gatsby-source-github-releases

Each release should probably get its own node. This way you can make single page per release if you want to.

I can share with you some code from the undefined that I wrote to create a source for simplecast RSS feed for the podcast site

Here is my simplecast source plugin for gatsby.
// ./plugins/gatsby-source-simplecast/gatsby-node.js
const axios = require('axios');
const crypto = require('crypto');

const digest = i =>
  crypto
    .createHash('md5')
    .update(JSON.stringify(i))
    .digest('hex');

exports.sourceNodes = async ({ actions }, options = {}) => {
  const { createNode } = actions;
  const { id, apiKey } = options;
  // Create nodes here, generally by downloading data
  // from a remote API.
  const { data } = await axios(
    `https://api.simplecast.com/v1/podcasts/${id}/episodes.json?api_key=${apiKey}`
  );
  data
    .filter(datum => datum.duration != null)
    .forEach(child => {
      createNode(
        Object.assign({}, child, {
          id: `${child.id}`,
          parent: null,
          children: [],
          internal: { type: 'Episode', contentDigest: digest(child) },
        })
      );
    });

  // We're done, return.
  return;
};```

Done 👍


Make sure attachments always use the public asset host

Attachments are always served by the whitehall-backend machines because
the NFS mount they are stored on is not available to the
whitehall-frontend machines.  This means any rendered page (such as CSV
previews) is rendered with by that rails app, and gets the admin assets
host.  The CORS settings for the admin asset hosts means that the browser
will reject those assets as not being available to pages on the public
site and so styling and functionality breaks.  We change the asset_host
for production.rb to use a proc that makes sure to always use the public
asset host for any attachments paths (those with system/uploads in the
path) and this should fix the problem.

LGTM
For posterity, this PR was created as part of this incident:
https://docs.google.com/document/d/15xTawGPq1UFJ5e6Zi6PCJciZVZrpUYuXAXbiFm921PA/edit#
This may be something for the incident review, but perhaps we could look at extracting these asset_host procs into a class and unit test that to mitigate future regression. We can potentially do this later.


New 'pretty' recipe format

This pull request adds a new 'pretty' recipe configuration format so that URLs are slightly more readable.
The current recipe format is simply serialised JSON. A contrived example with three random operations looks like this:
[
  { "op": "From Hex",
    "args": ["Space"] },
  { "op": "Pad lines",
    "args": ["Start", 5, " "] },
  { "op": "Strings",
    "args": [3, false] }
]

When added to the URL, this has to be percent-encoded and ends up as this mess:
#recipe=%5B%7B%22op%22%3A%22From%20Hex%22%2C%22args%22%3A%5B%22Space%22%5D%7D%2C%7B%22op%22%3A%22Pad%20lines%22%2C%22args%22%3A%5B%22Start%22%2C%225%22%2C%22%20%22%5D%7D%2C%7B%22op%22%3A%22Strings%22%2C%22args%22%3A%5B%223%22%2Cfalse%5D%7D%5D

Needless to say, this isn't particularly readable. The new format attempts to be as compact as possible, whilst improving readability. It relies on various special characters that do not need to be escaped in the fragment (#) or query (?) parts of a URL, as defined in RFC 3986. The above example looks like this in the new format:
From_Hex('Space')
Pad_lines('Start',5,' ')
Strings(3,false)

When it is used in the URL, newlines are removed and only characters which need to be escaped are percent-encoded:
#recipe=From_Hex('Space')Pad_lines('Start',5,'%20')Strings(3,false)

This saves space and hopefully looks a little less confusing. Complex CyberChef recipes can now be shared without the link looking quite as much like an XSS attempt...
Backwards compatibility with the serialised JSON recipe format has been maintained so old links will still work.

This is a good change, I have got some pushback in the past for suspicious looking URLs so this is a welcome change.
I'm glad you have maintained backwards compatibility with JSON recipe links, very nice work.


fix: add CAP_NET_BIND_SERVICE to flake

Add CAP_NET_BIND_SERVICE capability so leng can bind to port 53 while the service is running as a dynamic user

I can't merge, its your repo 😃

My bad! I thought my approval might have been enough


Check if homebridge is running

Hi,
So I was wondering, if there is any command to check if homebridge is running?
When I use the command:
service homebridge status
homebridge.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
althought I just started homebridge and it's running and working.
and if I use
service --status-all
then homebridge doesn't show up in the list.
Because I would like to somehow check if homebridge is still running and maybe I will have it displayed somewhere thats its still running.
Thanks

Did you install homebridge as systemd or initd?
If systemd, Try sudo systemctl status homebridge

none of them I always start the homebridge by hand.

If you start homebridge by hand. The terminal will show if it's running? If there's error the terminal will show as well?


Prowlarr rss scan fails if response takes too long

Prowlarr rss scans fail for one of my indexers that takes a long time to respond.
Cross seed just spits out Failed to reach http://prowlarr:9696/2/api.
I timed the request with curl a couple of times, and it took about 35~40sec to complete on average
time curl -s "http://prowlarr:9696/2/api?apikey=[REDACTED]" > /dev/null
real	0m35.764s
user	0m0.010s
sys		0m0.033s

So is there a way to increase the timeout, so longer requests don't fail?

dupe of #386


Add metrics and progress parameters for the fine-tuning process.

Use these indicators to fine-tune the visualization

Merged. Thanks for your contribution.


Fix yui_change_screen() to match 'document' naming pattern

screens were renamed to documents in a prior version, but yui_change_screen() did not get updated to match, and should be updated to reduce user confusion

Actually I remember why I did this -- yui_document is represents the gml object displaying a screen document, but screen refers to the contents of the document. yui_change_screen changes the screen associated with a document, it doesn't change it to a different document. So I'll leave this as is.

Actually I remember why I did this -- yui_document is represents the gml object displaying a screen document, but screen refers to the contents of the document. yui_change_screen changes the screen associated with a document, it doesn't change it to a different document. So I'll leave this as is.


How about an example in Code analysis solution property page?

It would be helpful if this page contained an example.

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

ID: efd1e8a4-67b0-57f9-7026-dab24253f7a9
Version Independent ID: b04dd946-edef-3bbc-ebd1-b6ac43d19689
Content: EditorConfig versus analyzers - Visual Studio
Content Source: docs/code-quality/analyzers-faq.md
Product: visual-studio-windows
Technology: vs-ide-code-analysis
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@dombat -- Dominic, thank you for your question.  Please clarify the kind of example you'd like to see.  Meanwhile, consider these resources:

Visual Studio on Q&A
Visual Studio MSDN Forum
Stack Overflow
Reddit

The code below links to another page. When you go there, nothing is mentioned about code analysis, so we don't know how to create one.

For sharing rulesets across multiple/all projects in a solution or a repo, we recommend defining a property group with CodeAnalysisRuleSet property in a shared props/targets file or Directory.props/Directory.targets file. If you don't have any such common props or targets that all your projects import, you should consider

An example CodeAnalysisRuleSet  block would be helpful.

The doc on custom MSBuild settings doesn't have many scenario-specific examples.
We do have an example here: https://docs.microsoft.com/en-us/visualstudio/code-quality/using-rule-sets-to-group-code-analysis-rules?view=vs-2019#specify-a-rule-set-for-a-project
I will add a link to this in the doc.

Doc fix should be live by noon, 12/17


Truck mix pallete

how is mixed pallet placement inside the truck?
is it possible?

No. It is not possible at the moment.
However, this feature is currently being developed.
It will replace existing truck pallet loading.
Regards,


9pin bus cable protocol

Hi, I am trying to find the protocol used in the Xiegu G90 body separation cable series and the head or the GSOC.
Does anyone know how to communicate? It looks like a simple serial bus, but not if anyone has been able to understand what protocol it uses.
i have done some testing with my g90. One of the very easy is to disconnect the head with the radio on. The radio kept going and listening to what I was tuning into.
This makes me think that the heads are simply a remote control of the body.
If this is true, it should be easy for someone with enough knowledge to make software capable of emulating the head, or adapt one of the sdr receivers...
The hardware needed would be to adapt the 9-pin bus signal (data and audio) to a USB port that connects the PC. I don’t think that’s at all complicated.
So, has anyone looked at how the G90 serial bus that connects the body and head works?

There is some info here:
https://xiegug90.groups.io/g/TechnicalAnalysis/files/Head to Radio Protocol

Great progress seems to have been made with this specific topic here: https://github.com/zeroping/xiegu-g90-headprotocol/
This should provide the necessary knowledge to enable creating a "CAT" interface between the GSOC and G90 body.


About encoding problems

Hi,
Thanks for the great work, but it seems to have some encoding problems, when I set the table label to:
table = contrib.table({
        label : '你好',
    })

It just didn't display as it should be, any ideas? Thanks.

Can you send a screenshot? If the characters are not displayed,  does it
also happens with blessed.box?
On Jun 9, 2015 1:59 AM, "Justin Ma"<EMAIL_ADDRESS>wrote:

Hi,
Thanks for the great work, but it seems to have some encoding problems,
when I set the table label to:
table = contrib.table({
label : '你好',
})
It just didn't display as it should be, any ideas? Thanks.
—
Reply to this email directly or view it on GitHub
https://github.com/yaronn/blessed-contrib/issues/50.

Here is a snapshot for the unicode characters problem:

Thanks!

Thanks Justin
I won't have access to check this in the next 2 weeks.
Please try to add a blessed box element with the same content (try the
blessed hello world). Possibly there is a blessed setting for this.
On Jun 9, 2015 6:43 PM, "Justin Ma"<EMAIL_ADDRESS>wrote:

Here is a snapshot for the unicode characters problem:
[image: blessed]
https://cloud.githubusercontent.com/assets/1161607/8073250/26155b1e-0f55-11e5-9712-bc8f41a4497a.png
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/yaronn/blessed-contrib/issues/50#issuecomment-110554419
.

@hustcer
Take a look at the fullUnicode option on the blessed.screen instantiation.
fullUnicode - allow for rendering of East Asian double-width characters, utf-16 surrogate pairs, and unicode combining characters. this allows you to display text above the basic multilingual plane. this is behind an option because it may affect performance slightly negatively. without this option enabled, all double-width, surrogate pair, and combining characters will be replaced by '??', '?', '' respectively. (NOTE: iTerm2 cannot display combining characters properly. blessed simply removes them from an element's content if iTerm2 is detected).

@xcezzz Thanks very much, It works, and it seems that iTerm2 can display well too.

Cool glad it works!


Debian disables ensurepip

build 0.0.4 uses ensurepip to ensure pip before installing build dependencies:
https://github.com/FFY00/python-build/blob/b805ff79227d7d72057068e292ab10af6861fcb6/src/build/env.py#L169
However, CPython provided by Debian does not include this module and replaces it by a script that always return 1.  I suppose we could either:

Let pip be a dependency for build
Skip ensurepip entirely and let the execution of pip fail if it doesn't exist

I am inclined to treat anything of the form "<distro> modifies Python so that this doesn't work" as a bug for the distro to handle, but also I think at need to drop the ensurepip call for other reasons anyway.
I'd prefer making pip a dependency (which it implicitly is anyway), or possibly just falling back to ensurepip if pip isn't present.

Yes, I think this is definitely a distro bug. Replacing ensurepip with that payload is incorrect. If they want to patch ensurepip to be skipped when operating in the system Python installation, they can do that, but under no circumstance should it also be skipped in different environments.
I don't want to make pip a hard dependency for isolated builds. I think we should use pip if it is in PATH, otherwise bootstrap pip into a custom environment with ensurepip.
I think the environment where we bootstrap pip into could actually be semi-permanent and shared between all builds. This would speed up isolated builds. @pganssle @gaborbernat what do you think?

Idealistically this is a problem for the distro, and probably solved by installing python3-venv by the user. Realistically though we could fallback to PATH pip, bundle pip, etc.

I think the environment where we bootstrap pip into could actually be semi-permanent and shared between all builds.

I'm +1 on this. Though I do consider it to be orthogonal to the issue here.

probably solved by installing python3-venv by the user

FYI the ensurepip is disabled thing is from python3-venv, and as @FFY00 said

this is definitely a distro bug. [...] If they want to patch ensurepip to be skipped when operating in the system Python installation, they can do that, but under no circumstance should it also be skipped in different environments.

I'm happy with all solutions proposed in this thread, and until one of them is implemented, I'll stay on <IP_ADDRESS> just fine.  Imma take a look at Debian's bug tracker and see if there's something can be done downstream.

I'm happy with all solutions proposed in this thread, and until one of them is implemented, I'll stay on <IP_ADDRESS> just fine. Imma take a look at Debian's bug tracker and see if there's something can be done downstream.

You don't need to stay on <IP_ADDRESS>, the same beahvior is still available in the new version with the --no-isolation/-n flag :blush:

@McSinyx do you know if venv still works properly?

I've just check and 0.0.4's working alright in a venv, but I think it's because the code calling ensurepip is not reached at all:
https://github.com/FFY00/python-build/blob/3082d37183ba42c0bf60125796848b630e73a633/src/build/__main__.py#L43-L58
I might miss some part of the specification/design principal of the whole PEP 517/518 and of python-build, but it'd be really nice if I can have build isolation even if I'm already in a venv.

Sorry, I wasn't clear at all! I meant to ask, if creating a venv with pip (no --without-pip) works. This is because we will start using venv on Python 3, which will provide pip already. If venv can create a virtual environment with a working pip, this issue is fixed on Python 3.

FROM ubuntu:latest

RUN apt-get update && apt-get install -y python3

RUN python3 -m venv env || true

RUN apt-get install -y python3-venv
RUN python3 -m venv env

Sending build context to Docker daemon  2.048kB
Step 1/5 : FROM ubuntu:latest
 ---> 9140108b62dc
Step 2/5 : RUN apt-get update && apt-get install -y python3
 ---> Using cache
 ---> 7c479d206251
Step 3/5 : RUN python3 -m venv env || true
 ---> Running in 6f2339347762
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

Failing command: ['/env/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']

Removing intermediate container 6f2339347762
 ---> 4406316bac77
Step 4/5 : RUN apt-get install -y python3-venv
...
Running hooks in /etc/ca-certificates/update.d...
done.
Removing intermediate container 481833d7fd8e
 ---> 08078fca859a
Step 5/5 : RUN python3 -m venv env
 ---> Running in f096a0aaf204
Removing intermediate container f096a0aaf204
 ---> ebd54add66f5
Successfully built ebd54add66f5

So no, it will not work without the user install python3-venv.

As a Debian user, I'm fine with having to install python*-venv.  I've just taken a look at Debian's patch (I know I promised to do this earlier, but my uni ate all of my time :smiley:) and it seems that the build.env.IsolatedEnvironment is not indicating enough to Debian that it's creating a virtual environment.  Modifying either prefix and base_prefix or just real_prefix should work around the patch.

Modifying either prefix and base_prefix or just real_prefix should work around the patch.

I don't follow how we can patch? Without ensurepip there's no way for the python to create an isolated build environment. Sure you can apply tens of patches, but you'll always miss something, as is the case with https://github.com/FFY00/python-build/issues/97.
IMHO this project should do nothing. Debian's patching in thise case does not make sense, and is the responsibility of Debian to fix it. Or enforce its users to manually install python*-venv.

/cc @kitterma @doko42 as the Debian Python maintainers, for their inputs. :)

As a Debian user, I'm fine with having to install python*-venv.

Yeah, I agree. Especially since this is not our bug.

Since @doko42 is the Debian maintainer for the Python interpreters, it's really his call, but as I understand it, it's not a bug.  It's a deliberate design choice, so it would be appropriate to let us solve it.  If I recall his rationale correctly it's that pip is primarily a developer tool and it's overkill to install it on end-user systems where Python is installed because they installed something else written in Python.

Right, but that completely misses the fact that it may be run in an isolated environment :confused:

No.  It optimizes for the predominate case.  Installing python3-venv is a trivial one time operation if someone wants it.  Most Debian users aren't going to be doing that.

Whatever, it does suck that it will increase our support burden, but we can always put in the FAQ that Debian users should not use the (deliberately) broken version of Python that Debian ships. It wouldn't be the first time.

It's a lot easier to install the bits that aren't there by default than to build your own interpreter.  In any case, I'm just trying to explain the rationale.  It's @doko42's call.

No. It optimizes for the predominate case. Installing python3-venv is a trivial one time operation if someone wants it. Most Debian users aren't going to be doing that.

I get the idea, but removing parts of the core language still feels a bit off. Python comes with batteries included, unless you're on Debian, because then some have been removed. Most users will not need the [tar module)(https://docs.python.org/3/whatsnew/3.8.html#tarfile), but you're not removing that part, aren't you? The same logic could be applied there too:

Installing python3-tar is a trivial one time operation if someone wants it.

I don't follow how we can patch?

I was trying to say that somehow getting the conditional in the patch passes alright.  E.g. the following would show that build's virt env is not recognized as such:
from subprocess import run
from sys import executable

from build.env import IsolatedEnvironment

PRINT_PREFIXES = """import sys

print(f"{sys.base_prefix=}")
print(f"{sys.prefix=}")
print(f"{getattr(sys, 'real_prefix', None)=}")
"""

with IsolatedEnvironment.for_current():
    run([executable, '-c', PRINT_PREFIXES])

since this is what I got:
sys.base_prefix='/usr'
sys.prefix='/usr'
getattr(sys, 'real_prefix', None)=None

Note that pip uses the exact same mechanism to identify virt envs, so the problem here is not Debian's ensurepip doesn't run in virt env, but rather build creates neither a PEP-405-compliant venv (where prefix != base_prefix) nor a legacy virtualenv (which used real_prefix), and uses pip install --prefix.

we can always put in the FAQ that Debian users should not use the (deliberately) broken version of Python that Debian ships.

IIRC build was originally written to be a standard python build tools for distro maintainers (exclusively to solve Arch's packaging principals).  It's unlikely excluding Debian because of its packaging principle would be a good choice were I to make the call.  Also speaking as a maintainer of a few Python packages, if I have to tell my peers to do things differently on Debian based distros, I'd rather tell them to directly build using the backends.

IIRC build was originally written to be a standard python build tools for distro maintainers (exclusively to solve Arch's packaging principals).

Originally. But we agreed to drop this angle once we decided to move it within PyPa. So what was originally here is irrelevant.

I was trying to say that somehow getting the conditional in the patch passes alright. E.g. the following would show that build's virt env is not recognized as such:

I don't follow. What conditional, what patch? We're not talking here about the virtual environment of the build. We're talking here about the standard library included venv module is not functional on debian (without the ensurepip package).

Also speaking as a maintainer of a few Python packages, if I have to tell my peers to do things differently on Debian based distros, I'd rather tell them to directly build using the backends.

This is your choice of OS stance on the topic, so if you want to keep using it you'll need to oblige to their advice:

Installing python3-venv is a trivial one time operation if someone wants it.

Originally. But we agreed to drop this angle once we decided to move it within PyPa. So what was originally here is irrelevant.

I definitely missed this discussion, sorry :sweat_smile:

What conditional, what patch?

Debian's patch to ensurepip that I thought we're all referring to here, which raises error upon sys.prefix == getattr(sys, "base_prefix", sys.prefix) or not hasattr(sys, 'real_prefix').  To be clear, I don't (think that any Debian user would) object to installing python3-venv, the issue here it to find at least a work-around to let python-build employs build isolation on Debian's Python.  IIUC then as of 0.0.4, python-build

Works with --no-isolation
Works in a venv but don't isolate build (because env.install not called in _build_in_current_env)
Doesn't work outside of a virt env without --no-isolation

I'm not sure whether I somehow misread the discussion above if it was about letting python-build use venv so that Debian's Python could correctly recognize that python3 -m ensurepip is called in a virt env; and if that was the case, please take my apologies, as well as appreciation.

This doesn't really matter for the purposes of making Debian packages, because probably Debian packagers will use the non-isolated environment mode anyway, and even if they didn't, they can set a build-time dependency on python-venv.
The problem is really that a lot of people use Debian and Ubuntu for some reason, and most of those people tend to use the system Python, so when they try and use the recommended tool for building python packages in the default configuration, it will be broken.
I think that as long as we detect the issue and point them to something indicating why they would probably stop using Debian's system Python, that's as good as we can do. Maybe eventually Debian will stop this near-universally reviled practice, but really it's not our bug.

I'm not sure how I feel about adding Debian-specific code to work around things being borked due to their patches, but if that results in a nicer user experience... 🤷🏽♂

I'm not sure why everyone is talking about python3-venv, but what do y'all here think about (1) build isolation is no-op if python-build is called in a virtual environment and (2) the environment created by build.env.IsolatedEnvironment does not look like a virtual environment (and thus pip is used with --prefix instead of automatically determining the install location).  Are these by design or just something that wasn't thought of?
I understand that I somehow turn the original issue into this and thus caused some confusion, so feel free to rename the issue or tell me to create a new one to reflect it.
Regarding what Debian does, I don't think there an argument from the users' side (i.e. me!) about having to install python3-venv—if anyone needs to just build and not install some packages, perse is very likely to have that package on per system anyway.
The issue is that the patched ensurepip can't not see the environment python-build provides as virtual, because [sys.base_prefix somehow doesn't point to the base/non-virtual environment] but the supposed-to-be-virtual environment, as showed by the short script above.
goto point (2) of the first paragraph

I am perplexed with the Debian's position, both as a distro packager and an upstream maintainer. I now understand why so many Python devs bring their own interpreter instead of using the one the distro gave them. In my opinion, this is ridiculous, both removing ensurepip's content and splitting out modules that should always be present, I think it results in awful UX.

It's a lot easier to install the bits that aren't there by default than to build your own interpreter.

Have you considered the assumptions this is breaking and how difficult it is to debug these kind of issues?? If you know what is wrong, yes, it is trivial to install the missing bits, but the problem is not that, it's how you get there. Also, it is really not that difficult to build your own interpreter, https://github.com/pyenv/pyenv. If I was using Debian I would just definitely use my own interpreter instead of trying to deal with the brokeness that is Debian's.
So, I urge you to reconsider your position on this. Expecially on ensurepip which is broken and without good alternative. It seems like we are not the only ones running into this kind of issues, apparently dephell has to bring their own ensurepip? https://github.com/dephell/dephell_venvs/blob/5d323406128fc8e9cfd1a9c88a59b99dcf0f79ea/dephell_venvs/_ensurepip.py
Just to clarify the status quo. Right now IsolatedEnvironment, and by extension isolated builds (the default), are broken on Debian. With #112, on Debian isolated builds will work on Python 3 if the user has installed python3-venv and will stay broken on Python 2. Comparing this to other systems: everything is working everywhere else :neutral_face:

I'm 100% satisfied with what proposed in GH-112 and FYI python2 is (slowly) being removed from Debian so, thanks!

I am perplexed with the Debian's position, both as a distro packager and an upstream maintainer. I now understand why so many Python devs bring their own interpreter instead of using the one the distro gave them. In my opinion, this is ridiculous, both removing ensurepip's content and splitting out modules that should always be present, I think it results in awful UX.

Debian has the policy that every package is built from source. I know that at least Fedora shares this requirement. I don't know about ArchLinux. You may like that policy or not, but calling this "ridiculous" seems odd. So basically you have two options for packaging:

include the source for ensurepip in the python distro source package, and build everything from source.
use the pip packaged by Debian to provide a pip to Debian developers and users.

The first solution is not really maintainable and would duplicate the work packaging pip for the distro (which is a different story), so to have a python3-venv package depending on pip seems the way to go.
Whether all modules should be required or not is a different story.  If you put everything into one package (apparently as ArchLinux is doing), you are required to install it's dependencies. If a source package is splitted into different binary packages, then the user has the choice to only install the required dependencies (E.g. an installation without idle and any X libraries & tools). Binary packages are the way to define the installation granularity for many Linux distributions; there might be other techniques like extracting only needed stuff for one application and only ship that, but that's not available for distributions.

This doesn't really matter for the purposes of making Debian packages, because probably Debian packagers will use the non-isolated environment mode anyway, and even if they didn't, they can set a build-time dependency on python-venv.

yes, Debian policy requires that all build dependencies are satisfied by the Debian archive, nothing else.

The problem is really that a lot of people use Debian and Ubuntu for some reason, and most of those people tend to use the system Python, so when they try and use the recommended tool for building python packages in the default configuration, it will be broken.

As I outlined in the last comment, Debian is using binary packages to allow for minimal installations as well. It comes down to the definition of the "default configuration".  Should that include pip? include a compiler? include build dependencies for various other third party packages?
I understand that it is convenient for developers of Python applications to have everything installed by default, however that is not the only community served by a Linux distribution.

I think that as long as we detect the issue and point them to something indicating why they would probably stop using Debian's system Python, that's as good as we can do. Maybe eventually Debian will stop this near-universally reviled practice, but really it's not our bug.

I am sorry to hear your conclusion.  Forcing users and developers into a pip only install mode might be understandable from the viewpoint of a pip developer, but that's not what I am used from the rather inclusive Python community.

No. It optimizes for the predominate case. Installing python3-venv is a trivial one time operation if someone wants it. Most Debian users aren't going to be doing that.

I get the idea, but removing parts of the core language still feels a bit off. Python comes with batteries included, unless you're on Debian, because then some have been removed.

It's not removed, it's split out into a separate binary package.Calling ensurepip a part of the core language seems to be questionable, as it's source is not part of the core language.  Yes, batteries included, but where do you stop shipping the whole power plant?  Most users will not be aware of those splits, and developers should be able to cope with additional dependencies.

Most users will not need the tar module, but you're not removing that part, aren't you?

No, I wouldn't remove any modules, only splitting those out. However this comes with a burden to Linux package maintainers adding extra dependencies for their packages.  Usually this is only done for license reasons (e.g. gdbm), or heavy external dependencies (e.g. X libraries, pip stack).

Debian has the policy that every package is built from source. I know that at least Fedora shares this requirement. I don't know about ArchLinux.

Arch Linux has the very same requirement.

So basically you have two options for packaging:
* include the source for ensurepip in the python distro source package, and build everything from source.
* use the pip packaged by Debian to provide a pip to Debian developers and users.

The Debian provided pip should be used by users/developers on the system Python, not an ensurepip provided pip. The problem here is that we need a way to bootstrap pip into a virtual environment. Simply removing the ensurepip payload breaks this.
See what I said in my first reply to the issue:

If they want to patch ensurepip to be skipped when operating in the system Python installation, they can do that, but under no circumstance should it also be skipped in different environments.

Please keep in mind that ensurepip is a Python module and can be, and is!, used in virtual environments. By removing the whole payload you are breaking this. This is what I said to consider ridiculous. So yeah, feel free to patch ensurepip to skip when operating on the system Python but keep the payload there usable on virtual environments.

Whether all modules should be required or not is a different story. If you put everything into one package (apparently as ArchLinux is doing), you are required to install it's dependencies. If a source package is splitted into different binary packages, then the user has the choice to only install the required dependencies (E.g. an installation without idle and any X libraries & tools). Binary packages are the way to define the installation granularity for many Linux distributions; there might be other techniques like extracting only needed stuff for one application and only ship that, but that's not available for distributions.

What is the binary requirement of venv?

So basically you have two options for packaging:
* include the source for ensurepip in the python distro source package, and build everything from source.
* use the pip packaged by Debian to provide a pip to Debian developers and users.

The Debian provided pip should be used by users/developers on the system Python, not an ensurepip provided pip. The problem here is that we need a way to bootstrap pip into a virtual environment. Simply removing the ensurepip payload breaks this.

If ensurepip cannot be shipped because it is not built in any binary package in the distro, how do you want to provide it for virtual environments?

See what I said in my first reply to the issue:

If they want to patch ensurepip to be skipped when operating in the system Python installation, they can do that, but under no circumstance should it also be skipped in different environments.

Please keep in mind that ensurepip is a Python module and can be, and is(!), used in virtual environments. By removing the whole payload you are breaking this. This is what I said to consider ridiculous. So yeah, feel free to patch ensurepip to skip when operating on the system Python but keep the payload there usable on virtual environments.

sorry, that's something I don't understand. Where do you get this payload from?
Looking at https://www.archlinux.org/packages/extra/x86_64/python/
you are shipping the wheels/binaries included in CPython, so not building from source.  This may be allowed by ArchLinux policy, but I can't do that for Debian.

Should that include pip?

I'd argue yes, given that the python.org builds of CPython does include pip and basically every other distro does as well. :)

No, I wouldn't remove any modules, only splitting those out.

The point was if "most people don't need X" is the line of reasoning to split out a component (in this case venv), many other parts of the Python standard library satisfy that criterion (in this example tar).

Just to clarify a few things, I consider Debian's approach to split modules into different packages because of binary dependencies valid and perfectly reasonable. But I think one should not take such decisions lightly, we should always keep in mind how it affects users. At least that is what I try to do, we need to draw a balance between

If ensurepip cannot be shipped because it is not built in any binary package in the distro, how do you want to provide it for virtual environments?

But you can build the wheels from source and put them there.

sorry, that's something I don't understand. Where do you get this payload from?
Looking at archlinux.org/packages/extra/x86_64/python
you are shipping the wheels/binaries included in CPython, so not building from source. This may be allowed by ArchLinux policy, but I can't do that for Debian.

I'd argue it is agaisnt Arch Linux policy but since they are pure Python, it's a grey area. I have opened a bug report suggesting to build the wheels from source.

Just to clarify a few things, I consider Debian's approach to split modules into different packages because of binary dependencies valid and perfectly reasonable. But I think one should not take such decisions lightly, we should always keep in mind how it affects users. At least that is what I try to do, we need to draw a balance. I know it can be difficult to understand exactly how things affect users, but it is extremely important since it's their lives I will be impacting.
In this case, I don't really understand the need to split out venv, distutils, etc. which have no binary dependency. Could you elaborate here? :blush:

I understand the merits of what Debian is doing, but it makes it impossible for us to provide a consistent user experience because there's no way to declare that python-build depends on venv. Users who get python-build via apt-get or whatever won't have this problem.
I assume that @doko42 is aware that this is a consistent source of bugs for end users (almost certainly causing more problems than patching the default pip to default to --require-virtualenv would cause) and that this affects upstream packages as it causes users to come to our packages complaining that it doesn't work because Debian provides something other than a full Python installation and calls it "Python". I assume that this has gone into their cost-benefit analysis and at the end of the day provoking enmity with upstream maintainers is apparently worth the perceived benefits. That is fine (though I'd be perfectly happy if the PSF asked Debian to stop calling their modified distribution "Python", since that is basically the core of the issue).
At the end of the day, I think all the maintainers here are in agreement that this is not our problem. I suggest that we just go ahead and try to detect the situation and raise an exception pointing to a FAQ.
Optionally, we can probably explicitly mention that we don't support using the default Debian/Ubuntu distribution, even in a virtual environment, and that people should reproduce their bugs using pyenv or using a different OS before reporting them. I imagine people will pay zero attention to such a declaration, but at least we can link to it.

Just to clarify a few things, I consider Debian's approach to split modules into different packages because of binary dependencies valid and perfectly reasonable. But I think one should not take such decisions lightly, we should always keep in mind how it affects users. At least that is what I try to do, we need to draw a balance. I know it can be difficult to understand exactly how things affect users, but it is extremely important since it's their lives I will be impacting.

thanks for the balanced view. I appreciate it.

In this case, I don't really understand the need to split out venv, distutils, etc. which have no binary dependency. Could you elaborate here?

I think we don't need to talk about distutils anymore, it will be deprecated and removed.  The two reasons for splitting out venv are

size: the bundled wheels, and wheels which are devendored for Debian have a substantial size, and are not needed in most non-development

Don't install what you don't need. Adding more in a default install usually increases any attack vector, although you might want to argue that the Python interpreter is usually enough to get done what you want.

@pganssle, I'm disappointed about your way to polemicise and threaten. If that's the only way to go, please go ahead. Just state that you are only interested in supporting pure pip installations, as you already did at the distutils/setuptools sprint at PyCon US 2019.
If the only thing needed is having python-build a dependency on python-venv, then let's provide an egg for that module and you can depend on that. If that needs a PEP, then lets write one. If anything else is needed, then lets work on that.

Hey, I personally have no issues with debian splitting out python-venv. I find it unfortunate for ease of onboarding new users who develop on Debian, but that's it. This project must depend on venv, and there's no way around that.
That being said, we already print out the error message Debian provides when invoking ensurepip, so I think that's enough hint of the end users how to solve it. I don't think there's need for anything more. Just a caveat for end-users that who wants to use python-build instaleld from PyPi (not apt) will need to install the python3-venv (as it provides ensurepip venv uses, and we use venv) package to make it work.
Users who develop for Debian will need to follow this, and this inconveniance is a barrier of entry that as @doko42 put it is there to help the majority of users of the OS, rather than favour ease of development in case of few. With that I consider this issue as can be closed.

That being said, we already print out the error message Debian provides when invoking ensurepip, so I think that's enough hint for the end users how to solve it. I don't think there's need for anything more. Just a caveat for end-users who install
python-build from PyPi (instead of a potential future python3-build package) will need to install the python3-venv to make it work (as it provides ensurepip venv uses, and we use venv).

Won't people see somewhat cryptic "no module named venv" when they run this on Debian without installing python3-venv, and then come complaining to us?
Even though it is emphatically not our problem, it seems to me it would be better to do something like this:
try:
    import venv
except ImportError:
    raise ImportError("The module venv is not found. This usually happens if you are using a patched or otherwised modified version of Python. See python-build.readthedocs.io/faq#why-doesnt-this-work-on-debian for more details.")

Won't people see somewhat cryptic "no module named venv" when they run this on Debian without installing python3-venv, and then come complaining to us?

No because python-venv actually does not contain the venv module only the ensurepip one.
The error message with latest version is very descriptive:
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

Failing command: ['/env/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']

I consider it good enough. If it needs improved should be done on the Debian side.

this won't help. the venv module is part of the install, when you install "python3".

Ah, sounds good to me, let's close this issue and we can re-examine it if we get too many users complaining about Debian's broken package.


Deterministic VeeR config

This PR makes order of parameters and defines generated by veer.config deterministic.

LGTM


chore: release v0.5.2

2023-11-14
Changes

Packages with breaking changes:

There are no breaking changes in this release.

Packages with other changes:

envied - v0.5.2
envied_generator - v0.5.2

envied - v0.5.2

FEAT: add ability to convert field name from camelCase to CONSTANT_CASE (#42)

envied_generator - v0.5.2

FEAT: add ability to convert field name from camelCase to CONSTANT_CASE (#42)
FEAT: generated files are now ignored in the coverage report (#62)
FEAT: add support for Uri fields (#70)
FEAT: add support for DateTime fields (#70)
FEAT: add support for enum fields (#73)

@petercinibulk I've drafted a release since people have been requesting these changes to be published 😇

You forgot feat: Obfuscated doubles and nums (#72) :)

You forgot feat: Obfuscated doubles and nums (#72) :)

Not sure how that escaped me. Thanx!

@petercinibulk @ThexXTURBOXx  I've pushed the tag v0.5.2 which made the release to pub.dev 🚀. Happy days 🍻


Microsoft Defender for Cloud template spec solution -> DO NOT MERGE A…

…S 1P
Change(s):
See guidance below
Reason for Change(s):
This PR is part of template spec solution migration for solution Microsoft Defender for Cloud.
See guidance below
Version Updated:
2.0.0
Required only for Detections/Analytic Rule templates
See guidance below
Testing Completed:
The link for test results is - https://microsoftapc.sharepoint.com/:f:/t/SentinelCATTeam/EkdL2-KHeLVEuxMQMIajPj4BfA88igtUQSvTwFeIwA3-YQ?e=B1MwkS
See guidance below
This is an 1P solution.

Hi @v-sabiraj
Can you please get confirmation on this PR merging or closing and act accordingly.
Thanks

Hi @v-sabiraj
Can you please get confirmation on this PR merging or closing and act accordingly.
Thanks

@v-sabiraj Please look into this.

Hi @v-sabiraj
Can you please get confirmation on the PR merging as its already approved.
Thanks

Hi @v-sabiraj ,
Could you please check and confirm whether we need these changes or not.
Thanks

Hi @v-sabiraj
Are we waiting on the skip validations?
Thanks

We are working on skipvalidations


Performing one off actions on extension update and memento/storage persistence

I have some extension specific data is stored in storagePath and mementos. Is this data persisted across extension updates? If I want to perform a one off action when an extension is updated is the solution to store a version number in a memento?

The storage is persisted across updates.
Yes, storing the version is a good idea for one-offs.


problem with redis upon creating container

Describe your problem
hi
I previously hag ragflow working with law documents and I was very impressed.
I updated the ragflow and now have problems with redis.
i did change the web app port to 8085:80 this is the only change, I am on ubuntu 22.04
the web app runs i added openai api key , there is a redis key error in system
[+] Running 10/10
✔ Network docker_ragflow      Created                                     0.0s
✔ Volume "docker_mysql_data"  Created                                     0.0s
✔ Volume "docker_minio_data"  Created                                     0.0s
✔ Volume "docker_redis_data"  Created                                     0.0s
✔ Volume "docker_esdata01"    Created                                     0.0s
✔ Container ragflow-redis     Started                                     0.9s
✔ Container ragflow-es-01     Healthy                                    21.6s
✔ Container ragflow-minio     Started                                     1.0s
✔ Container ragflow-mysql     Healthy                                    11.6s
✔ Container ragflow-server    Started                                    21.7s
[WARNING] [2024-05-31 17:45:45,788] [synonym.init] [line:24]: Realtime synonym is disabled, since no redis connection.
[WARNING] [2024-05-31 17:45:45,895] [synonym.init] [line:24]: Realtime synonym is disabled, since no redis connection.
[WARNING] Load term.freq FAIL!
$ docker ps
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED          STATUS                    PORTS                                                                NAMES
b1f87d421bd9   infiniflow/ragflow:v0.7.0                              "./entrypoint.sh"        31 minutes ago   Up 31 minutes             <IP_ADDRESS>:443->443/tcp, <IP_ADDRESS>:9380->9380/tcp, <IP_ADDRESS>:8085->80/tcp   ragflow-server
a926dc1deb51   docker.elastic.co/elasticsearch/elasticsearch:8.11.3   "/bin/tini -- /usr/l…"   31 minutes ago   Up 31 minutes (healthy)   9300/tcp, <IP_ADDRESS>:1200->9200/tcp                                     ragflow-es-01
6c8932c0ece2   redis:7.2.4                                            "docker-entrypoint.s…"   31 minutes ago   Up 31 minutes             6379/tcp                                                             ragflow-redis
5bfdcac4bb6a   mysql:5.7.18                                           "docker-entrypoint.s…"   31 minutes ago   Up 31 minutes (healthy)   <IP_ADDRESS>:5455->3306/tcp                                               ragflow-mysql
efccc12cbea2   quay.io/minio/minio:RELEASE.2023-12-20T01-00-02Z       "/usr/bin/docker-ent…"   31 minutes ago   Up 31 minutes             <IP_ADDRESS>:9000-9001->9000-9001/tcp                                     ragflow-minio

+1
When I install RagFlow in my Windows 11 with python 3.11 and Docker Desktop( Current version: 4.29.0 (145265)) in my WSL Ubuntu.  After running
docker compose -f docker-compose-CN.yml up -d
I get the erroe message below.

root@cong:/mnt/e/ragflow/docker# docker compose -f docker-compose-CN.yml up -d
[+] Running 6/6
✔ Network docker_ragflow    Created                                                                               0.0s
✔ Container ragflow-redis   Started                                                                               0.1s
✔ Container ragflow-mysql   Created                                                                               0.1s
✔ Container ragflow-minio   Started                                                                               0.1s
✔ Container ragflow-es-01   Created                                                                               0.1s
✔ Container ragflow-server  Created                                                                               0.1s
Error response from daemon: Ports are not available: exposing port TCP <IP_ADDRESS>:1200 -> <IP_ADDRESS>:0: listen tcp <IP_ADDRESS>:1200: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

The log from ragflow-es-01 shows an error message as

(HTTP code 500) server error - Ports are not available: exposing port TCP <IP_ADDRESS>:1200 -> <IP_ADDRESS>:0: listen tcp <IP_ADDRESS>:1200: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

please help me to figure out this problem. Many Thanks.

5bfdcac4bb6a mysql:5.7.18 "docker-entrypoint.s…"

I don't see any error in the log. Did I miss something?
Redis is use for parsing task schecule. So, ignore it if parsing is running well.

+1
When I install RagFlow in my Windows 11 with python 3.11 and Docker Desktop( Current version: 4.29.0 (145265)) in my WSL Ubuntu. After running docker compose -f docker-compose-CN.yml up -d
I get the erroe message below.

[+] Running 10/10
✔ Network ragflow_ragflow      Created                                                                                0.0s
✔ Volume "ragflow_redis_data"  Created                                                                                0.0s
✔ Volume "ragflow_esdata01"    Created                                                                                0.0s
✔ Volume "ragflow_mysql_data"  Created                                                                                0.0s
✔ Volume "ragflow_minio_data"  Created                                                                                0.0s
✔ Container ragflow-minio      Started                                                                                0.2s
✔ Container ragflow-redis      Started                                                                                0.2s
✔ Container ragflow-es-01      Created                                                                                0.1s
✔ Container ragflow-mysql      Created                                                                                0.2s
✔ Container ragflow-server     Created                                                                                0.1s
Error response from daemon: Ports are not available: exposing port TCP <IP_ADDRESS>:1200 -> <IP_ADDRESS>:0: listen tcp <IP_ADDRESS>:1200: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

The log from ragflow-es-01 shows an error message as

(HTTP code 500) server error - Ports are not available: exposing port TCP <IP_ADDRESS>:1200 -> <IP_ADDRESS>:0: listen tcp <IP_ADDRESS>:1200: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

Error log:

Fail to connect to es: Connection error caused by: ConnectionError(Connection error caused by: NameResolutionError(<urllib3.connection.HTTPConnection object at 0x7fe5dc9fa620>: Failed to resolve 'es01' ([Errno -2] Name or service not known)))

es.log

Fail to connect to es: Connection error caused by: ConnectionError(Connection error caused by: NameResolutionError(<urllib3.connection.HTTPConnection object at 0x7fe5dc9fa620>: Failed to resolve 'es01' ([Errno -2] Name or service not known)))

Warning:

Fail to connect to es: Connection error caused by: ConnectionError(Connection error caused by: NameResolutionError(<urllib3.connection.HTTPConnection object at 0x7fe5dc9fa620>: Failed to resolve 'es01' ([Errno -2] Name or service not known)))

please help me to figure out this problem. Many Thanks.
@brackendalebrewing

1200 is forbidden by OS. Please google it, make it 1200 available.

hi
Thanks for responding. I believe that redis updated and broke ragflow.  On
the redis git page i see that there was a may update.
I installed rag flow on bare metal on ubuntu 22.04 and 24.or and on looking
at the initial log " no redis connection"
on the app system screen there is a redis error "invalid key"
I will try to send the logs from that machine shortly
[image: PXL_20240603_015139863.jpg]
On Sun, 2 Jun 2024 at 18:06, KevinHuSh @.***> wrote:

5bfdcac4bb6a mysql:5.7.18 "docker-entrypoint.s…"
I don't see any error in the log. Did I miss something?
Redis is use for parsing task schecule. So, ignore it if parsing is
running well.
—
Reply to this email directly, view it on GitHub
https://github.com/infiniflow/ragflow/issues/1023#issuecomment-2144103533,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJUAW6VFVWRGYBHB2LEANKDZFO6SXAVCNFSM6AAAAABITII2YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBUGEYDGNJTGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi
here is more concerning the problem i am having with ragflow
[image: image.png]
database log
Can't update token usage for afc333d821cd11efb41f0242ac120006/EMBEDDING
error log
Can't update token usage for afc333d821cd11efb41f0242ac120006/EMBEDDING
401 Unauthorized: The server could not verify that you are authorized to
access the URL requested. You either supplied the wrong credentials (e.g. a
bad password), or your browser doesn't understand how to supply the
credentials required.
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 870, in
full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 855, in
dispatch_request
return
self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type:
ignore[no-any-return]
File "/usr/local/lib/python3.10/dist-packages/flask_login/utils.py", line
285, in decorated_view
return current_app.login_manager.unauthorized()
File
"/usr/local/lib/python3.10/dist-packages/flask_login/login_manager.py",
line 178, in unauthorized
abort(401)
File "/usr/local/lib/python3.10/dist-packages/flask/helpers.py", line
272, in abort
current_app.aborter(code, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/werkzeug/exceptions.py",
line 861, in call
raise self.mapping[code](*args, **kwargs)
werkzeug.exceptions.Unauthorized: 401 Unauthorized: The server could not
verify that you are authorized to access the URL requested. You either
supplied the wrong credentials (e.g. a bad password), or your browser
doesn't understand how to supply the credentials required.
401 Unauthorized: The server could not verify that you are authorized to
access the URL requested. You either supplied the wrong credentials (e.g. a
bad password), or your browser doesn't understand how to supply the
credentials required.
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 870, in
full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 855, in
dispatch_request
return
self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type:
ignore[no-any-return]
File "/usr/local/lib/python3.10/dist-packages/flask_login/utils.py", line
285, in decorated_view
return current_app.login_manager.unauthorized()
File
"/usr/local/lib/python3.10/dist-packages/flask_login/login_manager.py",
line 178, in unauthorized
abort(401)
File "/usr/local/lib/python3.10/dist-packages/flask/helpers.py", line
272, in abort
current_app.aborter(code, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/werkzeug/exceptions.py",
line 861, in call
raise self.mapping[code](*args, **kwargs)
werkzeug.exceptions.Unauthorized: 401 Unauthorized: The server could not
verify that you are authorized to access the URL requested. You either
supplied the wrong credentials (e.g. a bad password), or your browser
doesn't understand how to supply the credentials required.
Fail put 191c5b3421ce11efb46b0242ac120006/Punta Plata Rules and
RegulationsApproved at Extraordinary Meeting March142020(3).pdf: S3
operation failed; code: NoSuchBucket, message: The specified bucket does
not exist, resource: /191c5b3421ce11efb46b0242ac120006, request_id:
17D58E872118BF47, host_id:
dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8,
bucket_name: 191c5b3421ce11efb46b0242ac120006
minio log
Fail put 191c5b3421ce11efb46b0242ac120006/Punta Plata Rules and
RegulationsApproved at Extraordinary Meeting March142020(3).pdf: S3
operation failed; code: NoSuchBucket, message: The specified bucket does
not exist, resource: /191c5b3421ce11efb46b0242ac120006, request_id:
17D58E872118BF47, host_id:
dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8,
bucket_name: 191c5b3421ce11efb46b0242ac120006
stat log
Fail put 191c5b3421ce11efb46b0242ac120006/Punta Plata Rules and
RegulationsApproved at Extraordinary Meeting March142020(3).pdf: S3
operation failed; code: NoSuchBucket, message: The specified bucket does
not exist, resource: /191c5b3421ce11efb46b0242ac120006, request_id:
17D58E872118BF47, host_id:
dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8,
bucket_name: 191c5b3421ce11efb46b0242ac120006
warning log
Can't update token usage for afc333d821cd11efb41f0242ac120006/EMBEDDING
401 Unauthorized: The server could not verify that you are authorized to
access the URL requested. You either supplied the wrong credentials (e.g. a
bad password), or your browser doesn't understand how to supply the
credentials required.
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 870, in
full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 855, in
dispatch_request
return
self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type:
ignore[no-any-return]
File "/usr/local/lib/python3.10/dist-packages/flask_login/utils.py", line
285, in decorated_view
return current_app.login_manager.unauthorized()
File
"/usr/local/lib/python3.10/dist-packages/flask_login/login_manager.py",
line 178, in unauthorized
abort(401)
File "/usr/local/lib/python3.10/dist-packages/flask/helpers.py", line
272, in abort
current_app.aborter(code, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/werkzeug/exceptions.py",
line 861, in call
raise self.mapping[code](*args, **kwargs)
werkzeug.exceptions.Unauthorized: 401 Unauthorized: The server could not
verify that you are authorized to access the URL requested. You either
supplied the wrong credentials (e.g. a bad password), or your browser
doesn't understand how to supply the credentials required.
401 Unauthorized: The server could not verify that you are authorized to
access the URL requested. You either supplied the wrong credentials (e.g. a
bad password), or your browser doesn't understand how to supply the
credentials required.
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 870, in
full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.10/dist-packages/flask/app.py", line 855, in
dispatch_request
return
self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type:
ignore[no-any-return]
File "/usr/local/lib/python3.10/dist-packages/flask_login/utils.py", line
285, in decorated_view
return current_app.login_manager.unauthorized()
File
"/usr/local/lib/python3.10/dist-packages/flask_login/login_manager.py",
line 178, in unauthorized
abort(401)
File "/usr/local/lib/python3.10/dist-packages/flask/helpers.py", line
272, in abort
current_app.aborter(code, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/werkzeug/exceptions.py",
line 861, in call
raise self.mapping[code](*args, **kwargs)
werkzeug.exceptions.Unauthorized: 401 Unauthorized: The server could not
verify that you are authorized to access the URL requested. You either
supplied the wrong credentials (e.g. a bad password), or your browser
doesn't understand how to supply the credentials required.
Fail put 191c5b3421ce11efb46b0242ac120006/Punta Plata Rules and
RegulationsApproved at Extraordinary Meeting March142020(3).pdf: S3
operation failed; code: NoSuchBucket, message: The specified bucket does
not exist, resource: /191c5b3421ce11efb46b0242ac120006, request_id:
17D58E872118BF47, host_id:
dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8,
bucket_name: 191c5b3421ce11efb46b0242ac120006
On Sun, 2 Jun 2024 at 19:14, a Coop @.***> wrote:

hi
Thanks for responding. I believe that redis updated and broke ragflow.  On
the redis git page i see that there was a may update.
I installed rag flow on bare metal on ubuntu 22.04 and 24.or and on
looking at the initial log " no redis connection"
on the app system screen there is a redis error "invalid key"
I will try to send the logs from that machine shortly
[image: PXL_20240603_015139863.jpg]
On Sun, 2 Jun 2024 at 18:06, KevinHuSh @.***> wrote:

5bfdcac4bb6a mysql:5.7.18 "docker-entrypoint.s…"
I don't see any error in the log. Did I miss something?
Redis is use for parsing task schecule. So, ignore it if parsing is
running well.
—
Reply to this email directly, view it on GitHub
https://github.com/infiniflow/ragflow/issues/1023#issuecomment-2144103533,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJUAW6VFVWRGYBHB2LEANKDZFO6SXAVCNFSM6AAAAABITII2YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBUGEYDGNJTGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

+1
当我在 Windows 11 中使用 python 3.11 和 Docker Desktop（当前版本：4.29.0 （145265））在我的 WSL Ubuntu 中安装 RagFlow 时。运行后 docker compose -f docker-compose-CN.yml up -d
我在下面收到 erroe 消息。

[+]运行 10/10 ✔ 网络ragflow_ragflow 创建 0.0s ✔ 卷“ragflow_redis_data” 创建 0.0s ✔ 卷“ragflow_esdata01” 创建 0.0s ✔ 卷“ragflow_mysql_data” 创建 0.0s ✔ 卷“ragflow_minio_data” 创建 0.0s ✔ 容器 ragflow-minio 启动 0.2s ✔ 容器 ragflow-redis 启动 0.2s ✔ 容器 ragflow-es-01 创建 0.1s ✔ 容器 ragflow-mysql 创建 0.2s✔ 容器 ragflow-server 创建 0.1s 来自守护程序的错误响应：端口不可用：暴露端口 TCP <IP_ADDRESS>：1200 -> <IP_ADDRESS>：0：0：监听 TCP <IP_ADDRESS>：1200：bind：尝试以套接字访问权限禁止的方式访问套接字。

ragflow-es-01 中的日志显示错误消息为

（HTTP 代码 500） 服务器错误 - 端口不可用：公开端口 TCP <IP_ADDRESS>：1200 -> <IP_ADDRESS>：0：侦听 tcp <IP_ADDRESS>：1200：bind：尝试以套接字的访问权限禁止的方式访问套接字。

错误日志：

无法连接到 es：连接错误导致的：ConnectionError（连接错误导致：NameResolutionError（< 0x7fe5dc9fa620> 处的 urllib3.connection.HTTPConnection 对象：无法解析“es01”（[Errno -2] 名称或服务未知）））

es.log

无法连接到 es：连接错误导致的：ConnectionError（连接错误导致：NameResolutionError（< 0x7fe5dc9fa620> 处的 urllib3.connection.HTTPConnection 对象：无法解析“es01”（[Errno -2] 名称或服务未知）））

警告：

无法连接到 es：连接错误导致的：ConnectionError（连接错误导致：NameResolutionError（< 0x7fe5dc9fa620> 处的 urllib3.connection.HTTPConnection 对象：无法解析“es01”（[Errno -2] 名称或服务未知）））

请帮我解决这个问题。非常感谢。
@brackendalebrewing

Dude, have you solved this problem yet? About the interface 1200.

1200 is forbidden by OS.

Change the docker-compose-base.yaml under in  .\ragflow\docker to a specific number to solve port 1200 issue.


Dev 1285 upgrade from java 8

The intention of this pull request is to make it possible to build and run the TWA codes and agents with a Java 11 JDK/JRE.
This has been made necessary due to at least one dependency now being compiled to Java 11 bytecode.
Actually updating the TWA code to compile to Java 11 bytecode will require updating some of the key dependencies such as Spring.
Updating to Java 11 or ideally Java 17 bytecode would allow us to use newly added Java functionality as well as greatly improved security.

So far I've just looked at fixing the JPS base lib (all the tests now run for me). I will look at the agents in the "Agents" folder next. @sganguly-cares or @csl37 can you add a list of agents you think should be able to run in this here and I'll make sure their tests run?

So far I've just looked at fixing the JPS base lib (all the tests now run for me). I will look at the agents in the "Agents" folder next. @sganguly-cares or @csl37 can you add a list of agents you think should be able to run in this here and I'll make sure their tests run?

All of the agents in that folder should run, given that all projects in the 'main' branch have to be deployable. I have already tested the agents which are deployed on the CARES side, and all of them build fine. I believe the rest are maintained by CMCL/CoMo.
Added a list of agents still left to be tested here (It's under the "Agents" sheet): https://www.dropbox.com/s/8czq6roufkkwvry/Projects status with Java 11.xlsx?dl=0

Before merging can you please go through and update the pom.xml files of the agents we've modified with the following changes:

Update the version of the jps-base-lib dependencies to 1.17.0
Increment the minor version number for each modified agent


esbuild: 0.12.9 -> 0.12.11

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/evanw/esbuild/releases.
meta.description for esbuild is: "An extremely fast JavaScript bundler"
meta.homepage for esbuild is: "https://esbuild.github.io"
meta.changelog for esbuild is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/fqyx83002amavbsjx3sfyj0r9nzji2cp-esbuild-0.12.11/bin/esbuild passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 0.12.11 with grep in /nix/store/fqyx83002amavbsjx3sfyj0r9nzji2cp-esbuild-0.12.11

found 0.12.11 in filename of file in /nix/store/fqyx83002amavbsjx3sfyj0r9nzji2cp-esbuild-0.12.11

directory tree listing: https://gist.github.com/a49c054a07e05240290e62062e6198b6

du listing: https://gist.github.com/b667b8458975df04dcf4f87a2e48e6f2

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
esbuild
netlify-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fqyx83002amavbsjx3sfyj0r9nzji2cp-esbuild-0.12.11 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A esbuild https://github.com/r-ryantm/nixpkgs/archive/2b0ad115b2133a005d8353378df216955db26d12.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fqyx83002amavbsjx3sfyj0r9nzji2cp-esbuild-0.12.11
ls -la /nix/store/fqyx83002amavbsjx3sfyj0r9nzji2cp-esbuild-0.12.11/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

esbuild
netlify-cli

Maintainer pings
cc @Lucus16 @kalbasit for testing.

Result of nixpkgs-review pr 128545 run on x86_64-linux 1

2 packages built:

esbuild
netlify-cli


Count Record Opens Unintentionally if User Clicks in the Background While Results Are Being Fetched

Note
This can be observed on the slow network or with large dataset.
Current behavior
After results are fetched, the count record where the user clicked in the background opens automatically, disrupting the user's workflow.
Expected behavior
The user's click in the background during the fetching process should not trigger any action, and no count record should open unintentionally after the results are fetched.
Steps to reproduce the issue
Login the app using admin account.
Go to draft or assigned tab. Open the count and click back button.
While the results are being loaded, click anywhere in the background of the screen.
Once the results are fetched, observe that the count record corresponding to where the user clicked opens automatically.
Environment details
App version : v2.1.2
App environment : UAT
Additional information
https://jam.dev/c/20d823f3-5663-4c8f-a55b-5d4acfb111d3

Issue verified in release v2.2.0 and found that issue is still replicating. Hence, reopening this issue.

I want to work on this can you please assigned it to me.


Timezone ambiguity

Timezone abbrivations are (sadly) not unique, e.g. IST is (Israel/India/Irish) Standard Time.
(https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations)
Related issue elsewhere: https://github.com/osTicket/osTicket/issues/3583
Lookup for full time is done by abbreviated name, so this happens:
loc, _ := time.LoadLocation("Asia/Jerusalem")
datetime := time.Date(2016, 02, 03, 9, 0, 1, 0, loc)
l := en_US.New()
fmt.Println(l.FmtTimeFull(datetime)) // 9:00:01 am India Standard Time

Thanks @fmovlex for reporting, I'll try and think of a way around that; any help or thoughts on how would be appreciated :)


Invert the XYZ axes

Hello friend, thanks a lot for the plugin!
For some reason I cannot invert the XYZ axes in the joystick driver, I like the 3D mode, but the direction of the axes is not convenient for me :(
how can they be changed? Thank you so much!

Thank you @Evgenw. I'm sorry I've missed your issue. Can you provide a bit more detail on what's not working for you?

Does switching between Camera/2D/3D mode have any effect on your device?
What would work the best for you?

When you push the knob forward/backward, what do you expect it to do?
When you lift the knob up/push the knob down, what do you expect it to do?
When you push the knob to left/right, what do you expect it do to?
Do you expect the knob to do anything when you tilt it?

Hey! I'm glad you answered :)
1 forward / backward - zoom + / - (forward - zoom +, backward - zoom -)
2 up / press - page up / page down (similar to keys on a keyboard)
3 Left / Right - Page Right / Page Left
4 No, I do not expect.
P.S. Too much sensitivity and the page in Figma shakes when I am not using the device, could you increase the starting force
Thank you so much!

Thanks for the details! I can adjust the sensitivity or expose a configuration to let you adjust it.
Just want to double check your need to control the axes. Suppose this is your figma window:

Is this how you want your device to work:
Push knob forward: see fewer squares
Lift knob up: center on square "2A"
Push knob left: center on square "3" <-- Did I get this right? Or you actually wanted to center on square "1"?

 I hope you love video games too :)
Look

Got it. So you want map the knob movement to the camera, instead of to the physical world. Most PC gamers prefer that.
I'll make that possible in Figma.
Thank you for the dust 2 illustration.

@Evgenw , the latest version has addressed this issue. Just select 3D and Camera in the options.

In addition, I added a subtle threshold for activation. This should help reduce the shaking.
Give it a try?

Thank you! Thank you so much!!!!


Complete blog content gets shared

Share just an initial snippet from the blog - no HTML tags.

This issue is resolved!


Uniform Arrays

NOT READY FOR MERGE!
One day I was doing glTF skinning (library for GENG soon) and I've noticed, that I can't pass an array of matrices as a transform for bones.

PR is ready for merge. I've got a lot of problems with it, but it seems to be finally working (maybe it's just NVidia permissiveness). To use arrays in shader uniforms, you do:
uniform mat4 joints[100];

and
SingleUniform::new("joints[0]", vec![mat4::identity(); 100]); // This is the part where NVidia might just be a little to permissive...

For more information, see:
https://gamedev.stackexchange.com/questions/157837/uniform-arrays-do-not-work-on-every-gpu
https://stackoverflow.com/questions/37527264/glgetuniformlocation-get-elements-in-an-array-using-loop
Quote from https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetUniformLocation.xhtml:

glGetUniformLocation returns an integer that represents the location of a specific uniform variable within a program object. name must be a null terminated string that contains no white space. name must be an active uniform variable name in program that is not a structure, an array of structures, or a subcomponent of a vector or a matrix. This function returns -1 if name does not correspond to an active uniform variable in program, if name starts with the reserved prefix "gl_", or if name is associated with an atomic counter or a named uniform block.

In case this doesn't work, the workaround is to make a custom ArrayUniform, would look something like this:
#[derive(Clone)]
pub struct ArrayUniform<'a, U: Uniform> {
    name: &'a str,
    values: Vec<U>, // You'll probably want a vector here, because uniform values can't be statically borrowed normally
}

impl<'a, U: Uniform> ArrayUniform<'a, U> {
    pub fn new(name: &'a str, value: Vec<U>) -> Self {
        Self {
            name,
            values: value,
        }
    }
}

impl<'a, U: Uniform> Uniforms for ArrayUniform<'a, U> {
    fn walk_uniforms<C>(&self, visitor: &mut C)
    where
        C: UniformVisitor,
    {
        for (index, value) in self.values.iter().enumerate() {
            visitor.visit(&format!("{}[{}]", self.name, index), &value);
        }
    }
}


Beautiful table of contents or similar on readme.md

Currently there are two "orphaned" markdown files in the repo,
build.md
manualinstall.md

They're soon to be accompanied by two new markdown files:
windowsinstall.md
roadmap.md

could you please make a ToC or similar that shows these links in a pretty way?  Thank you very much!

Will do sir! 👍