Wrong result if program reads no input.

If tested program reads no input (but the testcase has input), it can termiante before we write the input to the stdin and it will cause IOStreamException Broken Pipe or Stream Closed. Then the result will be "aborted" while it should process the testcase normally comparing output with expected output.

When is such a scenario expected to arise?

Not too often, for sure. Although it did come up for Krig as you can see :)

OK. I tried a couple of problems from codeforces to get the situation (mentioned above).
But in all the cases hightail seems to be working fine.
Please correct me if my understanding of the issue is incorrect:
If we have a problem which takes no input, and in hightail we have specified some input, then since the program will terminate before anything would be written to stdin, and hence IOStreamException is expected to be thrown. Right?
@Krigpl Can you please share a link to the problem, while testing which you encountered this exception?
PFA the screenshot:

It was quite a long time ago and I don't recall any details. But if it
seems to be working now I would assume the bug is gone.
2015-07-26 21:21 GMT-07:00 ASTGS<EMAIL_ADDRESS>
OK. I tried a couple of problems from codeforces to get the situation
(mentioned above).
But in all the cases hightail seems to be working fine.
Please correct me if my understanding of the issue is incorrect:
If we have a problem which takes no input, and in hightail we have
specified some input, then since the program will terminate before anything
would be written to stdin, and hence IOStreamException is expected to be
thrown. Right?
@Krigpl https://github.com/Krigpl Can you please share a link to the
problem, while testing which you encountered this exception?
PFA the screenshot:
[image: hightail_bug_1]
https://cloud.githubusercontent.com/assets/9794969/8898626/f8c6bfbc-3444-11e5-9c60-9f0d3b179e54.jpg
—
Reply to this email directly or view it on GitHub
https://github.com/dj3500/hightail/issues/42#issuecomment-125081799.


Broken deleteDir

I'm not sure if this is a problem with the OpenStack SDK or the adapter, but deleteDir ends up throwing an exception ""containerName" is a required option, but it was not provided".
The adapter is very simple, it just uses listObjects on the container with a prefix, and then calls the delete method on each object returned by listObjects. From what I understand, the objects returned by listObjects do not have their containerName property set on them, which is why we get the error when delete is called on them.
So the deleteDir method can easily be fixed by specifying the container on each object like this:
public function deleteDir($dirname)
    {
        $objects = $this->container->listObjects([
            'prefix' => $this->applyPathPrefix($dirname)
        ]);

        try {
            foreach ($objects as $object) {
                $object->containerName = $this->container->name; //The fix
                $object->delete();
            }
        } catch (BadResponseError $e) {
            return false;
        }

        return true;
    }

I'm just not sure if it was intended to be like this in the SDK or if it's a bug.
Here's a PR with the fix for now.

Many thanks for reporting and fixing this. Closing this issue now.

Please release package update, the only option to get this fix is by using dev-master (via composer).


(1.20-pre1 - 24w07a) Menu background

As of 24w09a, the background used for menus is now used as-is. Previously, a copy of the dirt texture was used, which was darkened by the game, but it now uses a pre-darkened texture and the game does not apply any changes to it.
Implementing this into MC-TextureGen would be useful as it could be used to convert existing textures from resource packs into the new format.


Create reference page for use of metrics/audit info around deprecated API calls

This is a Feature Request
What would you like to be added
A reference page containing the information in https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings in a form that can be translated, kept up to date, and linked to from other reference pages.
Why is this needed
Suggested in review of https://github.com/kubernetes/website/pull/26483#discussion_r575838546
When this page is added, links to the blog post from reference pages (like the page added in https://github.com/kubernetes/website/pull/26483) should be updated to point to the reference docs.

/kind feature
/priority important-longterm
/triage accepted


RFP - r

The underlying project of RStudio
https://www.r-project.org/

There is already a package pushed, however it is unlisted:
https://chocolatey.org/packages/r
If I am not mistaken, I believe that someone was working on this.

Idk.. its up to date overhere
https://npackd.appspot.com/p/r


Clang messages can not close

I use coc-clangd and i have this issue on https://github.com/clangd/clangd/issues/833
They said it related to coc-clangd.
Is this is bug or i miss config ?
Thanks for your help

Upgrade your coc.nvim to latest release, this has been fixed already.

What's your CocInfo? Upgrade your coc.nvim to latest release, this has been fixed already.

Here my CocInfo

I coc.nvim is up to date but it doesn't fix

@Hungpro3112 https://github.com/neoclide/coc.nvim/issues/3171

@Hungpro3112 upgrade your coc to latest release and try again.

@Hungpro3112 upgrade your coc to latest release and try again.

It works. Thank you


Windows: Linkage error when opt-leve=z and crt-static is used

I tried to compile a project on Windows and I was getting linkage error. After some investigation I found the it has to do with opt-leve=z (set in Cargo.toml) and -Ctarget-feature=+crt-static (set in RUSTFLAGS env var). If I omit one of the two, the everything works, however this is not an option for the actual project.
I created a repo that replicates the problem:  oblique/optlevel-z-crt-static-issue.
You can view the linkage error here.
I have no idea why this is caused since I don't have a lot experience with Windows. Also I'm not sure if this is a bug in rustc.

@alexcrichton Since you have more experience for -sys and -src crates. Do you have any Ideas on how to fix this? /GL- is already used. Do you think that I should post this in Rust repo?

I don't have much experience with windows either I'm afraid, so I won't be able to help much.

I'm not so certain myself unfortunately, but this looks like it's sort of a routine linking error where either the C standard library isn't specified or it's the wrong C standard library by accident (/MD vs /MT)

If I add -Copt-level=z in RUSTFLAGS, for some reason it works. In this case -Copt-level=3 -Copt-level=z is passed to rustc (the -Copt-level=3 part is added by cargo). This is more confusing.
I think I'm going to open an issue in Rust. It looks like a bug.


PA-ELR System Maintenance Scheduled - 4/29 5-7PM

Problem Statement
We received an email in the ReportStream inbox from PA-ELR regarding scheduled system maintenance that will affect connectivity.
What you need to know
Email received:

This email is to notify PA-ELR users about the upcoming Production environment for PA-ELR services and PA-NEDSS unavailability.
PRODUCTION environment services – PA-ELR services and PA-NEDSS - will be unavailable for system maintenance on Monday, April 29, 2024, 5 PM EST until approximately 7 PM EST.
This will affect PA-ELR manual file uploads and automated file uploads, including ELR web service, PAWS, HIE/PHG and PHINMS.
During this time span if you attempt to submit files to Production PA-ELR, you will receive a message stating that it is currently unavailable for maintenance.
If you receive the error message, please only resubmit files during this time span after being notified services are available.
Please share this information provided with other members of your organization that may not have received this email.

Acceptance Criteria

[x] Check on 4/30 or later that no messages have failed to be delivered to PA
[x] If messages have failed to be delivered, resubmit successfully

No messages failed to be delivered to PA during this time


Change issues link from GitHub issues to JIRA

Change issues link from GitHub issues to JIRA
Description
Contributor document refers to GitHub issues as the issue tracker while it looks like Apache JIRA is being used for the purpose.
Status
done, ready for review
Checklist (tick everything that applies)

[ ] Code linting (required, can be done after the PR checks)
[x] Documentation
[ ] Tests
[ ] ICLA (required for bigger changes)

Codecov Report

Merging #1302 into trunk will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##            trunk    #1302      +/-   ##
==========================================
- Coverage   85.97%   85.97%   -0.01%
==========================================
  Files         362      362
  Lines       74191    74191
  Branches     6728     6728
==========================================
- Hits        63789    63787       -2
- Misses       7711     7712       +1
- Partials     2691     2692       +1

Impacted Files
Coverage Δ

libcloud/test/compute/test_upcloud.py
90.06% <0%> (-1.33%)
:arrow_down:

Continue to review full report at Codecov.

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

Thanks for the contribution.
We have recently moved all the development away from JIRA to Github so the documentation is corrected - https://github.com/apache/libcloud/pull/1297.
All the references to JIRA were also removed from our website and replaced with Github. If you still find a reference to JIRA somewhere, let us know and we will fix it.
JIRA should also be read-only now so new issues can't be created anymore.

My bad, there are no issues in Github so thought the document was outdated.
Thanks for the clarification, will the issues be migrated over to Github issues now or only new issues are created in GitHub?

Old JIRA issues won't be migrated, but existing JIRA project will stay online in a read-only mode for the foreseeable future.
And as per ASF policy, all the existing JIRA issues (creation, updates, deletes, etc.) are also archived on the mailing list (so even if we delete the JIRA project or similar, all the old JIRA interactions are still archived).


Permissions changes on zone detail page

It appears that if you try to remove a user from a container, or change their level, it might not be for the right user (the "are you sure?" prompt shows a different username than the one selected for removal).  This also appears to affect changing user levels on the same container detail page (its actually changing for some other user..

I haven't been able to reproduce this error. Everything seems to be working fine for me. I'd thought that maybe, if you delete a user (removing one of the rows) it might cause the table to misalign so that the button links appear in the wrong rows. But even after deleting users, I've only seen the appropriate behavior.

Yeah, I have the same issue.. but when I look at production, zone.centralcomputing, I see the bug.  Is this some sort of.. cookie issue? or..?

That was the example I needed. Fix is up at https://github.com/OSU-Net/cyder/pull/1035


Enhancement/Feature Request: align-right and align-center generic classes

It would be really nice if bootstrap included a generic class to align the contents of a div to the right (a center-align class would be nice as well). I couldn't find a way to do this that worked correctly inside of a column div on Bootstrap 4.0.0.alpha3
Example:
.align-right
{
  text-align: right;
}

<div class="align-right">
  Right-Aligned Text
</div>

It's exist
Responsive floats
or
Text alignment

Closing per @fchiumeo


Include cache headers in 304 responses

Fixes #2059

Nice! So it was just a bug from the ordering of the imports?

I've changed the order of plug applications, which is simply changing the order of function application as each plug is a function. Now, we first set the response headers on the conn struct, then perform the Etag check which may return early in case the Etag in the request header matches.


To ES6 and added Turkish support

@dortonway I'd love to have Turkish support; are you willing to reopen this PR and revert the es6 changes?

@ljharb I work on the fork at work and unfortunately we don't have time for open source.
The thing about Turkish is simply to take the second variant if it's provided in translation and if amount > 1.

It seems like an odd choice to fork something and fundamentally rewrite it, if you want to keep being able to use upstream changes :-/
Hopefully someone will be able to add Turkish in the future.


chore: possible tmp fix for #565

Description
reference: https://github.com/jazzband/django-two-factor-auth/issues/565
This is temporally workaround until django-user-sessions Django 4.x compatible version is released.
Motivation and Context
reference: https://github.com/jazzband/django-two-factor-auth/issues/565
How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Outdated, thanks anyway for your contribution!


Why Kino.listen doesn't return a pid?

https://github.com/livebook-dev/kino/blob/78e58cfc4d8d4a7018644c55f9ba06b9100ff3ce/lib/kino.ex#L419-L428
Is there a specific reason why :ok is returned instead of the pid?
It would be nice to be able to do something like this:
job_pid = Kino.listen(5000, fn i -> IO.puts(i) end)

Kino.Control.button("Kill job")
|> Kino.render()
|> Kino.listen(fn _ -> Process.exit(job_pid, :kill) end)

Can you please send a PR?

Just for reference:
Process.exit(job_pid, :kill) kills the whole cell. Instead use Kino.terminate(job_pid)


Use additional kwargs

Recently there have been additional kwargs that are aggregated so
that can be passed through when calling boto methods. These aren't
currently being used. This uses them.

cc @mariusvniekerk

Whoops

Thanks for picking this up @scizo


Observatory debugger can render offscreen

Working on a laptop.
Thanks for taking a look!

I've got a fix which clips this at the edge.  The browser is fighting my attempts to show a scroll bar.

Two fixes:
d6060d2dddcea1d28fd6bde67afc25b089e352f0
1587f88c2da2fc722ddc36f77830f6d360410108
These fix the rendering and also makes the variables consume much less horizontal space.


Allow to set a desired update interval for camera_proxy_stream view

Description:
Set desired image update interval using 'interval' query parameter. defaults to (existing) 0.5 seconds. Harcoded mininum of 0.05 seconds. Selecting a shorter interval will increase disk I/O (comparing image file, but not more network traffic)
Maybe the minimum interval is too short, I don't really know, please discuss!
In the front-end this could be used like:
this.cameraFeedSrc = '/api/camera_proxy_stream/' + this.stateObj.entity_id +
             '?interval=10&token=' + this.stateObj.attributes.access_token;

note: if the 'interval' parameter is omitted it will use the default (0.5) seconds.
Main use case: convert the frontend camera card to use the camera proxy (with a long interval, or maybe even selectable) and only update the image if it is changed, instead of a new request (and image transfer) every 10 seconds.

Ok. I've been giving this some thought. The feature itself is useful (streaming with a custom interval)
My implementation is sort of taking the wrong approach.
I've got to extend/change the view logic, maybe add a handle_async_image_stream, but not change the handle_async_mjpeg_stream because a lot of camera platforms implement that method themselves where they literally proxy the stream from the camera.... Going to refactor now

I don't think that we should merge this. There are already some camera's that convert streams using FFMPEG which I think is the way to go. For us to create an MJPEG stream on the fly, should be considered a fallback and we should not make it too good, so that people improve the integrations 😉 I also think that it's too easy to eat up all CPU or hammer the camera device if we allow it to be set too high.

I definitely agree on your point that this is a fallback. And platforms should really provide a proper stream. And if we make it too good it will get too easy to fall back to this resource heavy way of streaming.
However currently we refresh the frontend card with a new request and new download every 10 seconds. The point of this was to convert it so it could (always) use a stream, and maybe pick a faster (or slower interval) it would however only take the necessary bandwidth as new data only comes in when there is new data.
What if we limit it to the current update interval of 0.5 seconds? That’s currently what platforms fall back to if they not implement a proper proxy stream.
I wouldn’t even mind to set it to 1 or 2 seconds. I just care for a more efficient stream to the cams card.

I was thinking for the preview in the overview to actually add a new method to camera's to be able to provide a thumbnail picture. Right now we stream a lot of data to the frontend.

Oh I see now how we would be saving data, it's because we would not have to redownload a picture if it has not changed in 10 seconds.

Yes, and we can give a little control in the frontend about the update interval. (no values, maybe just a "tortoise and a hare" switch)
This all started because rpi_camera has a configurable interval. Someone wanted to set it to 30 seconds and 'sync' that interval to the frontend to save some requests and data.
So it's definitely not intended to provide high-fps streaming.
I don't know how much overhead every https request adds vs. an open socket, but with ssl that could add up too I guess?

I would not bother about the overhead of a request vs a socket. You have convinced me that this is a useful addition 👍


Override file for Azure specific elements of docker compose

Context
To facilitate use of common docker file for both local and azure deployments.
Changes proposed in this pull request
Azure specific components of docker-compose.yml moved into a new overrides files called docker-compose.azure.yml. This file is then called in the azure pipeline, along with the normal docker-compose file.
Guidance to review
Tested a build in Azure and local docker compose build to validate that the build succeeds in both types of environment.
Link to Trello card
697 - Use Docker in local development to match production environment

:+1: This looks good to me. I'd like @kjdchapman to have a look too, as I know he had some ideas about how he'd like the local Docker workflow to work so he should be in the loop on this


Machine mac-36 is reporting dead.

Is there an existing issue for this?

[X] I have searched the existing infra issues

Type of Request
infra task
Infrastructure Environment
LUCI, Github, Cocoon scheduler, Autosubmit, etc...
What is happening?
Machine mac-36 is reporting dead.

Steps to reproduce
Step 1:
Step 2:
..
Step n:
Expected results
I expect to see X when Y is finished.

I can login remotely onto machine mac-36 from my end, will look into more details.
flutter@flutter-devicelab-mac-36 ~ % uptime
11:42  up 11:20, 3 users, load averages: 1.07 1.06 1.02

Installing git package and ran "salt-call state.apply" to clear the error.


Don't use default jschon Catalog

If oascomply is used as a library with other code that uses jschon, there might be a collision regarding the default catalog.  Since we already set it up and export it in oascomply/__init__.py, give it a name and be certain to always use it (probably export the name as well?  Although technically if you have the instance I don't think the name is needed?)

Fixed on the m2 branch, most notably commit 8ba736e0


[meta] No HTTPS for docs

We're on surge.sh, which doesn't allow HTTPS on custom domains (for free, at least), and I've turned off Cloudflare a while ago (along with its' Universal SSL hack), so we stick with plain old http for now.
This is also a problem with some of my other projects (i. e. Beerializer's docs live at http://beerializer.songbee.net/, but Read The Docs has the same problem).
Further reading

http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/
https://letsencrypt.org/

https://www.netlify.com/ is probably what we're looking for.


Error: Chromium revision is not downloaded. Provide TAIKO BROWSER PATH or Install taiko again to download bundled chromium

While trying to run test locally in my system, getting above error. It runs fine on remote server(docker)

@shaifaliyadav Looks like taiko is unable to download chromium. Check project node_modules and taiko directory to see if chromium is downloaded.

@saikrishna321 yes i's not getting downloaded, that is the problem. Tried installing/uninstalling it, but no luck

this issue still exists..Can someone please help. @zabil @saikrishna321

Sorry to see that you are stuck with this issue but It's a bit hard to help with this as there is very little info to replicate it.
When creating a new issue there are a few sections to be filled up which helps find the actual problem. Those sections seem to be missing. Can you please fill up those sections? It has info about versions, environments, os, command to replicate it etc.
Without enough info a guess could be that there is a proxy for your local environment, if that is the case please check your proxy settings

You can download it yourself in package
 node node_modules\taiko\lib\install.js

having the same issue on Manjaro 21.2.0


The metadata "homepage" link rendered twice on PyPI

With the most current tools, and following the recommendations of PEP 621 – Storing project metadata in pyproject.toml, package publishers end up with duplicate homepage links rendered on the UI:

https://test.pypi.org/project/issue11220/
This is probably actually the fault of setuptools and/or the spec, but perhaps warehouse can workaround by ignoring duplicates? What do you think? Otherwise we might start seeing it everywhere as people adopt PEP 621 recommendations..  :-\
Note: The package was produced from running python -m build on this source, a stripped down version of the example in the PEP:
[build-system]
requires = ["setuptools >= 40.6.0", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "issue11220"
version = "0.1"

[project.urls]
homepage = "https://github.com/pypa/warehouse/issues/11220"

The issue is that we're getting both of these metadata fields from the distributions:
Home-page: https://github.com/pypa/warehouse/issues/11220
Project-URL: homepage, https://github.com/pypa/warehouse/issues/11220

PEP 621 doesn't seem to explain what tools should do with the old Home-page field when homepage is present, but looks like setuptools has decided to duplicate the value into it. I'm not sure that's really necessary, as I think the long-term plan should be to deprecate this field and stop using it entirely.
It's also not clear to me how PyPI should expect to de-duplicate this. A pyproject.toml like this:
[project.urls]
homepage = "https://example.com/homepage"
Homepage = "https://example.com/Homepage"
Home-page = "https://example.com/Home-page"
Home_page = "https://example.com/Home_page"
Home__page = "https://example.com/Home__page"

Produces this metadata:
Metadata-Version: 2.1
Name: issue11220
Version: 0.1
Summary: foo
Home-page: https://example.com/Home__page
License: UNKNOWN
Project-URL: homepage, https://example.com/homepage
Project-URL: Homepage, https://example.com/Homepage
Project-URL: Home-page, https://example.com/Home-page
Project-URL: Home_page, https://example.com/Home_page
Project-URL: Home__page, https://example.com/Home__page
Platform: UNKNOWN

UNKNOWN

So it looks like it's just choosing the last one, which seems confusing.
FWIW, flit doesn't have this problem, and produces the following metadata:
Metadata-Version: 2.1
Name: issue11220
Version: 0.1
Summary: foo
Project-URL: Home-page, https://example.com/Home-page
Project-URL: Home__page, https://example.com/Home__page
Project-URL: Home_page, https://example.com/Home_page
Project-URL: Homepage, https://example.com/Homepage
Project-URL: homepage, https://example.com/homepage

Which IMO is the correct behavior here and probably what setuptools should be doing, instead of PyPI introducing workarounds for its behavior.
CC @abravalheri for your thoughts.

There is a discussion regarding this in:

https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/13?u=abravalheri
https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/16?u=abravalheri

The path I choose is the maximum backward compatibility, so I purposefully decided to backfill the Home-page field using the values in Project-URL. This is motivated by the fact that the Home-page field is not currently considered deprecated.
I agree with Dustin that in the case of multiple candidates choosing the last option might be confusing. Would it be better if instead we stick with the first?

Regarding the deduplication, if you write:
[project.urls]
Homepage = "https://github.com/pypa/warehouse/issues/11220"

PyPI will display only one URL.

@di in the case of
Project-URL: Homepage, https://example.com/Homepage
Project-URL: homepage, https://example.com/homepage

If the approach chosen by PyPI is to not do any de-duplucation, does it also make sense to not automatically change the case of the word?

I agree with Dustin that in the case of multiple candidates choosing the last option might be confusing. Would it be better if instead we stick with the first?

I think the best thing would be for setuptools to just stop duplicating the field. I'm not sure what would be depending on maintaining this backwards compatibility, but it's not PyPI and nothing else comes to mind.

If the approach chosen by PyPI is to not do any de-duplucation, does it also make sense to not automatically change the case of the word?

I'm not sure I understand your question! I don't think PyPI should do any modification to what the user has put in this field. I don't think tools should be either.

I agree that PyPI should not be doing modifications to what has been provided to us. I think that as the core metadata for Project-URL is specified we also probably shouldn't change the casing either under the same rationale, since as the metadata si currently defined Homepage and homepage are distinct entries.
I think that there's a good argument to be made that Project-URL keys should be case insensitive, and if we made that change then I think changing case could be fine, but unless that happens I think not changing makes sense.
I also think there is a good argument that the existing url fields that aren't Project-URL should just be deprecated
As far as what is valid for setuptools to do here, tools are generally free to generate the metadata using their inputs as they see fit. PEP 621 defines a standard for how to generate some of those fields, from a specific shared input (in this case, 1:1 mapping with no transformation) but anything not covered by PEP 621.. isn't covered by PEP 621.
Like if we remove PEP 621 from the equation, and someone wrote:
from setuptools import setup

setup(
    ...,
    project_urls={
        "Homepage": "...",
    },
)

Would it be valid for setuptools to backfill the Homepage metadata using that? Which I think is unequivocally yes.
Does it make sense for setuptools to do this? Eh, personally I don't think that field matters and having it duplicated probably confuses some people somewhere so I wouldn't bother if I were setuptools. I don't feel strongly about it personally though.
I think it probably does make sense to deprecate the two old URL fields and in that case PyPI could just stop showing that field and setuptools can easily justify no longer emitting it.

I think the best thing would be for setuptools to just stop duplicating the field.

I understand and sympathise with the point of view you guys are exposing here. Probably in the future we will remove the duplication, but there are a few other changes that might need to happen first, before we reach that point.
For example, distutils expects the field to be defined. It will complain loudly with a warning, which will make setuptools users very confused, and may break CI workflows configured with a more strict PYTHONWARNINGS[^1].
If Home-page gets deprecated as core metadata, then I would have some more leverage to push this kind of change.
[^1]: To workaround that I have to propose a PR to drop the warning in pypa/distutils. But the maintainers there may (rightfully) indicate that the field is not deprecated and therefore there is no obvious problem with the behaviour implemented in distutils. There is some precedence with other fields that makes me believe that would be the case.

I'm not sure I understand your question! I don't think PyPI should do any modification to what the user has put in this field. I don't think tools should be either.

What is the current approach taken by PyPI for deduplication?
What happens if the user has 2 Project-URL with (exactly) the same label?
Based on previous experiments, it seems that PyPI will deduplicate Home-page: ... and Project-URL: Homepage, ... but not Project-URL: homepage, ....
(As pointed out by Donald) PyPI currently displays Project-URL: homepage, https://example.com/homepage as
Homepage
i.e. it capitalises the first letter.
So if there is some form of deduplication going on, it would make sense to do it considering the values after PyPI processes them for display.
Otherwise, it would make sense to me to display them as they are given by the user.

Regardless, my opinion is that this is not a real issue with PyPA, and the warehouse project can decide to display Project-URL however they see fit.
In terms of the setuptools implementation, the answer would be: it's complicated.
Right now, since core metadata is not technically incorrect when duplicating Home-page and Project-url: Homepage, ..., there is a high chance this issue would be treated as a wontfix or at least linger in the issue tracker for a while before we are in a position that we can tackle it properly.

What is the current approach taken by PyPI for deduplication?
What happens if the user has 2 Project-URL with (exactly) the same label?

From what I can tell, in the database it will store the duplicated URLs since it's storing it as a row per entry, with a singular string column for "Key, Value".
When we load that data, our data model makes it available in two forms:

A list of strings in the "Key, Value" form.
A Mapping of Key -> Value, and we "prefill" the mapping with a "Homepage" key taken from Home-page and Download from Download-URL.

This means that if someone has a "Homepage" project-url or a "Download" project URL (explicitly that, case sensitive) AND the older Home-page or Download-URL data, that the project-url will overwrite and take precedence. It also means that PyPI is already treating those fields as somewhat deprecated already.
It also means if someone has duplicates for the same Project URL Key twice, the latter will overwrite and "win". The core metadata spec is silent in this case, but I think we should probably change this case to be an error on upload, and just require unique keys for every Project-URL entry.

For actually sending that data to the end user, for the HTML pages and the JSON API we use the mapping in (2). In the XMLRPC API we return the list from (1).

To workaround that I have to propose a PR to drop the warning in pypa/distutils. But the maintainers there may (rightfully) indicate that the field is not deprecated and therefore there is no obvious problem with the behaviour implemented in distutils. There is some precedence with other fields that makes me believe that would be the case.

It being deprecated or not isn't really important. It's not a required field, they're of course free to be stricter on what they require than the metadata spec requires, but the spec itself its' perfectly valid to emit metadata without that field regardless of this issue. The only required fields are Name, Version, and Metadata-Version.

Thank you very much for the explanation @dstufft, now it does make sense the behaviour I was observing with Project-url: Homepage, ....

they're of course free to be stricter on what they require than the metadata spec requires, but the spec itself its' perfectly valid to emit metadata without that field regardless of this issue.

This is more or less what is happening right now. Metadata will be emitted, but distutils will be stricter and use warnings to encourage users to fill some metadata it considers important.

I was mostly pointing it out because I'm pretty sure those warnings date back to when at least Download-URL was a mandatory value, I don't recall if Home-page was mandatory or not. It being made optional was a (relatively speaking) recent change (8? years 10? years ago).

Here is what I think setuptools should do:

Stop auto-populating a Project-URL into the Home-page.

Here is what I think distutils should do:

Nothing. Getting changes into distutils is useless, it's already on death row.

Here is what I think warehouse should do:

If there is any Project-URL with the key "homepage" or "home-page" (case insensitive), then use that link and render it as the Homepage link. Ignore whatever is in Home-page. This is just pragmatic, and makes sure PyPI does the right thing for people using the latest build tools without changing anything for people that are using old build tools.

Maybe setuptools could patch their vendored distutils to not warn on missing Home-page, if it's easy enough, but that's not really particularly important (distutils sdist builds already spam ignorable warnings about a bunch of other stuff)
Here is what I do in my build backend, if Home-page is duplicated in a Project-URL, the first one gets kicked out.

Note:
In the Web UI PyPI does not have the concept of a "Homepage" link or a "Download" link. It has a Project URL mapping that gets rendered. PyPI will inject the Home-page and Download-URL metadata into that Project URL mapping at render time (but if the Project URLs contain "Homepage" or "Download" the injected values get over written.
The JSON/XMLRPC API differentiate between project URLs and Home-page/Download-URL and should not munge data between them. Those APIs are to get access to the underlying data, and should faithfully reproduce the data as given.

Yes, I understand. So my suggestion is just to extend the "injected values get overwritten" part to also overwrite with a project url of homepage or home-page or hoMepAGE (any one of them, first, last, doesn't matter as long as it deterministic)

Hi @wimglenn.
When I was collecting feedback about PEP 621 implementation, cryptic distutils warnings were constantly mentioned by the users. Right now , we avoid messages about the url corresponding to Home-page by backfilling with the value in Project-URL, and therefore effectively promoting backward compatibility with distutils.
Please note that I am not against the changes proposed. I am just saying that the process is a bit more indirect and goes through either changing distutils first or creating the patches you propose.
It would be also helpful if there is consensus in the community and the Home-page field in the core metadata is officially deprecated.
My personal plan for the moment in terms of contributions to setuptools is to focus in other changes that I judge more urgent/important (unfortunately we all have to prioritize with the volunteering time we have available).
So I invite anyone that is interested in pushing this issue forward in the setuptools/distutils side to propose the changes via code contributions.

where does this backfill happen in setuptools? I was spelunking through the code but could not find it..

This is it: https://github.com/pypa/setuptools/blob/372652d6dadf8de6c29c83d0f2107fdd7b6e6571/setuptools/config/_apply_pyprojecttoml.py#L173

@abravalheri  Thanks - was not aware of pypa/distutils, and just assumed that setuptools was vendoring the stdlib code. Good to know! I'll prepare PR when I find the time, totally agree that it's not an urgent/important issue.

https://github.com/pypa/distutils/pull/138
https://github.com/pypa/setuptools/pull/3289
https://github.com/pypa/warehouse/pull/11273

the first two PR should fix the root cause
the third one alleviates the symptoms for pkgs made from existing releases of setuptools


active quests are now active again after serialize/deserialize

I have noticed that an active quest is no longer active after deserializing. The active state was not taken into account during serialization and was therefore saved incompletely.

Oh wow, I obviously didn't test it enough 😅


A lot of things violate the normal course of human operation

add pins, update pins, delete pins need user to select a pin from list. and other thing like this. I will redesign some of them and try to make them more comfortable

rebuild the front end pin system, make it more easy to use. but there will be some other things to do.


Fixed typo on overview-of-data-center-bridging.md

Thanks for the typo fix, @alfredmyers! I'll go ahead and merge this for you. The changes should be live later today.


[6.0] Support macros when cross-compiling

Explanation: Macros cross-compiled by SwiftPM with Swift SDKs should be correctly built, loaded, and evaluated for the host triple.
Scope: isolated to modules dependency resolution and llbuild, does not impact code related to XCBuild.
Risk: medium, known issues were addressed on main and are cherry-picked here, with no new issues reported for a few weeks now.
Testing: added unit tests, manual end-to-end testing done with existing Swift SDKs.
Issue: rdar://105991372
Reviewers: @bnbarham @xedin @neonichu
(cherry picked from commit cb3b0856f3616e9a505c94d2c7958b83ab32f9f6, https://github.com/apple/swift-package-manager/pull/7353)
# Conflicts:
#	CHANGELOG.md
#	Sources/Build/BuildDescription/SwiftTargetBuildDescription.swift
#	Sources/Build/BuildManifest/LLBuildManifestBuilder.swift
#	Sources/Build/BuildPlan/BuildPlan.swift
#	Sources/Commands/SwiftTestCommand.swift
#	Sources/Commands/Utilities/PluginDelegate.swift
#	Sources/Commands/Utilities/TestingSupport.swift
#	Sources/PackageGraph/ModulesGraph+Loading.swift
#	Sources/PackageGraph/ModulesGraph.swift
#	Sources/SPMTestSupport/MockBuildTestHelper.swift
#	Sources/SPMTestSupport/MockPackageGraphs.swift
#	Sources/SPMTestSupport/PackageGraphTester.swift
#	Sources/SPMTestSupport/ResolvedTarget+Mock.swift
#	Tests/BuildTests/ClangTargetBuildDescriptionTests.swift
#	Tests/BuildTests/CrossCompilationBuildPlanTests.swift
#	Tests/SourceKitLSPAPITests/SourceKitLSPAPITests.swift

(cherry picked from commit b9eb3c138ec681d8858de4d8bf7d179758490ba1, https://github.com/apple/swift-package-manager/pull/7493)
# Conflicts:
#	Sources/PackageGraph/ModulesGraph+Loading.swift
#	Sources/PackageGraph/Resolution/ResolvedPackage.swift

(cherry picked from commit 5a4c0240c771db9dab8b5b264a9d368dfe11f0fc, https://github.com/apple/swift-package-manager/pull/7508)
# Conflicts:
#	Sources/Commands/SwiftBuildCommand.swift
#	Sources/Commands/SwiftTestCommand.swift
#	Sources/Commands/Utilities/TestingSupport.swift

(cherry picked from commit 8db240186de97b01c2d2fb351b367bbdd43fe6b6, https://github.com/apple/swift-package-manager/pull/7519)
# Conflicts:
#	Tests/BuildTests/CrossCompilationBuildPlanTests.swift

@swift-ci test

@swift-ci test

@swift-ci test

@swift-ci test

@swift-ci please test

@swift-ci test windows

I think you might also want this change: https://github.com/apple/swift-package-manager/pull/7629

I cherry-picked:

https://github.com/apple/swift-package-manager/pull/7471
https://github.com/apple/swift-package-manager/pull/7593
https://github.com/apple/swift-package-manager/pull/7619
https://github.com/apple/swift-package-manager/pull/7646 (this supersedes https://github.com/apple/swift-package-manager/pull/7629)

And opened an aligned sourcekit-lsp PR - https://github.com/apple/sourcekit-lsp/pull/1454

https://github.com/apple/sourcekit-lsp/pull/1454
@swift-ci please test

https://github.com/apple/sourcekit-lsp/pull/1454
@swift-ci please test Windows platform

https://github.com/apple/sourcekit-lsp/pull/1454
@swift-ci please test

https://github.com/apple/sourcekit-lsp/pull/1454
@swift-ci please test Windows platform

https://github.com/apple/sourcekit-lsp/pull/1454
@swift-ci please test macOS platform

https://github.com/apple/sourcekit-lsp/pull/1454
@swift-ci please test Linux platform


multiVAE and organize_multiome_anndatas: module 'scarches.models' has no attribute

Hi I have been trying to follow to tutorial of Integration and reference mapping with multigrate https://docs.scarches.org/en/latest/multigrate.html. However, I was having trouble loading the multiVAE and organize_multiome_anndatas from models. I am wondering if these two models are still available. Or is it cuased by the installing process?
import scarches.models.organize_multiome_anndatas
ModuleNotFoundError                       Traceback (most recent call last)
Cell In[3], line 1
----> 1 import scarches.models.organize_multiome_anndatas
ModuleNotFoundError: No module named 'scarches.models.organize_multiome_anndatas'
import scarches.models.MultiVAE
ModuleNotFoundError                       Traceback (most recent call last)
Cell In[3], line 1
----> 1 import scarches.models.MultiVAE
ModuleNotFoundError: No module named 'scarches.models.MultiVAE'
adata = sca.models.organize_multiome_anndatas(
adatas = [[rna_cite, rna_multiome], [None, atac], [adt, None]],    # a list of anndata objects per modality, RNA-seq always goes first
layers = [['counts', 'counts'], [None, 'log-norm'], ['clr', None]], # if need to use data from .layers, if None use .X
)
adata
AttributeError                            Traceback (most recent call last)
Cell In[14], line 1
----> 1 adata = sca.models.organize_multiome_anndatas(
2     adatas = [[rna_cite, rna_multiome], [None, atac], [adt, None]],    # a list of anndata objects per modality, RNA-seq always goes first
3     layers = [['counts', 'counts'], [None, 'log-norm'], ['clr', None]], # if need to use data from .layers, if None use .X
4 )
5 adata
AttributeError: module 'scarches.models' has no attribute 'organize_multiome_anndatas'
Version is as follows:
scarches                  0.5.9                    pypi_0    pypi
multigrate                0.0.2                    pypi_0    pypi
python                    3.10.9          he7542f4_0_cpython    conda-forge

Hi @Yansr3,
Thanks for reporting this! Could you try installing both scarches and multigrate from git?

Hi @alitinet,
Thank you for replying. The error is fixed by installing from github. Thank you!

Hi I encountered the same problem while trying multiVAE as you written. And I installed both scarches and multigrate from github but the error occurred again. Could you please teach me how you fix this problem? Thank you!

@alitinet @Koncopd


How can i see what i  sync to github in github website

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:
OS Version:

Steps to Reproduce:

if i turn on setting sync with github
2.How can i see what i  sync to github in github website

Per https://code.visualstudio.com/docs/editor/settings-sync#_can-i-use-a-different-backend-or-service-for-settings-sync the synced settings aren't actually stored on GitHub.

@gjsjohnmurray where can i see the synced settings data in website

@WingDust they are stored in a settings sync server from Microsoft. Please look at this doc to know how to view your data - https://code.visualstudio.com/docs/editor/settings-sync#_restoring-data


#232 Fix favicon rendering logic and add Links

@SuelaCark @Aleks1908 up for verification

@SuelaCark please verify again. I couldn't come up with a clean solution on how to load at top level and I don't have the time to do so. The implemented scrolling looks nice to me, if it's alright with you, feel free to approve and merge


FR: media retention based on access time.

Purge local and remote media that hasn’t been accessed in a certain amount of time, in order to control the size of media repo. (Preferably automatically)
Synapse manual: https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html?highlight=Media_re#media_retention

Another approach is to use systemd-tmpfiles with conduwuit's startup check disabled:
d	/var/lib/private/serverOS-conduwuit/media	-	-	-	10d

This works mostly fine for me, just need some more time to prove the stability. Maybe it can be added to the conduwuit docs.

This does not differentiate between local and remote media. This will cause local media to be deleted too.
We plan on separating out the local and remote media into at least two separate directories eventually.

Yes, and that's my intention. Users on my server upload media pretty often and the majority of them us useless and never accessed again.

Absolutely, and some people will want to purge local media the same way as remote media, but some people will also not want to do that.
Splitting the two and having them configurable separately makes a lot of sense here - it'd let both sets of people do whatever they want! 😊


String enum default value results in wrong value on INSERT

Steps to reproduce:

Create an Entity that has a Enum field
Add 2 or more values to the Enum
Describe enums as strings using OnModelCreating on DbContext
Set a default value different than index 0 of the Enum inside using OnModelCreating on DbContext
Try to insert an Entity that has the Enum field set as index 0 of the Enum
Observe that the inserted value is the default one, instead of the desired index 0 of Enum.

Example:
Visitor.cs
public class Visitor
{
    public int Id { get; set; }
    public VisitorState State { get; set; }
}

public enum VisitorState
{
    InQueue,
    Ordering,
    Eating
}

ApplicationDbContext.cs, inside OnModelCreating
builder.Entity<Visitor>()
    .Property(e => e.State)
    .HasConversion(v => v.ToString(),
        v => (VisitorState)Enum.Parse(typeof(VisitorState), v))
        .HasDefaultValue(VisitorState.Ordering);

Seeding some data anywhere
this._dbContext.AddRange(new List<Visitor>
{
    new Visitor
    {
        State = VisitorState.InQueue
    },
    new Visitor
    {
        State = VisitorState.Ordering
    },
    new Visitor
    {
        State = VisitorState.Eating
    }
});

Database Result

Id
State

1
Ordering

2
Ordering

3
Eating

Expected Result

Id
State

1
InQueue

2
Ordering

3
Eating

Solution that reproduces the issue
EnumIssue.zip
Thanks in advance.

@vdurante What is your expectation of what HasDefaultValue should do in this case?

@ajcvickers If I attempt to insert a NULL State, it should insert the default value, which is Ordering in this case. In my example I attempt to insert a value of InQueue, but in the database it inserts the wrong value of Ordering.

@vdurante Typically you need a nullable property for that, otherwise there is no null State.

@ajcvickers either way, what explains the fact I am inserting the value InQueue but it gets inserted as Ordering in the database? I am not trying to insert NULL. I am explicitly inserting a value and the wrong value is being inserted.

@vdurante Because if you want EF to sometimes insert a real value, and sometimes use the database default, then EF has to be able to determine when to do one verses the other. It does this based on whether the value in the given entity is the CLR default or not. However, if the CLR default is an actual value that can be inserted, then it can't act as the sentinel. In this case, the property should be made nullable so that null becomes the CLR default and the database default will therefore not be used unless the value is null.

@ajcvickers I guess I understood what is happening.
So, EF considers the CLR default is 0 since the attribute cannot be NULL? From my understanding of your comment, since it is a non-nullable enum, EF considers the default 0, so it maps position 0 of the enum (InQueue) to the default.

@ajcvickers thank you!


CLI output JSON formatted

For internal CI purposes we're currently running a variation of the CLI tool which outputs in JSON format so that the script running it can do further processing using jq etc.
Opening this issue to allow a PR to be opened to make the change available upstream.

Hey @roxspring. I'm really happy that your team is using CLI, however I don't fully agree with this approach. If you are interested in JSON output, why not to trigger API directly and post-process it with jq?

Maybe you can provide some example and we will see how to make CLI more useful

I agree with @netme.
@roxspring, please describe your use case

We're using GitLab CI and have a job configured with each API project to check it's swagger.yaml file against Zally. Until recently that would just use the classic cli to fail the build on MUST violations, but consequently SHOULD and lesser violations were going unnoticed. So we decided that the job should be updated so that it additionally uses the GitLab API to add markdown formatted comments to the commit in question. The job consists of a small bash script running within a docker image.
We were already using the freshly built CLI, which itself already knew how to make the requests. I knew that the API required the yaml to be wrapped in an ApiDefinitionRequest and wasn't sure how to easily/reliably do that from a curl command line. So hacking the Zally CLI seemed the simplest way forward.
On reflection, I can understand that it would be ideal for such integrations to use the API directly but I was "put off" by the complexity of forming a suitable request. Perhaps this suggests we should have a 2nd simpler end point that allows direct POSTing of the json/yaml in question to ensure that barrier is kept low.
On the other hand, I'm a little surprised at making the CLI easier to process by a script - automation seems to be the primary use case of such command line tools these days.
We're using GitLab CI and have a job configured with each API project to check it's swagger.yaml file against Zally. Until recently that would just use the classic cli to fail the build on MUST violations, but consequently SHOULD and lesser violations were going unnoticed. So we decided that the job should be updated so that it additionally uses the GitLab API to add markdown formatted comments to the commit in question. The job consists of a small bash script running within a docker image.
We were already using the freshly built CLI, which itself already knew how to make the requests. I knew that the API required the yaml to be wrapped in an ApiDefinitionRequest and wasn't sure how to easily/reliably do that from a curl command line. So hacking the Zally CLI seemed the simplest way forward.
On reflection, I can understand that it would be ideal for such integrations to use the API directly but I was "put off" by the complexity of forming a suitable request. Perhaps this suggests we should have a 2nd simpler end point that allows direct POSTing of the json/yaml in question to ensure that barrier is kept low.
On the other hand, I'm a little surprised at making the CLI easier to process by a script - automation seems to be the primary use case of such command line tools these days.

@roxspring thanks for clarifications. I see here 2 problems you are trying to solve:

Return different status code when SHOULD violations are happening
Show the comments in GitLab with the violations which have happened

What we can do about it:

Add the extra level parameter which will fail optionally on SHOULD, MAY violations
Add a flag to show less details in the output

Will it be somehow a solution? Ideally for that needs we need a proper GitHub / GitLab integration layer.

For our case we don't necessarily want to change the status code - we only block the build on MUST failures - but we do want to raise the visibility of the violations into GitLab comments rather than just the console logs from various jobs. And actually we're happy with the level of detail from the violations - we just need to transform them into Markdown. Pseudo code for what we're doing goes like this:
processSwaggerWithZally()

if hasAnyViolations() then
  commentOnCommit(violationsRenderedAsMarkdown())
else
  commentOnCommit(thumbsUpEmoji())
end if

if hasMustViolations() then
  stopTheBuildPipeline()
end if

A proper Git* integration layer sounds good but I'm not sure how different that would look as GitLab CI seems to have no plugin mechanism beyond running docker based jobs in a pipeline. Ideas welcome though 😃

@roxspring could you please also provide an example of generated Markdown?

/me suddenly wondering whether a --markdown option would have been more popular
Markdown currently looks as follows:
* [SHOULD Operation Summary and OperationId Match](http://example.com/#MatchingSummaryAndOperationIdNames)
** OperationId should be the lowerCamelCase version of the summary
** /status GET has operationId 'getStatus' but expected 'getStatusxxx' to match 'Get statusxxx'

Actually, looks like there's nothing proprietary in the actual bash script we're using right now so here it is in it's entirety including the jq incantation we're using to generate the markdown:
#!/usr/bin/env bash

PATH=$1
JSONTOMARKDOWN=".violations[] | \"* **[\(.violation_type) \(.title)](\(.rule_link))**\", \"  * \(.description)\", (.paths[] | \"  * \(.)\")"

echo "Linting $PATH..."
/usr/bin/zally lint --json $PATH > /tmp/zally.json
RESULT=$?

echo "Formatting markdown comment..."
if /usr/bin/jq --exit-status ".violations | length > 0" /tmp/zally.json; then
    /usr/bin/jq \
        --raw-output \
        "$JSONTOMARKDOWN" \
        /tmp/zally.json > /tmp/zally.md
    /bin/sed -e s/^/\ \ /g /tmp/zally.md

    echo "Commenting violations on gitlab commit..."

    /usr/bin/curl \
        --silent \
        --request POST \
        --header "PRIVATE-TOKEN: ${ZALLY_GITLAB_TOKEN}" \
        --data "note=%F0%9F%91%8D" \
        --data "path=$PATH" \
        --data "line=1" \
        --data "line_type=new" \
        ${CI_PROJECT_URL}/../../api/v4/projects/${CI_PROJECT_ID}/repository/commits/${CI_BUILD_REF}/comments
fi

exit $RESULT

Yeah, that's why I was asking :-)
We can think about keeping --format=markdown option, that can be a deal breaker, because we will be able to generate e.g. HTML reports.
What we still need is to:

agree how the format should look exactly
maybe think about short / long versions of the format
sync text and markdown formats, so they provide consistent output

@maxim-tschumak @roxspring any ideas on that? 💡
Don't get me wrong, I wanted to avoid showing raw output from API, because in the end API can serve it perfectly .

Sounds good to me. The only thing I'd add:

agree a positive (non-blank) output when no violations are found

Do you have ideas / improvements on the Markdown formatting to suggest?

Created a ticket #652 for --format option

And another optional ticket #653


Cleaner handling of timezones

(Split from #25)
This is mainly a problem because Elm core does not properly support timezones or even give a way to determine the timezone of a Date value.
Specifically, in our app, we need to let the user choose moments in time, but we want the datepicker to show them dates in their user-selected timezone, which sometimes is different from the timezone of the local computer they are using.
Our investigation has led to the following thoughts about how to make datetimepicker more robust w/r to timezone handling:

datetimepicker should provide its own data types that directly matches what the pickers can choose
(instead of giving back a Maybe Date)

datepicker should give a record with year, month, day
timepicker should give a record with hour, minute
datetimepicker should give a record with year, month, day, hour, minute

datetimepicker can provide convenience functions to turn the above data types into Date values (documented to note that they will convert using the local timezone of the user's web browser)

I really like the idea of datetimepicker returning its own data types. I know there's some efforts in elm-core to improve the Date API, if you know any insight of that, maybe we can try to match the API there so when the new Date API is released, we can easily swap the data types with the new core Date type.
But if it's still too early for that, I'm fine with designing our own data types.

I think nothing will be changing in core w/r to dates in Elm 0.19.  I believe Evan thinks that it will be best to have core be a simple as possible w/r to dates and have a separate elm-lang/time package that is smart enough to include timezone info, etc.  I think it's far enough out that it's worth making types here for now.
Probably will have a PR for this next week.


Can't create resource when using 'Create Namespace' if there is an error first time

Fo to a resource, like secrets and click create and choose 'custom'.
Choose 'Create a new Namespace' in the namespace dropdown and enter a new namespace name.
Enter a name for the resource and for the type choose the service-acount-token option.
Click 'Create'.
You'll get an error - because for the secret type we chose, there are required key/values that we did not provide.
Change the secret type to 'Opaque'.
Click Create.
Form errors:  Could not create the new namespace. namespaces "dsfsdf" already exists
Looks like we create the new namespace, but then if we get an error from the backend because of bad data, you can't correct this and try again, because we try to create the namespace a second time and we already created it.

QA Template
Root cause
The UI did not check to see if a namespace already existed before creating it. So upon the second attempt to create the same namespace, it threw an error.
What was fixed, or what changes have occurred
This PR https://github.com/rancher/dashboard/pull/6853 changes the logic for namespace creation in the resource creation form so that if the namespace already exists, it does not attempt to create the namespace.
Areas or cases that should be tested
To test this PR, I did the same steps as in the above issue description:

Created a namespace test1.
In the secret creation form, created a Custom secret and selected the service account token as the secret type.
In the namespace dropdown, I selected Create a new namespace and entered test1.
Attempted to create the secret multiple times.
Confirmed that the error message was about the secret lacking required fields, not that the namespace already exists. The error was as expected: Secret "test6" is invalid: metadata.annotations[kubernetes.io/service-account.name]: Required value

I also tested the positive test case in which the secret is created successfully on the second attempt:

In the secret creation form, created a Custom secret and selected the service account token as the secret type.
In the namespace dropdown, I selected Create a new namespace and entered test1. (Although at this point, that namespace already exists)
Entered a name for the secret
Created a valid token for a valid service account (Note: If the secret is invalid, the backend won't throw errors. In order to see it show up successfully, the secret must use a valid service account token.) There was already a service account named default in the test namespace that I used, so I created the token by running kubectl create token -n test1 default to create a token for the service account called default. (Another note: Kubectl 1.24 is required to create the token)
In the secret form, in the data tab, added a key-value pair token: and pasted the new token.
In the secrets form, in the labels and annotations tab, added the key-value pair kubernetes.io/service-account.name: default to link the token to the service account named default.
Confirmed that the token was successfully created in the test1 namespace

I also tried the positive test case where a new namespace is successfully created at the same time as the service account token secret is successfully created.
What areas could experience regressions?
This change affects all resource creation forms where you can select a namespace or create a new namespace for the resource (dozens of forms). However I would expect the behavior to be the same for all of them - if there is a backend error preventing the resource from being created, you should be able to retry it without seeing the error about how the namespace already exists.
Are the repro steps accurate/minimal?
Yes

Upgrade verified from v2.6.8 >> v2.6-head 48b6bc6

Installed rancher server on v2.6.8
Created an rke2 and an rke1 clusters node drivers 1 worker, 1 etcd, 1 cp roles.
In the secret creation form, created a Custom secret and selected the service account token as the secret type.
In the namespace dropdown, selected create a new namespace and entered anu-ns1.
Attempted to create the secret multiple times.
It returned the error:

Could not create the new namespace. namespaces "anu-ns1" already exists

Upgraded rancher server to v2.6-head
Repeated the same steps as above and noticed the error for Could not create the new namespace. namespaces "anu-ns1" already exists is not seen anymore
Created a workload by selecting the create namespace in the dropdown option.
Provided an invalid workload name as WK-1 --> failed but the namespace was already created.
Retried by changing the container name to an invalid name --> failed --> changed the container name and workload names to a valid name --> verified no namespace error seen.

Fresh checks:

Install rancher on v2.6-head
Created an rke2 and an rke1 clusters node drivers 1 worker, 1 etcd, 1 cp roles.
Created a workload by selecting the create namespace in the dropdown option.
Provided an invalid workload name as WK-1 --> failed but the namespace was already created.
Retried by changing the container name to an invalid name --> failed --> changed the container name and workload names to a valid name --> verified no namespace error seen.
Verified by creating a config map, selecting the create namespace option and verified the namespace was created and the config map was created.


Can we get a new release?

I love this layerswitcher, and am using it via npm install, but it has a few bugs since I am using the latest release(which is quite old). I pulled the latest code, and it works perfectly for me but I would like to use the official releases. Thanks in advance!

Yes, it's been a while :smile_cat:. I'm planning on a release once https://github.com/walkermatt/ol-layerswitcher/pull/132 is merged which should be soon.

I've just published v3.3.0.

Thank you! It works perfectly now.


Crash with API when mod was ported from 1.19.2 to 1.20.1

It's me again, so I had been using your API to successfully code a mod, I actually finished it to a point I released it out into the world and am very happy with that(Thank you again for creating the API). However, I tried porting it to 1.20.1 and got an error that I did fix when I tried originally doing this in 1.19.2, from . To fix that I had to properly add the mixin gradle, which worked all well. However after porting it and fixing all these issues, a similar error seems to be occurring, and the stuff with the mixingradle is still there and working as my own Mixins successfully load. The main error seems to be this:
"Caused by: org.spongepowered.asm.mixin.transformer.throwables.InvalidMixinException: @Shadow field f_172546_ was not located in the target class net.minecraft.client.renderer.BlockEntityWithoutLevelRenderer. Using refmap cpm.mixins.refmap.json"
CPM.Mixin.1.20.1from1.19.2 Error Log.txt
I would only ever ask here if I exhausted every other option and resource to fix this on my own, so I would greatly appreciate your help.

I'm stupid, fixed it


OpenTelemetry support

Here are the pull requests to backport:

[ ] https://github.com/elastic/elasticsearch-py/pull/2457
[ ] https://github.com/elastic/elasticsearch-py/pull/2466
[ ] https://github.com/elastic/elasticsearch-py/pull/2470
[ ] https://github.com/elastic/elasticsearch-py/pull/2479
[ ] https://github.com/elastic/elasticsearch-py/pull/2482
[ ] https://github.com/elastic/elasticsearch-py/pull/2490
[ ] https://github.com/elastic/elasticsearch-py/pull/2491

Closing, #52 already existed.


How do I feed batches to SamAutomaticMaskGenerator

I am not sure if this is available, but if it is, I'd love to know how to feed images in batches for SamAutomaticMaskGenerator

following

following

following

hi, you can feed a batch like this to the SAM image encoder with onnx runtime:
encoder_inputs = {"x": [batch[0,...].cpu().numpy(),
batch[1,...].cpu().numpy(),
batch[2,...].cpu().numpy()]
}
output = self.sam_encoder_session.run(None, encoder_inputs)
image_embedding = output[0]
    decoder_inputs = {
"image_embeddings": image_embedding,
"point_coords": onnx_coord,
"point_labels": onnx_label,
"mask_input": onnx_mask_input,
"has_mask_input": onnx_has_mask_input,
"orig_im_size": np.array(image.shape[:2], dtype=np.float32)

}
I am using the onnx model for the encoder part taken from here
I just copy-pasted this code snippet from one of my project but you can adjust it to your needs. it's a bit messy but I was just playing around haven't had the time to optimize it

following

https://github.com/ByungKwanLee/Full-Segment-Anything addresses the ciritical issues of SAM, which supports batch-input on the full-grid prompt (automatic mask generation) with post-processing: removing duplicated or small regions and holes, under flexible input image size


Icon request: Register.ly

URL for the brand / site / app
https://register.ly/
Logo resources for the icon
https://register.ly/about/brand/
Proof of the Aegis-compatible 2FA
https://register.ly/two-factor-authentication-register-ly
Anything else?
Register.ly is a web host for .ly domains.
Confirmation

[X] I have read and followed the issue guidelines & issue form.

Can't access the PDF vectors, they block the access. I contact them about it yesterday.
If they don't answer / do nothing, then I have to unfortunately reject this, because the raster images of the logo are too small.

What specifically should I request from them - PDF vectors of their logo?

Yes, also SVG and EPS OK too. Basically any vector format.
Or ask them to stop firewall blocking the "download" / "PDF" links in the https://register.ly/about/brand/ page 😅

I got no response for my messages and nothing was changed for the download links, but I tried image tracing anyways and it got good results despite the low resolution. So, here's the icon.
https://github.com/aegis-icons/aegis-icons/blob/master/icons/1_Primary/Register.ly.svg

:question: How to add icon(s) to Aegis?
:star: Support this project by giving a star! Just adding like to this comment is also appreciated.


How to deal with a YAMLException?

I've found an edge case with NPFrontMatter::ensureFrontmatter() helper. It fails raising a YAMLException on the following:
---
title: Health🌀
meta: @review(1m) @reviewed(2022-03-14)
---

This is technically correct, as I discover via https://yamllint.com/ that there's a prohibition on @ character starting a value. This won't get in the way of Project+Reviews plugin which uses @review(2m) and which some will include (with or without a key) in frontmatter.  I found the issue when trying to add a trigger to a note which already had this frontmatter, via a command that does use the helpers.
We could say "well, the standard's the standard so let this continue to be a rare error". But it took me a while to work out what was going on, and I have access to the code. If someone else hits it we're going to go through this debugging again.  So I think I'd prefer to find a workaround that allows this slight anomalous use. After all, we're not trying to use full-on YAML here, but just simple key:value pairs.
The workaround I have in mind is to change the temporarily treat any leading @ in a value as \@, which is allowed.  But this means changing @templating/support/modules/FrontmatterModule/getAttributes and probably more, which I mustn't do unilaterally.
Thoughts @mikeerickson  @dwertheimer ?

@jgclark as an aside, as discussed previously, it would be great if Projects/Reviews could read straight frontmatter (in addition to working as per this post):
---
review: 1m
reviewed: 2022-03-14
---

I wrote this function which I use every time I write the frontmatter.

Excellent.

[EDIT] BTW, perhaps at some pointgetAttributes should be moved to the @helpers file at the same time, but for now, the easiest thing to do would be to sanitize at the top of getAttributes() function in np.Templating

@mikeerickson are you OK with these 2 suggestions?
And in Discord DM David and I agreed (I think) that we should treat ... #something in a YAML value as a hashtag that gets protected, but treat ... # something (with space) as the start of a comment that gets ignored (as per the YAML standard).
@mikeerickson are you OK with this as well?

@mikeerickson looking forward to hearing your thoughts.
@jgclark I just pushed up the changes. A lot more code than I bargained for, but I think I have captured most of the edges and am protecting users from accidentally messing up frontmatter YAML
Every one of @mikeerickson's tests are passing, as well as my old and new tests in NPFrontMatter and the rest of the repo.  Deals with all these edges:

I have moved getAttributes and getBody to NPFrontMatter and have refactored the calls to those in the whole repo. I have rebuilt Templating and all appears fine.
@jgclark Pls rebuild and test:

[ ] DailyJournal
[ ] Meeting Notes

Let me know what you find.

I first looked at NoteHelpers, as that's the one that contains "/add trigger".
It's now working for the edge cases here, thanks.
However, I wasn't expecting the side effect of permanently adding the surrounding quotes. I was suggesting temporarily treating the offending characters as quoted, so that the processing can work, but not changing the text in the note.

@jgclark Thanks for testing. Ah. Well this is in fact the old code doing this, not the new code. It's always been sanitizing on write. You're just seeing it now because now I'm now allowing it to read before it does the write (it was previously crashing on the read before the write). So I can turn off the sanitizing on write, which will allow people to write whatever they want in frontmatter, including things which may break the fm() parser. We will be somewhat shielded because we will sanitize non-standard YAML on read (as long as we use the getAttributes() function. What I don't know though is how @EduardMe is parsing frontmatter on his end and whether non-standard YAML will keep his triggers and title reading from working properly. I can turn it off and we can test what happens.

@jgclark Thanks for testing. Ah. Well this is in fact the old code doing this, not the new code. It's always been sanitizing on write. You're just seeing it now because now I'm now allowing it to read before it does the write (it was previously crashing on the read before the write).

Aha.

So I can turn off the sanitizing on write, which will allow people to write whatever they want in frontmatter, including things which may break the fm() parser. We will be somewhat shielded because we will sanitize non-standard YAML on read (as long as we use the getAttributes() function.

Good: that's what I think I'm after. I will need to start using getAttributes() in Reviews plugin, particularly when we extend it to use YAML fields.

What I don't know though is how @EduardMe is parsing frontmatter on his end and whether non-standard YAML will keep his triggers and title reading from working properly. I can turn it off and we can test what happens.

I suspect he's not trying to use YAML yet, but just treating the H1 line as a special case.
So, if I understand correctly:

[ ] DW tweak helpers
[ ] JGC update NoteHelpers
[ ] JGC update DailyJournal

I've looked in the past at the Meeting Note code, and failed to fully understand what's going on, so I don't want to change that.

I've released a rebuild of NoteHelpers, but having checked there should be no way we hit this edge case from DailyJournal. So I'm leaving that alone until it next needs releasing for other reasons.


Don't serve dotfiles anymore

Don't serve the files starting by a dot, fixing the H1 report #120026.
Returning a 404 status code will save ourselves from reports like "Code 403 indicates that the file exists".

@whit537: I can't close the related report (#120026), can you do it? The message could be something like:

Hi jsshen,

Sorry for the delay, this issue has been fixed today.

Thanks for making Gratipay a safer place!

@nashe We should wait until the fix is deployed first. ;-)

Uh yes, Github was not showing me the #142...

Okay! http://grtp.co/.gitignore is 404. 👍
@nashe Sounds like you're clear to respond, ya?

@whit537 : this issue is now fully revolved. Since this issue is already old, should I ask for the public disclosure today?

@nashe You can "Request public disclosure" as soon as you resolve an H1 ticket. That'll enter a 30-day process. The researcher can agree to disclosure sooner, otherwise we let the 30 days run out. Make sense?

That'll enter a 30-day process.

(after which it'll automatically be disclosed)

Ok, I've misunderstood the Gratipay statement about this. This ticket can finally be forgot :^)

Ok, I've misunderstood the Gratipay statement about this.

Which statement? Can we improve our docs somehow?

What about this?