Disable special docker treatment unless root

Description:
Related issue: fixes https://github.com/home-assistant/home-assistant/issues/24397
Version 0.94 broke running the official docker image as non-root user by installing python packages system-wide instead of in config/deps (see https://github.com/home-assistant/home-assistant/pull/24175). This PR restores the previous behavior in this special case.
It is a no-op when the docker image is run as suggested in the docs, but also allows running the image as non-root (using docker run --user ...) which some users prefer over securing the installation with AppArmor.
I believe this should be included in the official build, because

running services inside docker as non-root is considered a security best-practice
the change is trivial, chances that this breaks anything in the official build are very small
it allows users to use the official image, making it less likely users are running outdated versions
using AppArmor as suggested here is never even mentioned in the official docs and is complicated if done right
there is user demand for running as non-root, for example https://github.com/home-assistant/home-assistant/issues/7872, https://github.com/home-assistant/home-assistant/pull/23262, https://github.com/home-assistant/home-assistant/issues/24397, discourse, discourse, discourse, reddit, reddit

Thanks!
Checklist:

[X] The code change is tested and works locally.
[X] Local tests pass with tox. Your PR cannot be merged unless tests pass
[X] There is no commented out code in this PR.
[X] I have followed the development checklist

Hi @tribut,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!

What are the implications of this? How will this impact package management ?
How will it impact the other things that Home Assistant does?
At what other places in the Home Assistant codebase do we make assumptions about how Docker works and will we need to add this check?
How will this impact the maintenance burden / what can cause us to regret this decision to support this?

Hey @baloob, thanks for taking a look at this.

What are the implications of this? How will this impact package management?
How will it impact the other things that Home Assistant does?

I will address these together, because they seem to be closely related.
Not sure what you mean by "package management", but the implication of this change is that unless we are running as root inside docker, we will not make special assumptions about the privileges we have. Given that the case "not a virtual environment" is already explicitly tested for in the code, most notably where the target folder for pip --user is set, I assumed that this was a supported configuration:
https://github.com/home-assistant/home-assistant/blob/f540d74b654700f349303cca7df0e13ba66a824a/homeassistant/requirements.py#L93-L94
This should not otherwise affect what HA does - after all, a container should look like any other environment for userspace. If any other part of HA assumes that we are running as root, this would be a bug in venv configurations as well.

At what other places in the Home Assistant codebase do we make assumptions about how Docker works and will we need to add this check?

As far as I can tell, the function I modified is the only place in the source (except for system info and the version sensor) that explicitly queries whether we are running inside docker. See the discussion of the patch for how this function is used and why I believe this is where the check should be added.

How will this impact the maintenance burden / what can cause us to regret this decision to support this?

As long as "running as normal user and not inside a venv" is a supported configuration (is it? - see above) no further changes to enable the "docker, non-root" configuration should ever be necessary, because that's how it behaves.
The only potential for regressions is: If for some reason geteuid() ever returns something other than 0 running on official hassio, it would lead to possibly unexpected behavior, but I fail to come up with a scenario for this.
Of course if the "docker, but not root" setup breaks for any reason, users might come and complain, but it should be no harder to close these bug reports with "sorry, not supported" than it is now to reject the "please support non-root docker" feature requests. If the last point is of concern however, I could add a startup log message like "You are running the docker image as non-root user. This configuration is unsupported, proceed at your own risk."

The Home Assistant container is built to be able to support all possible integrations that Home Assistant supports. It does so by installing packages on demand supported by our wheel infrastructure with pre-compiled packages.
To apply Docker best practices, one should also follow best practices for building your container. In that case you would have a container that pre-installs everything you need. Those installations should also then use a virtualenv, which is one of our supported ways of installing Home Assistant.
I do not think that we should merge this PR as-is. Instead, let's fix the fact that we do not install inside a virtual env when we're in Docker.
Once that is fixed, you should be able to create a Docker container that follows the best practices, runs in a virtualenv, and behaves exactly like you want it to.
I don't think that we should try to add a bunch of exceptions to different places to try to support everything in the official Docker image. We don't have the resources to maintain that.

So remove the not is_docker from here should allow you to build Docker images that run as user: https://github.com/home-assistant/home-assistant/blob/9e8f4a589f80ec00532daa09b20ce9edbf61c1fd/homeassistant/requirements.py#L93-L94
Looping in @pvizeli to make sure that what I say is correct.

I agree with the solution that @balloob descripe. I think that allow to covery any special case.

Excellent - that sounds like the best solution indeed! Do you want me to try and prepare a PR that changes the docker image to use a virtualenv? Or is that something you'd rather do yourselves?

Do you want me to try and prepare a PR that changes the docker image to use a virtualenv? Or is that something you'd rather do yourselves?

It would be great if you want to take that on!  🎉

The hass.io image should be the image that is using a virtualenv. It is doing a lot of special things to make sure we support a lot of things without being a huge download. This image using a virtualenv should be an externally maintained image. We just need to make sure that it will work with Home Assistant. So inside Home Assistant, we should make sure we follow these steps when deciding the target of a package:

If run in virtualenv: install in venv
If run in docker: install in system env
Else: install in deps folder

I'm confused. I thought you were proposing to change the docker image, so that it installs its packages in a virtualenv? Now you are saying both "The hass.io image should be the image that is using a virtualenv" and "If run in docker: install in system env"?
Could you please clarify what your proposal is? I fear I may be misunderstanding.

If you prefer, we can also meet on discord for a quick chat. Maybe less is "lost in translation" in real time 🙃

Let me try to clarify 👍
I was not proposing to change the official Docker image. We do a lot of things to support minimal downloads / maximal support. We do not want to complicate this any further (it's already complex).
I am proposing that Home Assistant follows those 3 steps for deciding on where to install a package (with system env I mean the system installation / container).
Once that is in place in Home Assistant, you can create a non-official image that will be able to run as user by leveraging a virtual env.

Thanks for clarifying :+1:
I was hoping we could actually reduce complexity by changing the three supported configurations (virtualenv/docker/deps) to just two (virtualenv/deps) and thought that's what you were proposing. But I understand the official docker images are finely tuned (I've seen -builder and -base when I tested my changes, of course).
Using non-official images still seems vastly inferior to me for reasons I already outlined in my earlier posts. And now you are essentially proposing to use "docker and not virtualenv" to decide where to install packages in the "docker" configuration:

So remove the not is_docker from here should allow you to build Docker images that run as user:
https://github.com/home-assistant/home-assistant/blob/9e8f4a589f80ec00532daa09b20ce9edbf61c1fd/homeassistant/requirements.py#L93-L94

I am proposing to use "docker and not root", which has exactly the same complexity, but allows to use the official images (unchanged!). Help me understand this tradeoff.

Feel free to just close this PR if you don't feel like hashing this out, btw. I totally respect your right to make technical decisions like this and if I read the code correctly, if I had a virtualenv inside docker, it would already be used. So no need to change anything if that is the settled solution.

This night it came to me that the official image probably supports venv (it does), so I came up with this embarrassingly simple solution that works without changes to either HA or the docker image: https://github.com/tribut/homeassistant-docker-venv
I guess this means the issue can be closed. Thanks for bringing up the venv idea, though it took me a while to realize how trivial the solution is :flushed:

Yeah, that was exactly the solution. It is very difficult to support all the user cases out of the box. So we stick official on the way that allow easy to run most of integration but we should open that user can do such solutions as self maintaining.


Proposal: Event and API object revisions

I'd like to propose that we add monotonically-increasing revision numbers to each of the objects that is returned by the API and visible in the event stream.  A client can use revision numbers to more-reliably synchronize state between events received and results of API calls; using a revision number, a client can detect a duplicate event, a stale event, a missing event, or a stale API response and take appropriate action.  The revision number for a given object should be present in each event including that object, and in each API response that returns that object.  I am not proposing that we necessarily use the same revision number across different objects, but that each object has a monotonically-increasing revision number.
An example of a system that functions like this is the API and event stream of Amazon ECS.  Each event specifies a version field that increases each time the underlying resource changes and those same version fields are returned in the API responses for those respective resources.  Events are delivered at least once, and the API is eventually consistent; these version fields help a client reconcile (and this is used by the Blox cluster-state-service to create a local copy of your cluster state).
Kubernetes has something similar with their resourceVersion field.  While the resource Version is used primarily as a mechanism to provide optimistic concurrency, it also lets a client understand enough to perform reconciliation logic.  resourceVersions are returned on GET and Watch operations over a particular resource.
While containerd is not eventually consistent, concurrently-executing client code that both listens for events and reconciles against API responses can run into a similar problem of not knowing which result is the correct one.  Using a revision number here would allow the client code to compare and discard the one with the lower number.
While containerd is not providing guaranteed at least once delivery, a client can disconnect and reconnect to the event stream and lose events.  Using a revision number here would allow the client to discover that events were missed when it queries the API.

@samuelkarp Do we need to have actual ordering or is it sufficient just to know that the item has changed based on a version number? I ask this because having total or partial ordering changes the requirements from the datastore, limiting the possible targets for future implementations. Total orderings also tempt one to be able to time travel any data structure, which is cool but expensive.
For the most part, correlating events with a particular object only require that each revision has a different value in version.
I would also like to point out that adding such functionality makes equality more complex, in that you need to blank out the version field to test structural equality.
The other possibility here is to limit the mutability for data structures that matter. #859, for example, separates the faster changing fields into an object that won't really change once constructed, obviating the need for revisioning. We take this further if it provides the same effect.

Do we need to have actual ordering or is it sufficient just to know that the item has changed based on a version number?

I think having an ordering here is useful to a client, as then the client can implement the logic as to whether to discard an old record or a new record.  What would it look like to know that an item changed based on the version number; would that mean that containerd would then be responsible for calculating if a diff exists?

I ask this because having total or partial ordering changes the requirements from the datastore, limiting the possible targets for future implementations.

I'm concerned about that too.  I think the risk here can be mitigated by not ordering all the events emitted, but just ordering within each specific mutable object; it seems like it would be fairly easy to change the revision number when the object is mutated since you'd be doing a write to the datastore anyway.

For the most part, correlating events with a particular object only require that each revision has a different value in version.

As a client of containerd, I'd like to avoid querying containerd every time I receive an event.  With a revision number that provides an order, I can asynchronously and periodically query containerd to determine whether I missed an event (e.g., an event happened while my client was not running during an upgrade).  If the only guarantee is that the revision is different when the object is mutated rather than being orderable (e.g., if the revision was a guid or a sha), I'm limited my ability to use the event as anything other than a trigger to make a synchronous query against containerd for the data.

I would also like to point out that adding such functionality makes equality more complex, in that you need to blank out the version field to test structural equality.

From a client's perspective, equality becomes a little easier because the client can rely on just the revision number instead of doing deep structural equality.

The other possibility here is to limit the mutability for data structures that matter. #859, for example, separates the faster changing fields into an object that won't really change once constructed, obviating the need for revisioning.

That will probably help.  I looked at #859 and I'm not sure which structures are immutable; both Container and Task appear to mutate.

@ehazlett Since you're working on https://github.com/containerd/containerd/pull/956, I'd appreciate your thoughts here too.

Revisions seem fine to me although I'm also concerned about the ordering and maintaining the revisions state internally.

@samuelkarp should this still be opened after the discussions at the summit?

@crosbymichael I'd like to validate that I can do without it before closing this; waiting on https://github.com/containerd/containerd/issues/1054 to be fixed first.

@samuelkarp no problem.  I'm just going through issues and seeing if there is anything that we need to get done.

@samuelkarp Are there considerations we still need to make here?


Added Font awesome icons

changes to login.jade, login.style.css, and added files for font-awesome

Merged. Thanks @yashdeep97 !


Fahad wednesday

Button works, the component assigns the ID for next npc Line depending on the choice player makes and setStates . However it won't grab the next Line and fill in the blanks (fills in buttons though?????)


Maksimum text lenght is 1000

Hello, I encountered a problem. When the text length is more than 1000 characters, the package throws an error. The error appears to be caused by the Bing Translation API reaching its maximum text length. How can I solve this problem? I would also like to use your package with longer texts. I would be glad if you help. Thanks.

The latest v2.10.0 has increased the text length to 5000. If you are using this version and think it is still not enough, you have to split the text to multiple blocks.

I think it's not possible and I just tested with the following code. Please check the version again in node_modules/bing-translate-api/package.json.
translate(new Array(5000).fill('0').join(''), null, 'en')

First Try(5000 Chars)
node.js cli output
root@45:/home/sammy# node app.js
Server is running
Error: Something went wrong!
Response status: 200 (OK)
Response body  : {"statusCode":400,"errorMessage":""}
    at wrapRequest (/home/sammy/node_modules/bing-translate-api/src/index.js:213:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async translate (/home/sammy/node_modules/bing-translate-api/src/index.js:289:16)
    at async file:///home/sammy/routes/bingRoutes.js:43:29

My dummy text(5000 chars)
But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure? On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains. But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure? On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain. These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted. The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains. But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure? On the other hand, we denounce with righteous indignation and dislike men who are so beguiled
Second Try(1001 Chars)
node.js cli output
Error: Something went wrong!
Response status: 200 (OK)
Response body  : {"statusCode":400,"errorMessage":""}
    at wrapRequest (/home/sammy/node_modules/bing-translate-api/src/index.js:213:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async translate (/home/sammy/node_modules/bing-translate-api/src/index.js:289:16)
    at async file:///home/sammy/routes/bingRoutes.js:43:29

Dummy Text(1001 Chars)
But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure? On the other hand, we denounce
Third Try(999 Chars)
node.js cli output
Nothing! Good.

Dummy Text(999 Chars)
But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure? On the other hand, we denoun
Successfully Translated Text:
Ama size hazzı kınamak ve acıyı övmek gibi tüm bu yanlış fikirlerin nasıl doğduğunu açıklamak zorundayım ve size sistemin tam bir açıklamasını vereceğim ve gerçeğin büyük kaşifi, insan mutluluğunun usta kurucusunun gerçek öğretilerini açıklayacağım. Hiç kimse hazzın kendisini reddetmez, sevmez veya kaçınmaz, çünkü bu zevktir, ancak rasyonel olarak hazzın peşinden gitmeyi bilmeyenler son derece acı verici sonuçlarla karşılaşırlar. Ne de kendi acısını elde etmeyi seven, peşinden koşan ya da arzulayan kimse yoktur, çünkü bu acıdır, ama ara sıra zahmet ve acının ona büyük bir zevk verebileceği durumlar ortaya çıkar. Önemsiz bir örnek vermek gerekirse, hangimiz bundan bir avantaj elde etmek dışında zahmetli fiziksel egzersiz yaparız? Ama can sıkıcı sonuçları olmayan bir zevkten zevk almayı seçen ya da sonuçta hiçbir zevk vermeyen bir acıdan kaçınan bir insanda kusur bulmaya kimin hakkı var? Öte yandan, kınıyoruz
Note:
router.post('/translate', rateLimit({
    windowMs: 60 * 1000, // 1 dakika
    max: 200, // 1 dakikada en fazla 200 istek
    handler: (req, res, next) => {
        res.status(429)
            .json({ error: 'Çok fazla istek yaptınız. Lütfen bir süre sonra tekrar deneyin.' });
    },
}), [
    body('text').notEmpty().isString().isLength({ max: 5000 }).withMessage('İstek metni 1000 karakteri geçemez'),
    body('from').custom((value) => validateLanguageCode(value)).notEmpty().withMessage('Çevirilen dil geçerli değil.'),
    body('to').custom((value) => validateLanguageCode(value)).notEmpty().withMessage('Çevirilecek dil geçerli değil.'),
    body('raw').optional().isBoolean().withMessage('raw değeri şu an çok değerli ')
],
    validateRequestBody
    ,async (req, res) => {
    try {
        // İstekten gelen veriler
        const { text, from, to, raw } = req.body;

        // translate fonksiyonunu çağırma
        const translation = await translate(text, from, to, false, raw);

        // Çeviri sonucunu JSON formatında client'a gönderme
        res.json({ translation: translation.translation });
    } catch (error) {
        // Hata durumunda uygun bir response gönderme
        console.error(error);
        res.status(500).json({ error: 'Internal Server Error' });
    }
});

It works well for me. Can you clone this repo and run the following commands to see if the field maxTextLen value in src/config.json is 5000?
npm i
npm run gen:config

PS C:\Users\xxx\Downloads\bing-translate-api-master> npm i

added 44 packages, and audited 45 packages in 2s

20 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
PS C:\Users\xxx\Downloads\bing-translate-api-master> npm run gen:config

><EMAIL_ADDRESS>gen:config
> node scripts/generate-config.js

✔ Generated config
 {
  websiteEndpoint: '/translator',
  translateEndpoint: '/ttranslatev3?isVertical=1&',
  spellCheckEndpoint: '/tspellcheckv3?isVertical=1&',
  maxTextLen: 1000,
  maxCorrectableTextLen: 50,
  correctableLangs: [
    'da',      'en',      'nl',
    'fi',      'fr',      'fr-CA',
    'de',      'it',      'ja',
    'ko',      'no',      'pl',
    'pt',      'pt-PT',   'ru',
    'es',      'sv',      'tr',
    'zh-Hant', 'zh-Hans'
  ],
  userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>'
}

✔ Generated language map
 {
  af: 'Afrikaans',
  sq: 'Albanian',
  am: 'Amharic',
  ar: 'Arabic',
  hy: 'Armenian',
  as: 'Assamese',
  az: 'Azerbaijani',
  bn: 'Bangla',
  ba: 'Bashkir',
  eu: 'Basque',
  bho: 'Bhojpuri',
  brx: 'Bodo',
  bs: 'Bosnian',
  bg: 'Bulgarian',
  yue: 'Cantonese (Traditional)',
  ca: 'Catalan',
  lzh: 'Chinese (Literary)',
  'zh-Hans': 'Chinese Simplified',
  'zh-Hant': 'Chinese Traditional',
  hr: 'Croatian',
  cs: 'Czech',
  da: 'Danish',
  prs: 'Dari',
  dv: 'Divehi',
  doi: 'Dogri',
  nl: 'Dutch',
  en: 'English',
  et: 'Estonian',
  fo: 'Faroese',
  fj: 'Fijian',
  fil: 'Filipino',
  fi: 'Finnish',
  fr: 'French',
  'fr-CA': 'French (Canada)',
  gl: 'Galician',
  lug: 'Ganda',
  ka: 'Georgian',
  de: 'German',
  el: 'Greek',
  gu: 'Gujarati',
  ht: 'Haitian Creole',
  ha: 'Hausa',
  he: 'Hebrew',
  hi: 'Hindi',
  mww: 'Hmong Daw',
  hu: 'Hungarian',
  is: 'Icelandic',
  ig: 'Igbo',
  id: 'Indonesian',
  ikt: 'Inuinnaqtun',
  iu: 'Inuktitut',
  'iu-Latn': 'Inuktitut (Latin)',
  ga: 'Irish',
  it: 'Italian',
  ja: 'Japanese',
  kn: 'Kannada',
  ks: 'Kashmiri',
  kk: 'Kazakh',
  km: 'Khmer',
  rw: 'Kinyarwanda',
  'tlh-Latn': 'Klingon (Latin)',
  gom: 'Konkani',
  ko: 'Korean',
  ku: 'Kurdish (Central)',
  kmr: 'Kurdish (Northern)',
  ky: 'Kyrgyz',
  lo: 'Lao',
  lv: 'Latvian',
  ln: 'Lingala',
  lt: 'Lithuanian',
  dsb: 'Lower Sorbian',
  mk: 'Macedonian',
  mai: 'Maithili',
  mg: 'Malagasy',
  ms: 'Malay',
  ml: 'Malayalam',
  mt: 'Maltese',
  mr: 'Marathi',
  'mn-Cyrl': 'Mongolian (Cyrillic)',
  'mn-Mong': 'Mongolian (Traditional)',
  my: 'Myanmar (Burmese)',
  mi: 'Māori',
  ne: 'Nepali',
  nb: 'Norwegian',
  nya: 'Nyanja',
  or: 'Odia',
  ps: 'Pashto',
  fa: 'Persian',
  pl: 'Polish',
  pt: 'Portuguese (Brazil)',
  'pt-PT': 'Portuguese (Portugal)',
  pa: 'Punjabi',
  otq: 'Querétaro Otomi',
  ro: 'Romanian',
  run: 'Rundi',
  ru: 'Russian',
  sm: 'Samoan',
  'sr-Cyrl': 'Serbian (Cyrillic)',
  'sr-Latn': 'Serbian (Latin)',
  st: 'Sesotho',
  nso: 'Sesotho sa Leboa',
  tn: 'Setswana',
  sn: 'Shona',
  sd: 'Sindhi',
  si: 'Sinhala',
  sk: 'Slovak',
  sl: 'Slovenian',
  so: 'Somali',
  es: 'Spanish',
  sw: 'Swahili',
  sv: 'Swedish',
  ty: 'Tahitian',
  ta: 'Tamil',
  tt: 'Tatar',
  te: 'Telugu',
  th: 'Thai',
  bo: 'Tibetan',
  ti: 'Tigrinya',
  to: 'Tongan',
  tr: 'Turkish',
  tk: 'Turkmen',
  uk: 'Ukrainian',
  hsb: 'Upper Sorbian',
  ur: 'Urdu',
  ug: 'Uyghur',
  uz: 'Uzbek (Latin)',
  vi: 'Vietnamese',
  cy: 'Welsh',
  xh: 'Xhosa',
  yo: 'Yoruba',
  yua: 'Yucatec Maya',
  zu: 'Zulu'
}

✔ Generated dts from template

✔ Generated README.md from template

config.json:
{
  "websiteEndpoint": "/translator",
  "translateEndpoint": "/ttranslatev3?isVertical=1&",
  "spellCheckEndpoint": "/tspellcheckv3?isVertical=1&",
  "maxTextLen": 1000,
  "maxCorrectableTextLen": 50,
  "correctableLangs": [
    "da",
    "en",
    "nl",
    "fi",
    "fr",
    "fr-CA",
    "de",
    "it",
    "ja",
    "ko",
    "no",
    "pl",
    "pt",
    "pt-PT",
    "ru",
    "es",
    "sv",
    "tr",
    "zh-Hant",
    "zh-Hans"
  ],
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>"
}

It looks like the maximum text length is till 1000 in your area. I think I should fetch the maxTextLen configuration dynamically, instead of hard coding it.
For a long text, you can split it into multiple blocks to translate one by one.

Yes, in my region the maxTextLen is 1000.
Thank you for your suggestion. However, I'll stick with Google Translate instead of Bing Translate. I will follow the developments.
Enjoy your work

Hi @MahmutHizal, I changed the default maxTextLen back to 1000 in v3.3.0 since 5000 is only supported in China. And in this new version, I added a new EPT mode that has a lower (or no?) rate limit. It would be great if you could check out the latest code of the main branch and leave your feedback.

Hi @MahmutHizal, I changed the default maxTextLen back to 1000 in v3.3.0 since 5000 is only supported in China. And in this new version, I added a new EPT mode that has a lower (or no?) rate limit. It would be great if you could check out the latest code of the main branch and leave your feedback.

Hello,
I didn't have much time, so I downloaded the latest master branch and ran npm run gen:config and npm run test, and I'm providing the output below.
 Please shorten the text.
    at translate (C:\Users\xxx\Downloads\bing-translate-api-master\src\index.js:285:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Error: The supported maximum text length is 1000. Please shorten the text.
    at translate (C:\Users\xxx\Downloads\bing-translate-api-master\src\index.js:285:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Hello ----> 你好 fromLang en

The detected language 'en' is not supported to be corrected or the length of text is more than 50.
000000000000000000000000000000000000000000000000000 ----> undefined

00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ----> Zero fromLang en

000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ----> Zero fromLang en

Hello ----> გამარჯობა fromLang en

你好 ----> Hello fromLang zh-Hans

The detected language 'hr' is not supported to be corrected or the length of text is more than 50.
Bore da ----> undefined

this text is vry lang ----> this text is very long

안녕하십니까 ----> 你好 fromLang ko

gradent ----> gradient

邹忌修八尺有余，而形貌昳丽。朝服衣冠，窥镜，谓其妻曰：“我孰与城北徐公美？”。其妻曰：“君美甚，徐公何能及君也？” ----> 邹 忌身高八尺多，而且外形、容貌光艳美丽。穿着官服，照镜子，对妻子说：“我和城北徐公比，谁更美？”他的妻子说：“您非常美丽，徐 公怎么能比得上您？” fromLang zh-Hant

en supported: true
en1 supported: false
Korean language code: ko


Swift bridging header modification issue

Hi
I'm trying to install swix in my IOS app. To do that I follow the different instructions of the swix 0.30 documentation in the "How to creat a new iOS app that includes swix" paragraph.
For me all the different steps are ok until the Swift bridging header modification. As you can see in the attach image, i don't have the objective-c bridging header menu in my project setting.
Have you an idea of my problem?? (for information i used Xcode 8.2.1)
Best regards

#34 should fix this.
The below SO question has some tips on adding a bridging header. There's some field in the build settings, but the easiest way is to add a .m file yourself and click "yes" at the prompt.
https://stackoverflow.com/questions/24002369/how-to-call-objective-c-code-from-swift


Added missing "standalone" functions to raudio.c & fixed return bug

NOTICE: THIS IS THE SAME COMMIT AS #17 IN RAUDIO. I PUT THIS HERE TO HAVE BOTH REPOS SYNCED.
Hey,
While I updated raudio #16, I also found some bugs & afterthoughts with "raudio.c".
First, as GetFileNameWithoutExt, GetFileName & strprbrk were linked to Raylib itself I had to add them to "raudio.c" under the "RAUDIO_STANDALONE" define for standalone mode to work. Point at which the functions were added:

(15-04-2023) RadsammyT: "[raudio] Rewritten ExportWaveAsCode() file saving to be more like rtextures ExportImageAsCode() (raysan5#3013)"

Second, I use a lot compiler flags so it found that "SaveFileData" & "SaveFileText" in "raudio.c" were missing return values. Surprisingly a lot of variables inside "raudio.c" were actually using the values returned, that were never actually given.

@sanyokdev Thanks for the review! As raudio is integrated into raylib this issue was not detected before...


Add Raga Rocks

https://open.spotify.com/playlist/37i9dQZF1DX8pmtpgsUtwS

Looks good, thanks for contributing!


Weard behavior when increasing the cost of lane changes

Screenshots

This issue is now fixed in version 1.0.5 and up.
For more information, visit the forum post.


Update external-tables-azurestorage-deltalake.md

Added Preview tag

@shsagir
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Should We Fork OnlyDust?

[ ] Conduct a comprehensive feasibility assessment for forking the OnlyDust structure, including both frontend and backend components.

Issue: Should we fork OnlyDust?
I have evaluated the OnlyDust codebase, which comprises the following four repositories:

marketplace-frontend
marketplace-api
marketplace-indexer
marketplace-backend

Given that the project is maintained by over 30 professionals, I believe it is not feasible for us to fork the project. While the project contains almost everything we aim to build, it lacks a payment module, presenting a technical challenge. Therefore, I recommend using OnlyDust as a reference for any issues we encounter while developing our own solution.

Summary of the App:
Home Page:

Search Projects with filters for tags, ecosystems, and technologies.
Sort options by contributors, project name, or trending status.

Project Page:

Displays project name, photo, description, and tags.
Details include project leads, contributors, ecosystems, sponsors, and technologies.
Lists repositories and issues with labels, repo links, and application buttons.
Actions: Sponsor project, get in touch, apply.

Contributors Page:

Lists all contributors.

Contributor Profile Page:

Shows detailed contributor information, activity, and work distribution.

Hackathons Page:

Lists previous and upcoming hackathons.

Contributions Page:

Tracks contributions (in progress, completed, canceled).

Rewards Page:

Displays rewarded and pending amounts, filters by dates, projects, and currencies.

Profile Menu:

Manage account, public profile, feedback, terms, privacy, log-out.

Manage Account Page:

Connect GitHub, update profile details, set time availability, job search status, and payout preferences.

Payment Profile Page:

Payment methods, company information, and invoices.

More details about the features available: https://www.evernote.com/shard/s354/sh/83e9d44f-cb47-b0e5-5a61-ab18a8dd6199/KNVwCxxt1TfHF3VvrkG4vj5lSQt9m_kng0JQ-c5XUYsri4wCOvOBExJ-TQ

I analyzed the repository and tried to run the project but without success there is a high complexity layer to run and with several dependencies.
In short, we can use the project as a guide.
Thanks for the documentation, we can start from these principles.


Why intercepting android.content.ContextWrapper class

Why Android scripts intercept android.content.ContextWrapper class for different things?
Is this class somehow lower level for other classes?

@kochia3 t's done because android.content.Context is an abstract class that cannot be used to create objects but android.content.ContextWrapper extends android.content.Context and exports the methods we want to hook.
Closing it as not an issue.


Bug: Mathjax v3 - Certain Symbols (€) throw a TexParser error

Using certain symbols causes Mathjax v3 to throw an error in the TexParser. I'm sure there's more examples, but I've noticed it with a couple of currency symbols such as:
€ - euro
₣ - Francs
₹ - Rupee
You can get around the error by wrapping the symbols in a \text{} environment, but this wasn't necessary in mathjax v2 and I'm unsure what symbols might cause this issue.
Steps to Reproduce
You can create this error on the tex2svg demo sample provided in this repo.
https://mathjax.github.io/MathJax-demos-web/input-tex2svg.html
Can also be seen on the tex2chtml demo
https://mathjax.github.io/MathJax-demos-web/input-tex2chtml.html
Alternatively I recreated the tex2svg in jsfiddle, but I log the error to the console.
https://jsfiddle.net/hLbp1z4s/

Use one of the symbols mentioned above (e.g. €12) and press "Render TeX"
An error is thrown Cannot read properties of null (reading '4')

Technical details
Example pages use latest Mathjax@3, I've also confirmed the issue with<EMAIL_ADDRESS>I've seen the issue in both Google Chrome, Edge and Firefox
Questions
Any recommendations on a workaround for this in the meantime?

This is fixed in the next release of v4 (via mathjax/MathJax-src#900).  For now, you can use
  MathJax = {
    tex: {
      packages: {'[+]': ['fix-unicode']}
    },
    startup: {
      ready() {
        const {Configuration} = MathJax._.input.tex.Configuration;
        const {MapHandler} = MathJax._.input.tex.MapHandler;
        const NodeUtil = MathJax._.input.tex.NodeUtil.default;
        const {getRange} = MathJax._.core.MmlTree.OperatorDictionary;
        function Other(parser, char) {
          const font = parser.stack.env['font'];
          let def = font ? {mathvariant: parser.stack.env['font']} : {};
          const remap = (MapHandler.getMap('remap')).lookup(char);
          const range = getRange(char);
          const type = range?.[3] || 'mo';
          let mo = parser.create('token', type, def, (remap ? remap.char : char));
          range?.[4] && mo.attributes.set('mathvariant', range[4]);
          if (type === 'mo') {
            NodeUtil.setProperty(mo, 'fixStretchy', true);
            parser.configuration.addNode('fixStretchy', mo);
          }
          parser.Push(mo);
        }
        Configuration.create('fix-unicode', {fallback: {character: Other}});
        MathJax.startup.defaultReady();
      }
    }
  };

to apply the needed fix.

PS, the error was using range[4] rather than range?.[4] in the middle of the Other() function.

Appreciate the quick and helpful response. We will definitely move up to Mathjax 4 when it's released. Would you be able to provide an example of that workaround for mathjax-full?
I created a cutdown sample of how we use mathjax-full, but I'm unsure how to add that startup logic to replace the broken  range[4] check.
https://codesandbox.io/s/distracted-roman-23zpum?file=/src/index.js

Here is a modified version of your code:
import { mathjax } from "mathjax-full/js/mathjax";
import { TeX } from "mathjax-full/js/input/tex";
import { AllPackages } from "mathjax-full/js/input/tex/AllPackages";
import { SVG } from "mathjax-full/js/output/svg";
import { RegisterHTMLHandler } from "mathjax-full/js/handlers/html";
import { chooseAdaptor } from "mathjax-full/js/adaptors/chooseAdaptor";

import {Configuration} from "mathjax-full/js/input/tex/Configuration";
import {MapHandler} from "mathjax-full/js/input/tex/MapHandler";
import NodeUtil from "mathjax-full/js/input/tex/NodeUtil";
import {getRange} from "mathjax-full/js/core/MmlTree/OperatorDictionary";

const adaptor = chooseAdaptor();
RegisterHTMLHandler(adaptor);

function Other(parser, char) {
  const font = parser.stack.env['font'];
  let def = font ? {mathvariant: parser.stack.env['font']} : {};
  const remap = (MapHandler.getMap('remap')).lookup(char);
  const range = getRange(char);
  const type = range?.[3] || 'mo';
  let mo = parser.create('token', type, def, (remap ? remap.char : char));
  range?.[4] && mo.attributes.set('mathvariant', range[4]);
  if (type === 'mo') {
    NodeUtil.setProperty(mo, 'fixStretchy', true);
    parser.configuration.addNode('fixStretchy', mo);
  }
  parser.Push(mo);
}
Configuration.create('fix-unicode', {fallback: {character: Other}});

const tex = new TeX({
  formatError(jax, error) {
    throw Error(`TeX error: ${error.message}`);
  },
  packages: AllPackages.filter((x) => x !== "textmacros").concat('fix-unicode')
});

const svgOutput = new SVG({ fontCache: "none" });

// https://github.com/mathjax/MathJax/issues/2824#issuecomment-1020447016
// use document for first parameter so mathjax can get the font size correct for non TeX fonts
const html = mathjax.document(document, {
  InputJax: tex,
  OutputJax: svgOutput
});

export const toSVG = (latex) => {
  return html.convert(latex, { display: true });
};

const svgHtml = toSVG("12345€");
const wrapper = document.createElement("div");
wrapper.append(svgHtml);
document.body.append(wrapper);

Note that you don't have to subclass the TeX input jax in order to get the error handling, as there is a formatError() option that you can use, as I have done here.  Also, since you are adding the SVG into the page, there is no need to convert to outerHTML and then innerHTML again, and that has adverse consequences (like losing the event handlers).  But it may be that this test page does not reflect your actual usage of the resulting SVG.
Finally, the chooseAdaptor() is really only for development use, where you want to be able to run the exact same code in both the browser and in node.  If you use it in production, you will package both the HTML adaptor and the LiteDOM adaptor, and so will be shipping extra code that you won't be using.


[SMALLFIX] Java 8 Improvement

replace anonymous type with lambda in alluxio.master.block.DefaultBlockMaster#generateBlockInfo #296

when we push master repos to the origin/master, we got the push rejected error. We only push succeed the smallfix repos. However, when we make new pull request, we got Alluxio:master and raoluSmile:smallfix are entirely different commit histories, nothing to compare. We did compile the code successfully and see "BUILD SUCCESS". The compile code we use is "mvn clean install -DskipTests -Dcheckstyle.skip"
some environment details:
Apache Maven 3.5.4
Java version: 1.8.0_172, vendor: Oracle Corporation
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-36-generic", arch: "amd64", family: "unix"

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/766/
Test FAILed.

Merged build finished. Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/769/
Test FAILed.

Hi there, it looks like the jenkins server is complaining about a style issue.
/usr/src/alluxio/core/server/master/src/main/java/alluxio/master/block/DefaultBlockMaster.java:963: error: Line is longer than 100 characters (found 121).

When compiling, to make sure you catch these issues you should remove the -Dcheckstyle.skip from your build command.

Thank you, we update the file and make new pull request,.


[Bug]: The bundle channel is alpha, but the catalog is stable.

Describe the bug
Because channels are not defined in the Makefile, the default channels are used when the bundle is generated.
https://github.com/zncdatadev/hdfs-operator/blob/451b1c8e4cf84cb05aea9b40ec28252ee97eaccf/Makefile#L8-L25
Have you searched existing issues?  🔎

[X] I have searched and found no existing issues

Reproduction
https://github.com/zncdatadev/hdfs-operator/blob/451b1c8e4cf84cb05aea9b40ec28252ee97eaccf/Makefile#L8-L25
wo can fix it :
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -23,6 +23,7 @@ VERSION ?= 0.0.1
 # To re-generate a bundle for other specific channels without changing the standard setup, you can:
 # - use the CHANNELS as arg of the bundle target (e.g make bundle CHANNELS=candidate,fast,stable)
 # - use environment variables to overwrite this value (e.g export CHANNELS="candidate,fast,stable")
+CHANNELS ?= "stable"
 ifneq ($(origin CHANNELS), undefined)
 BUNDLE_CHANNELS := --channels=$(CHANNELS)
 endif
@@ -32,6 +33,7 @@ endif
 # To re-generate a bundle for any other default channel without changing the default setup, you can:
 # - use the DEFAULT_CHANNEL as arg of the bundle target (e.g make bundle DEFAULT_CHANNEL=stable)
 # - use environment variables to overwrite this value (e.g export DEFAULT_CHANNEL="stable")
+DEFAULT_CHANNEL ?= "stable"
 ifneq ($(origin DEFAULT_CHANNEL), undefined)
 BUNDLE_DEFAULT_CHANNEL := --default-channel=$(DEFAULT_CHANNEL)
 endif

Screenshot
No response
Logs
No response
System Info
- go 1.22
- operator-sdk 0.18.2
- client-go 0.30.1
- k8s 1.26

Severity
I can work around it

Duplicate of https://github.com/zncdatadev/trino-operator/issues/85


I want firstElementChild/lastElementChild and friends

They would be convenient. Recently had to use
var first = $(el).children().first()[0];

instead of
var first = el.firstElementChild;

and felt super-sad.

I felt super-sad too :crying_cat_face:.


Deprecate assert_display_snapshot, refactor macros

This PR:

Deprecates assert_display_snapshot in favor of assert_snapshot, as discussed in #379
Makes a sizable change in how macros are constructed:

It makes macros consistent — previously debug & display had different forms than the others, not taking a debug_expr.
The non-redaction macros are a simple wrapper of _assert_snapshot_base, which takes a closure transform of how to transform the input to a string.
The redaction macros are a simple wrapper of _assert_serialized_snapshot, which takes an arg format (similar to before), and uses that to construct a transform.
As a result, the boilerplate for each macros is removed.

It's not quite complete, but wanted to post before spending more time on it.
Still todo:

[x] We get a couple of test failures; I need to look into this; we seem to be generating an additional --- in some yaml snapshots. (possibly something is being converted to string twice?)
[x] Update docs; previously the debug_expr wasn't well documented, and now that the source is more opaque this is more important

This is updated, with all the tests passing, and better comments around the macros.
One thing that would make the code even simpler — serializing values the same for File and Inline. I think the only difference is that YAML snapshots lose the leading --- in files — is that right? Any reason not to remove for both files & inline?

Updated the docs at https://github.com/mitsuhiko/insta-website/pull/17

I will try to get this reviewed this week.

@mitsuhiko the gentlest of pings! Also will take feedback if you think it's not so great :)

I am in favor of this. I will try to get it merged and released ahead of backwards incompatible changes.

I am in favor of this. I will try to get it merged and released ahead of backwards incompatible changes.

Thanks!

Just a heads up, @mitsuhiko + @max-sixty - I have good reason to believe that these changes broke one of our tests. It seems like this version of the assert_yaml_snapshot macro takes ownership of the value, while previous versions only borrowed it. I can reproduce the test failures observed in https://github.com/rojo-rbx/rbx-dom/pull/398 on insta 1.36.0 (the version in which the changes in this PR shipped), but not on insta 1.35.1.

I'll take a look, thanks @kennethloeffler !

This is fixed in #453, apologies for the temporary break

It's perfectly okay - it's easy to see how this flew under the radar 😅

Sorry for that. I pushed out a fix!


fix: Resource group output in DA

Description
https://github.com/terraform-ibm-modules/terraform-ibm-secrets-manager/issues/214
Release required?

[ ] No release
[x] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
This PR fixes the resource group ID output in Secrets Manager Deployable Architecture.
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

:tada: This PR is included in version 1.18.9 :tada:
The release is available on:

GitHub release
v1.18.9

Your semantic-release bot :package::rocket:


az image copy fails with command ended with an error

If the issue is to do with Azure CLI 2.0 in-particular, create an issue here at Azure/azure-cli

Extension name (the extension in question)
image-copy
Description of issue (in as much detail as possible)
az image copy fails with command ended with an error. I believe it's because --source-uri is None when it makes the call to start the blob copy.
az image copy --source-resource-group standard --source-object-name standard-image --target-location southcentralus --target-resource-group standard --cleanup --verbose
Getting os disk id of the source vm/image
Creating source snapshot
Getting sas url for the source snapshot
Creating resource group: image-copy-rg
Target location count: 1
Starting async process for all locations
southcentralus - Creating target storage account (can be slow sometimes)
southcentralus - Creating container in the target storage account
southcentralus - Copying blob to target storage account
command ended with an error: ['/Users/npow/anaconda3/bin/python3', '-m', 'azure.cli', 'storage', 'blob', 'copy', 'start', '--source-uri', None, '--destination-blob', 'standard-image_os_disk_snapshot.vhd', '--destination-container', 'snapshots', '--account-name', 'southcentralusscrj7t3b6o', '--sas-token', 'REDACTED', '--output', 'json']
Deleting transient resources

@npow What version of the CLI are you using?
If it's 46 please update to 47 and try again (there's a problem with 46 that since was resolved).
If the issue also occurs on 47 then rerun the command with --debug flag and post the output here.

This is actually a duplicate of #318 which is resolved is later versions of the CLI.
@tjprescott @williexu can you close this?


docs: add missing CLI references

Added the missing references to scan and telemetry CLI commands.

Allow CI Workflow Run

[ ] approve CI run for commit: d7561e3ae36687d3e1061f28f4da2a34797e2ed9

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer


[Documentation]: Pie chart: Background color can be an array as well

Documentation Is:

[x] Missing or needed

Please Explain in Detail...
The documentation under https://www.chartjs.org/docs/latest/charts/doughnut.html lacks the information that backgroundColor can be a Color[], not just a Color.
Your Proposal for Changes
Like for data: number[], add an array descriptor to the type column.
Example
https://jsfiddle.net/38shmLt1/

Closing this, for more information see https://github.com/chartjs/Chart.js/pull/6450#issuecomment-520950454.


[Blockchain] Double-Edged Sword: Cryptocurrency both as an Enabler and a Solution to Ransomware

Proposed title of article
Double-Edged Sword: Cryptocurrency both as an Enabler and a Solution to Ransomware
Introduction paragraph (2-3 paragraphs):
Ransomware continues to emerge in a big way amid information security specialists’ warnings about this problem for years. The presence of newer malware enablers is only making matters worse. Cryptocurrency is one of such factors contributing to increasing ransomware popularity.
A number of players in the tech industry propose banning cryptocurrency use to mitigate these attacks. However, banning crypto may not work. Luckily, there are steps that we can take to limit the spread of ransomware attacks enabled by cryptocurrency usage.
Key takeaways:

The ransomware problem with Crypto
Crypto Ransomware (CryptoDefense, CryptoWall and CryptoLocker,)
Cryptocurrency Mining Malware
Cryptocurrency as a solution to ransomware

References:
N/A
Templates to use as guides

How To Guide Template
Software Review Template
Tutorial Template

Good afternoon and thank you for submitting your topic suggestion.
Your topic form has been entered into our queue and should be reviewed (for approval) as soon as a content moderator is finished reviewing the ones in the queue before it.

@BashiirIsla
Sounds like a helpful topic - lets please be sure it adds value beyond what is in any official docs and/or what is covered in other blog sites. (the articles should go beyond a basic explanation - and it is always best to reference any EngEd article and build upon it).
Please be attentive to grammar/readability and make sure that you put your article through a thorough editing review prior to submitting for final approval. (There are some great free tools that we reference in EngEd resources.)
ANY ARTICLE SUBMITTED WITH GLARING ERRORS WILL BE IMMEDIATELY CLOSED.
Please be sure to double check that it does not overlap with any existing EngEd articles, articles on other blog sites, or any incoming EngEd topic suggestions (if you haven't already) to avoid any potential article closure, please reference any relevant EngEd articles in yours. - Approved


Implement ensime:serverIndex goal.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@yyadavalli I've pushed your suggestion. Is it possible for you to merge and release a new version of the maven plugin soon?


figure out what we're going to do for pod presets

options:
-bake pod presets into our mutating webhook server
-convince kubernetes to make it part of the default apiserver
-make it its own repo and include it in the service catalog chart

This project is being archived, closing open issues and PRs.
Please see this PR for more information: https://github.com/kubernetes/community/pull/6632


Bug dupli

https://youtu.be/5jU_2WO81yY

I am unable to reproduce this issue, could you please attach your code and make sure you're not doing anything that could be causing this?

const DURABILITY = 3050;
const ATTACK = 9;
public function __construct(ItemIdentifier $identifier, string $name = "Unknown") {
    parent::__construct($identifier, $name, ToolTier::DIAMOND());
    $this->initComponent("etain_sword", 1, new CreativeInventoryInfo("equipment", "itemGroup.name.sword"));
    $this->addProperty("hand_equipped", true);
    $this->addProperty("damage", self::ATTACK);
    $this->addComponent("minecraft:durability", CompoundTag::create()
        ->setTag("damage_chance", CompoundTag::create()
            ->setTag("max", new IntTag(100))
            ->setTag("min", new IntTag(100))
        )
        ->setTag("max_durability", new IntTag(self::DURABILITY))
    );
}

const DURABILITY = 592;
const PROTECTION = 8;
public function __construct(ItemIdentifier $identifier, string $name = "Unknown") {
    parent::__construct($identifier, $name, new ArmorTypeInfo(self::PROTECTION, self::DURABILITY, ArmorInventory::SLOT_CHEST));
    $this->initComponent("cobalt_chestplate", 1, new CreativeInventoryInfo("equipment", "itemGroup.name.chestplate"));
    $this->addComponent("minecraft:wearable", CompoundTag::create()->setString("slot", "slot.armor.chest"));
    $this->addComponent("minecraft:armor", CompoundTag::create()->setInt("protection", self::PROTECTION));
    $this->addComponent("minecraft:durability", CompoundTag::create()->setInt("max_durability", self::DURABILITY));
}

Twisted ?

This is the same logic I used as well. Could you try again with a server that only has Customies and this item registered?

yes, i go

I managed to fix this bug but now I have another bug with CustomBlocks
https://youtu.be/RJrP1o7_0no

Could you attach the code you are using to register these blocks, and could you also try disabling all your plugins apart from customies and the one used to register the block?

This is my block:
$material = new Material(Material::TARGET_ALL, "cobalt_block", Material::RENDER_METHOD_ALPHA_TEST);
$model = new Model([$material], "geometry.block", new Vector3(-8, 0, -8), new Vector3(16, 16, 16));
$creativeInfo = new CreativeInventoryInfo(CreativeInventoryInfo::CATEGORY_CONSTRUCTION);
CustomiesBlockFactory::getInstance()->registerBlock(fn(int $id) => new CobaltBlock(new BlockIdentifier($id, 1), "cobalt_block", new BlockBreakInfo(3.0, BlockToolType::PICKAXE, ToolTier::IRON()->getHarvestLevel())), "minecraft:cobalt_block", $model, $creativeInfo);
    And it is my class
    class CobaltBlock extends Block {

public function __construct(BlockIdentifier $idInfo, string $name, BlockBreakInfo $blockBreakInfo) {
    parent::__construct($idInfo, $name, $blockBreakInfo);
}

public function getDropsForCompatibleTool(Item $item): array
{
    return [ItemFactory::getInstance()->get(1, 1, 1)];
}

public function getSilkTouchDrops(Item $item): array
{
    return [ItemFactory::getInstance()->get(1, 1, 1)];
}

}

twisted ?

I don't see anything wrong with your code, did you test this with only Customies and the plugin registering these blocks? Please attach a picture of the output from /pl just to be sure

@TwistedAsylumMC can you send a template plugin for du this more easily please

ok twisted, we have a problem, when we do a simple plugin to add one block, it's work but, when we add an other block, it place the block UPDATE, but UPDATE it just a textures


bar is on top my layout

the problem is that the bar is floating above the layout, so the space where the bar is blocked,
even with scrollview it is not possible to get reach it.
is there a way to make the bar not float
?

Can you provide me some details how you're using the BottomBar in your layout?

I had the same problem. But in my case it was a easy to solve it. Because now the BottomBar is a widget in the xml layout, that means that you have to specify a position in the layout. For example this is my layout
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <FrameLayout
        android:id="@+id/fragment_container"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_marginBottom="60dp"/>

    <com.roughike.bottombar.BottomBar
        android:id="@+id/bottomBar"
        android:layout_width="match_parent"
        android:layout_height="60dp"
        android:layout_gravity="bottom"
        app:bb_tabXmlResource="@xml/bottombar_tabs" />
</FrameLayout>

I was using a FrameLayout as a Parten container and one of the rules of a FrameLayout is that all the View in the container will overlap, so in my case i just gave a marginBottom to "@+id/fragment_container"  of 60dp (The size of the BottomBar).
Hope it helps!

yes thank you very much!


use render :partial when rendering a partial

Even though render :template works, the templates that are
being referenced are partials. By using the recommended API we reduce
non-standard things in the code.
I also suspect, but cannot proof, that render partial behaves slightly
different with the locals hash.

For built in page types this holds true, but for plugin based page types deriving from PageType the template is actually located at pageflow/somthing/page.erb.html (i.e. in the pageflow-panorama gem).
I can't really say what the objective of not using a partial here originally was, but far as I can tell this change would break compatibility. The fact that the tests still pass indicate a lack of coverage regarding this plugin interface.

Okay, clear. I will raise an issue to improve test coverage.


Duplicate of #43264


Charts repo index file should use github release / git commit date as created

Expected Behavior

Each release in https://projectcalico.docs.tigera.io/charts/index.yaml should have the matching release date as created value.
Renovate is using this to decide certain stabillity^1, so  i need to disable that feature.
Current Behavior

All versions always have the latest update date as  created value.
Possible Solution

Use the github release date or the corresponding git commit date as created value .
Steps to Reproduce (for bugs)

download https://projectcalico.docs.tigera.io/charts/index.yaml
check created property of each release

Context

I use renovate to update my charts via terraform.
Your Environment

Calico version v3.22.4 (becaus i never got an update by renovate)
Orchestrator version (e.g. kubernetes, mesos, rkt): k3s 1.24.4
Operating System and version: Ubuntu 20.04 (migrating to 22.04)
Link to your project (optional):

ISTR we had some 'fun' with incrementally adding releases to the index, and I ended up just rebuilding the index from scratch every release, which is what leads to this behaviour.

What does a typical "helm chart index updater" CI pipeline look like? Do you have any examples you can point me at please?

FWIW, the current pipeline is grabbing all the helm charts for each release, putting them into a charts directory, then doing:
"cd charts && helm repo index . --merge index.yaml.bak --url https://github.com/projectcalico/calico/releases/download/"

most repos are using chart releaser for this
https://github.com/renovatebot/helm-charts/blob/d8b34a357443cabb0c9a6403fda368b342007dfb/.github/workflows/release.yaml#L41

Thanks, I'll go comb through the source and see if I can figure out how it works.  We don't use github actions for CI, otherwise this would be easy.

you can also use the chart releaser without GitHub actions, the action is just a wrapper for the cli tool.
https://github.com/helm/chart-releaser

:+1:  Of course we don't use github to host the index either, but yes, using the CLI tool seems like a good start.


Why simple CentOS-HPC VM is failing?

az vm create --resource-group hpc-my --name ansysVM --image OpenLogic:CentOS-HPC:7.4:latest --admin-username username123 --admin-password pswd --size Standard_H8
This image requires --osDisk parameter. I don't understand why…
What is the correct set of parameters to deploy CentOS-HPC image?

Deployment failed. Correlation ID: 33ac9c21-9a80-4b5e-81f9-a0f7a4699528. {
"error": {
"code": "InvalidParameter",
"target": "osDisk.managedDisk",
"message": "The value of parameter osDisk.managedDisk is invalid."
}
}

Environment summary
az-cli version 2.0.43
Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)

Should not the CentOS image be automatically attached to the osDisk? Should not this be an automated procedure run in the background?

For whatever it is worth, I just ran the same command on az @ 2.0.44 on a windows box, and the command succeeded. I created the VM in the westus location.

@lmiroslaw please make sure you are not updating an existing VM with conflicting configurations; then run the vm command with --debug and send me the trace with the error at yugangw at microsoft dot com
I am closing this as it is unlikely a CLI issue, but I will reactivate once get a repro


msvc-dev-cmd action stopped working

I have been using the mscv-dev-cmd in a couple of my github workflowss to set the VC environment variables.
This stopped working across the board a couple of weeks ago, without any changes to the workflow scripts.
So I am assuming that this is related to an upgrade of windows-latest in gh-workflows.
This is one of the relevant recipes: https://github.com/constantinpape/z5/blob/master/.github/workflows/build.yml
And here is a PR where the windows CI fails: https://github.com/constantinpape/z5/pull/181. See also the full error message below.
Any ideas on how to fix this would be highly welcome.
Run<EMAIL_ADDRESS>Found with vswhere: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat
'"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\vsdevcmd\ext\**********************************************************************"' is not recognized as an internal or external command,
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
operable program or batch file.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
'"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\vsdevcmd\ext\**"' is not recognized as an internal or external command,
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
operable program or batch file.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
'"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\vsdevcmd\ext\**"' is not recognized as an internal or external command,
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
operable program or batch file.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
'"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\vsdevcmd\ext\**********************************************************************"' is not recognized as an internal or external command,
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
operable program or batch file.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\)" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\Windows" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\)" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\set" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\)" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\D:\a\z5\z5" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\C:\Program" could not be found.
Error: [ERROR:VsDevCmd.bat] Script "vsdevcmd\ext\[vcvarsall.bat]" could not be found.
Error: [ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
Error: [ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
Error: [ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
Error: [ERROR:VsDevCmd.bat] Where [value] is:
Error: [ERROR:VsDevCmd.bat]    1 : basic debug logging
Error: [ERROR:VsDevCmd.bat]    2 : detailed debug logging
Error: [ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
Error: [ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
Error: [ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1
Error: Could not setup Developer Command Prompt: invalid parameters

Uh-huh... Thanks for a report, @constantinpape!
I'm able to reproduce the issue with both windows-2016 and windows-2019 environments so that's not it. The real reason seems to be related to the conda-incubator/setup-miniconda step that your builds perform before setting up MSVC environment. That seems to conflict with something (maybe some shell defaults, or whatnot), making vcvarsall.bat output something really unexpected that msvc-dev-cmd cannot parse.
Reordering build steps seems to help. I've sent you a PR with a workaround. That should at least let you have a green build while I'm figuring our what exactly Python env breaks in MSVC scripts.

I'm able to reproduce the issue with both windows-2016 and windows-2019 environments so that's not it. The real reason seems to be related to the conda-incubator/setup-miniconda step that your builds perform before setting up MSVC environment. That seems to conflict with something (maybe some shell defaults, or whatnot), making vcvarsall.bat output something really unexpected that msvc-dev-cmd cannot parse.

Ok, good to know. I was just assuming that this was due to the latest windows build because this set up did work for me until a couple of weeks ago. But I guess some other change must have triggered the issue then.

Reordering build steps seems to help. I've sent you a PR with a workaround. That should at least let you have a green build while I'm figuring our what exactly Python env breaks in MSVC scripts.

Thanks!


Poetry fails because it tries to install an unneeded dependency

[x] I am on the latest Poetry version.
[x] I have searched the issues of this repo and believe that this is not a duplicate.
[x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

OS version and name: Ubuntu 16.04
Poetry version: 0.11.5
Link of a Gist with the contents of your pyproject.toml file: Sorry, can't upload due to it being a project at work. But I think it should not be relevant to the error, as my file is very minimal. I specify python 3.6 as a requirement.

Issue
Hi guys,
I tried out poetry because pipenv has unresolved dependency conflicts, where they should not happen.
Unfortunately, something similar happenend to me now with poetry.
In my dependencies, I use a private module which requires shove>=0.6.6. With pipenv, this installs without a problem:

With poetry, it tries to install the package futures==3.2.0, which is clearly not compatible:

Updating dependencies
Resolving dependencies... (34.5s)
Package operations: 42 installs, 26 updates, 0 removals
Writing lock file

Installing futures (3.2.0)

[VenvCommandError]
Command ['pip', 'install', '--no-deps', '--index-url', 'xxxx/repository/pypi-all/sim
ple', 'futures==3.2.0'] errored with the following output:
Looking in indexes: xxxx/repository/pypi-all/simple
Collecting futures==3.2.0
Using cached xxxx/repository/pypi-all/packages/1f/9e/7b2ff7e965fc654592269f2906ade1c7d705f1bf25b7d469fa153f7d19eb/futures-3.2.0
.tar.gz
futures requires Python '>=2.6, <3' but the running Python is 3.5.2
install [--no-dev] [--dry-run] [-E|--extras EXTRAS] [--develop DEVELOP]

According to poetry show --tree, futures is a requirement for shove:

This seems not right to me and I don't understand the different behavior in comparison to pipenv.
Thanks!

Thanks for reporting this and sorry about that!
This has already been fixed on the develop branch and the fix will be officially released in the next 0.12 version.
You can already try it if you want by installing the current 0.12 pre release, preferably by using the new recommended installer.
curl -sSL https://raw.githubusercontent.com/sdispater/poetry/develop/get-poetry.py

See https://github.com/sdispater/poetry/blob/develop/docs/docs/index.md#installation for more information

Thanks for the quick reaction, I will try that!

Hmm, with version 0.12.0a2, the same error happens, futures is in the pyproject.lock-file as a dependency of shove :(

futures is in the pyproject.lock file because it is indeed a dependency of shove. However, now, Poetry will now choose a version of futures <3.2.0 which does not have a Python restriction.
Basically, shove does not use environment markers to tell that futures should be installed only for Python < 3.0 so Poetry can only assume that it is a strict dependency.
This is an issue upstream and should be fixed by the shove maintainers.


Unable to synchronize to Github

Hello Team,
I have a private repository. I have been using Stackedit (online version) for long time. Recently I am not able to open from Github or create any new file on Github using StackEdit application. I get following error for the rest api in my browser network console: 401 error.
API: /repos/{owner}/{repo}/contents/{path}
{
    "message": "Bad credentials",
    "documentation_url": "https://docs.github.com/rest"
}

I revoked the access from Githhub and authorised it again. But this isn't resolved the issue.
Thank you,

https://github.com/benweet/stackedit/pull/1724

My fork repo has fixed this bug.
StackEdit+ : https://stackedit.net
open source: https://github.com/mafgwo/stackedit-plus

Should be fixed with v5.15.0.


pin m-jar-p version, fixes Reproducible Builds issue

see https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/net/osslabz/crypto-commons/README.md

thanks, very helpful!


Speedtest Tracker tries to connect to PG using root login

Describe the bug
The Speedtest Tracker container seems to intermittently not use the provided PG login credentials. I have specified DB_USERNAME and DB_PASSWORD, but intermittently I get auth log failures in the Postgres logs.  I changed the IP of the Speedtest Tracker container to confirm it was the source of the logs, and it is. Otherwise, results and notifications are stored in the database under the proper username.
Environment (please complete the following information):

OS: Debian
Architecture: amd64, Docker, LSIO container
Browser n/a
Version 0.19.0
Postgres 15

Logs
postgresql-15-main.log.1:2024-05-05 06:33:10.960 EDT [1904103] root@root FATAL:  no pg_hba.conf entry for host "<IP_ADDRESS>", user "root", database "root", SSL encryption
postgresql-15-main.log.1:2024-05-05 06:33:10.962 EDT [1904127] root@root FATAL:  no pg_hba.conf entry for host "<IP_ADDRESS>", user "root", database "root", no encryption
postgresql-15-main.log:2024-05-16 15:10:39.707 EDT [2828520] root@root FATAL:  no pg_hba.conf entry for host "<IP_ADDRESS>", user "root", database "root", SSL encryption
postgresql-15-main.log:2024-05-16 15:10:39.710 EDT [2828529] root@root FATAL:  no pg_hba.conf entry for host "<IP_ADDRESS>", user "root", database "root", no encryption

You probably started the container before setting the initial creds, if you don't have anything in your PG db delete it's volume and let it rebuild with the new authentication credentials.

Where are you specifying your DB_ environment variables?

docker-compose:
        environment:
            TZ: ${tz}
            PUID: '17683'
            PGID: '17683'
            DB_CONNECTION: 'pgsql'
            PUBLIC_DASHBOARD: 'true'
            APP_NAME: 'speedtest tracker'
            DB_HOST: postgres.internaldomain.example
            DB_PORT: 5430
            DB_DATABASE: speedtesttracker
            DB_USERNAME: speedtesttracker
            DB_PASSWORD: <redacted>
            FORCE_HTTPS: 'true'
            HOME: /config
            CACHE_DRIVER: 'database'

A .env is created on startup if it's missing, make sure the DB_ variables there are commented out to avoid collisions.

Looks like it knows to not write the DB_ variables to the .env in the container.
root@host:/home/user/dockerdata/speedtest-tracker# less .env
# A full list of options can be found in the '.env.example' file.

# Application key
# Used for encryption where needed, if a key is not generated run: php artisan key:generate
APP_KEY=base4:redacted=

# Application URL
# Not used in the URL but effects links in emails and notifications: https://docs.speedtest-tracker.dev/faqs#links-in-emails-dont-point-to-the-correct-url
APP_URL=http://localhost

# SMTP mail config
# Only SMTP protocol is supported at this time: https://docs.speedtest-tracker.dev/settings/notifications/mail
MAIL_MAILER=smtp
MAIL_HOST=mailhog
MAIL_PORT=1025
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
<EMAIL_ADDRESS>MAIL_FROM_NAME="Speedtest Tracker"

# Telegram bot config
TELEGRAM_BOT_TOKEN=null

Honestly if it only happens from time to time, I'd ignore it at this point.

That's fair enough haha. I'll keep an eye on it in case it stops working.


Implement flake8 copyright

Summary
Add Flake8_copyright to check copyright headers exist in files.
Configurable settings include copyright regexp, author, and character spacing until copyright regexp.
Closes https://github.com/charliermarsh/ruff/issues/3579
Test Plan

How was it tested?
cargo test
also tested locally via
select = ["C801"]

[flake8-copyright]
copyright-regexp = "(?i)Copyright \\d{4} \\(C\\"
copyright-author = "ruff"
copyright-min-file-size = 300

cargo dev generate-all; cargo run -p ruff_cli -- check /Users/ryang/cs/ruff/crates/ruff/resources/test/fixtures/flake8_copyright/C801_custom_regexp_pass.py --select C801 --no-cache --config=$(readlink -f ruff.toml)

Hi, I made a first stab at implementing https://github.com/charliermarsh/ruff/pull/4701 flake8-copyright
However, it seems like the "pre-commit" check in CI is failing due to a lack of copyright headers on some python files in the scripts directory https://github.com/charliermarsh/ruff/actions/runs/5115146921/jobs/9196121487?pr=4701
Wondering if it would be preferable to add the copyright header, disable the check or add noqa C801?
When I tried adding noqa, when emulating CI and running the command locally, it would overwrite my changes.

Sorry if this was documented somewhere/asked again, but wondering if there's a group of people to assign as reviewers for PR's?

Addressed comments
This PR should be good for re-review. However, the CI problem still lingers. I tried adding # noqa: CPY801 to the python files, but autofix removes the line. I could add a line to these scripts such as # Copyright (c) 2023 ruff or is there a way we can disable this check when running ruff on this repo for that particular github action?

Sorry, missed that question -- can we add CPY to the ignore in scripts/pyproject.toml?

TIL nested pyproject.toml. Neat!

addressed all comments. Wondering if @charliermarsh or @MichaReiser could re-review please?

Hi! Cool to see a another new rule has landed.
Two comments - as seen in 0.0.237:

The listing of linters appears inconsistent:
$ ruff linter
[...]
 COM flake8-commas
     CPY Copyright-related rules
  C4 flake8-comprehensions
[...]

That line should have been  CPY flake8-copyright, I think.

The docs say This rule is part of the nursery, a collection of newer lints that are still under development. As such, it must be enabled by explicitly selecting CPY001., but enabled already using CPY (broader). Could it be an accidental copy/paste from some E-rules?

Thanks for this. I had intentionally renamed to "Copyright-related rules" but perhaps that was a mistake.
(I think it's probably a bug that --select CPY works... but it's not a big deal in this case since the category only has the one rule, so I might not even bother to fix :joy:)


[ci] use shorter job names

Current CI job titles are too long for the visualisation in GitHub, both at the bottom of PRs and in the Actions sidebar.  This PR makes the names shorter by removing the content in parens.

While this makes the names shorter, this is useful information. And removing the trailing part does not improve which part of the name is visible.

@YuriSizov long names hide execution time of the jobs at the bottom of PRs.
Currently:

In this PR:

Furthermore, at least the target argument feels redundant because all the jobs with target editor are named Editor and all the ones with target template_release are named Template.
If the information is useful (particularly in the four jobs with longer names), I believe there are better solutions to show it. Currently they can only be read by clicking on the 'Details' and going to the job run view (e.g. https://github.com/godotengine/godot/actions/runs/4522307823/jobs/7964678551?pr=75325). It's not readable in the sidebar, nor in the graph. Therefore, we might have a step that prints those argument, right after 'Set up job'. That would show the info in the same page (joust a couple of rows below), and it would fix the issues.
Moreover, we might use the GITHUB_STEP_SUMMARY to have that info shown at the bottom of the summary, next to the list of artifacts. What do you prefer?

I updated this PR to print the "INFO" as the first step of the jobs. I did not include the "target" field, so the jobs that had that argument only don't have an INFO field. Click on the Details of the checks in this PR to see the output. For instance: https://github.com/godotengine/godot/actions/runs/4526609969/jobs/7971901828?pr=75333.
Moreover, branch https://github.com/umarcor/godot/tree/umarcor/ci/info is one commit ahead of this one. That prints the content to GITHUB_STEP_SUMMARY. As a result, apart from the info being shown as a step in each job, it's shown in the summary of jobs. See, for instance: https://github.com/umarcor/godot/actions/runs/4526572433/jobs/7971836148 and https://github.com/umarcor/godot/actions/runs/4526572433. Note that the summary is shown after the job is finished, not right after the step is executed.

long names hide execution time of the jobs at the bottom of PRs.

Is this the only reason for the changes? Why is the execution time of the CI important? It's not a stable value, it fluctuates throughout the day and depending on the Actions agents availability. So it doesn't provide any useful information to contributors. It's useful mostly to some engine maintainers to investigate if we have a congestion or other issues. But we don't seem to have an issue with the current way things are.
I appreciate the effort, but this sounds like a non-problem, and thus there is no need to look for a solution.

Execution of CI is important for contributors who are waiting for CI to finish...
Yet the reason for the changes is semantic. The name or title should contain the name or title, not metadata. Doing so breaks 3 of the 4 places where the name is shown in the GitHub web frontend. I find it difficult to understand why that's a no problem since it feels as an obvious symptom that something is not being used as it should. Using features as intended prevents future unexpected issues.
Could you please explain why the current implementation in this PR does not satisfy the needs of those who need to see that metadata?

Execution of CI is important for contributors who are waiting for CI to finish...

Whether a CI run has finished or not is displayed with a status icon. The time being visible doesn't help with waiting whatsoever.

Using features as intended prevents future unexpected issues.

If there are any actual issues, we can work on them and discuss a solution. Making these changes just because some of the UI doesn't look neat and clean is not a good rationale.

Could you please explain why the current implementation in this PR does not satisfy the needs of those who need to see that metadata?

The point of having this data in a very visible place is for it to be easily visible. Both during runs and during configuration/reading the config. Prints are hidden in the execution steps. We already print all configuration flags during the actual compilation, so adding an extra info print step doesn't actually add anything useful or make it easier to find.
Again, contributions should come from actual problems first, and I don't see an actual problem being solved here.

The time being visible doesn't help with waiting whatsoever.

It's the status, the time, plus whatever GitHub decides to dynamically put after the job name since the PR is created/pushed until it's merged.
Execution time can be important when a job failed because it lets the contributor know if something is preventing the job from starting, or it did start but it failed after several minutes.

If there are any actual issues, we can work on them and discuss a solution. Making these changes just because some of the UI doesn't look neat and clean is not a good rationale.

GitHub users might want to use the features provided by GitHub. I personally like reading the status information at the bottom of the PRs when I'm contributing to a project.
Is your judgement to decide whether breaking UI is irrelevant? I would please ask to have this discussion opened to other maintainers. It seems to be an opinion that having redundant text breaking UI is worth.

The point of having this data in a very visible place is for it to be easily visible. Both during runs and during configuration/reading the config. Prints are hidden in the execution steps. We already print all configuration flags during the actual compilation, so adding an extra info print step doesn't actually add anything useful or make it easier to find.

Visibility and readability during runs:
current,

in this PR,

and the flags print during compilation (which requires scrolling and expanding one step),

Visibility and readability when reading the config:
current,

in this PR,

Again, contributions should come from actual problems first, and I don't see an actual problem being solved here.

According to your previous statements, you deem it negligible, but you do see the problem, which is UI being broken and info being hidden in the PR checks view.

The name should contain what we want it to contain. You are indeed creating a semantical problem with an arbitrary limitation in this statement.

The arbitrary limitation I'm trying to create is "do not break the UI unnecessarily since users might want to use it". I believe it's rather sensible.

I'm sorry, I don't think the build time is relevant. It's not a useful piece of information, and I would ask you to trust me on that, because I look at dozens of Godot PRs daily (including waiting on them to finish so I can merge them). Maybe it's something that can be referred to in other projects, but at our scale, build time is not something a regular contributor can use in a meaningful way (and relying on it can be misleading).
So that's a non-problem to me that the UI "breaks". And thus I don't think that moving the important text to the build logs is justified, even if you can make an argument that your proposed logs are slightly better than existing logs.

just wait to see if other people want to participate in the discussion.

let me chip in from a position of very casual contributor. @umarcor I think I am in the same shoes as you are - very eager to help, and where else to help than in the domain you understand the best. Such contributions are definitely welcome, that's the way how open source projects can flourish. Unfortunately for me Godot is primarily the game engine and C which is not my domain. So I can keep digging through the other parts which I understand (ci/buildsystems), keep discovering non-issues there, which then I can "fix". Sometime I hit, sometime I miss.
In this particular PR, what issue does this solve? All boils down to "build time is not shown" (?) I agree with Yuri here - this information is not really useful in the big picture of the project. You mentioned "execution of CI is important for contributors who are waiting for CI to finish." Never heard anyone anywhere mentioning this. Do you have any datapoints supporting this claim please? Even if this would be a real issue, this information is still not useful - the build times are unpredictable so seeing the execution time doesnt help anything. And even then if this information would be really essential to have, then the issue should be directed to Github and the UI of Actions rather than the project here.
So I would say if it's not broken dont fix it. There is easily hundred of similar non-issues in the project, but I think instead of bikeshedding we should let the maintainers focus on the important things.


Filter 'andOperator' per Filter instead of globally

This is a feature request:
Adding Filters individually with a boolean operator, instead of having one boolean operator for connecting all filters.
Example:
Now all filters are applied either by the AND operator or OR operator, which means expressions like:
filter1 && filter 2 && filter 3 && filter 4
filter1 || filter 2 || filter 3 || filter 4

It would be great to be able to add filters individually with their preceding operator to the filter chain.
source.addFilter(filter1, false);
source.addFilter(filter2, true);
source.addFilter(filter3, false);
source.addFilter(filter4, true);

would result in the following filter chain:
filter1 && filter2 || filter3 && filter4

Hello @cgebe !
I see that source object already supports this method: https://github.com/akveo/ng2-smart-table/blob/master/src/ng2-smart-table/lib/data-source/local/local.data-source.ts#L169
Does this method satisfy your goals?


minor code fix on documentation page

What does this Pull Request accomplish?
It is documentation typo fix
Why should this Pull Request be merged?
Fix the documentation typo fix
What testing has been done?
No testing done.

/docs/ changes not required to run the pipeline. Bypassing branch protection to merge this PR.