text:
Update ics package to latest version: v2.29.0

This updates the ics package to the latest version. It seems that the ics.createEvent function now takes dates as arrays instead of moment objects. 🤔
Related to https://github.com/opencollective/opencollective-api/pull/6212

@Betree :

I don't get it, there is no update to package.json and the package-lock.json update seems unrelated. Did you forget to commit them?

Ops, I think I somehow missed to commit those. I've corrected it. Thanks much for pointing it out. 👍🏽

Also, I don't see this change listed on https://github.com/adamgibbons/ics/releases, is the change documented somewhere?

Yes I didn't see either, but if you notice their readme, it seems to use the array format for dates.

Did you try the update to make sure the ICS file was properly formatted?

Yes. Here's a sample file which I've generated.
BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
PRODID:adamgibbons/ics
METHOD:PUBLISH
X-PUBLISHED-TTL:PT1H
BEGIN:VEVENT
UID:49d51e21-82f4-488c-b020-0a18db01b0d9
SUMMARY:Test Agora Event
DTSTAMP:20210722T152300Z
DTSTART:19691202T000000Z
DTEND:20210622T131700Z
URL:http://localhost:3000/agora-collective/events/test-agora-event-73de3f3d
STATUS:CONFIRMED
ORGANIZER;CN=Agora Collective:mailto:no-reply@agora-collective.opencollecti
	ve.com
BEGIN:VALARM
ACTION:AUDIO
REPEAT:2
ATTACH;VALUE=URI:Glass
TRIGGER:-PT24H
END:VALARM
BEGIN:VALARM
ACTION:AUDIO
REPEAT:2
ATTACH;VALUE=URI:Glass
TRIGGER:-PT72H
END:VALARM
END:VEVENT
END:VCALENDAR

Yes. Here's a sample file which I've generated.

Great, if these timestamps match the event dates I'm all good with this update!

Thanks, I've created an issue on that repo as well just to double check and maybe add it to the documentation; https://github.com/adamgibbons/ics/issues/190. 😸

The month is wrong. For an event in October, it's displayed September. Can that be fixed?

The month is wrong. For an event in October, it's displayed September. Can that be fixed?

@znarf : Fixed at https://github.com/opencollective/opencollective-api/pull/6462. Let me know how it looks.

authors: SudharakaP znarf

repo: opencollective/opencollective-api


text:
Manually subscribe to Updates

User story
As an OpenCollective user, I would like to be able to subscribe to Updates (from Collectives, Hosts, Events) without having to contribute. Sometimes you may be interested in the evolution of a collective, but not ready to finance it yet.
It could also be a way to engage users not registered yet on OpenCollective, who are not ready to donate  but who may be interested in getting updates from the collective.
Best solution for this problem
Add a Follow / Unfollow button on the collective page (now included in the design https://www.figma.com/file/e71tBo0Sr8J7R5n6iMkqI42d/09.-Collectives?node-id=2439%3A40042)
Specs
Because of the way frontend will be implemented, this feature also require adding the ability to unsubscribe from collective's updates for existing backers.
API

[ ] Add a new following field in LoggedInUser with type FollowType to get subscriptions for a collective. The updates field in it will be true if user is member of the collective and the membership has isSubscribedToUpdates set to true.

{
  LoggedInUser {
     following(collectiveId: 42) {
       id
       updates
     }
  }
}

{
	"LoggedInUser": {
     "following": {
       "id": "1337-42", /*UserId-CollectiveId*/
       "updates": true
     }
  }
}

[ ] On GQLV2, add a setFollowing mutation taking a collective and a FollowInputType object that creates the member with role FOLLOWER if necessary or set the isSubscribedToUpdates field.

mutation {
  setFollowing(account: { legacyId: 42 }, updates: true) {
    ...
  }
}

{
   "id": "1337-42", /*UserId-CollectiveId*/
   ...
}

[ ] Don't send private updates to followers
[ ] Don't show private updates to followers
[ ] Make sure that host admins can't see private infos for followers (check generateCanSeeUserPrivateInfoLoader)

Some additional paths to update:

https://github.com/opencollective/opencollective-api/pull/5888/files/39745c55641613f6124cb41adb0d331871edfc84..1f85921aafa97e256779d71ee4d8d241f32f81cb#diff-90ee3a074ce4d95ccb38d581b33cb78d00855e488561cc76ea4b0582f31f71b4R534

Tests

[ ] Following a collective

[ ] Creates a member with role Follower
[ ] Doesn't create a new member if there's already one
[ ] Get email when new update is published

[ ] Unfollowing a collective

[ ] Set isSubscribedToUpdates to false
[ ] Doesn't receive emails for new updates, event if user is a BACKER

Frontend

[ ] Fetch the membership status in collective page
[ ] Add a "Follow" button that calls setFollowing to manage the subscription
[ ] Don't show private updates to followers

Tests

[ ] Cypress

[ ] Follow / unfollow updates the button

Metrics
How much many subscribe without donating.

Yes, yes, yes.
There is a hack which is creating a free tier, but this is something we should design for /cc @cuiki
Maybe add a "subscribe" or "follow" or "join" button as the primary call to action?

Please make sure you implement this as an opt-in or opt-out for collectives. I am working with collectives to have subscriptions that have as a perk  previews of releases via the updates feature.

We got a user request for this feature today. I think it's a good one.

That's a good question @Betree - on Patreon, private updates are only for paying backers. Have we gotten any clue from users if this kind of 'perk' is the reason they want private updates? I would guess yes, because if anyone can sign up for updates and get the private ones, there's no point in them being private.

@alannallama Yes, it is the reason why they want private updates. We actually got this feature request from the Dokku collective and we're co-financing the bounty for it so it's something important to them.
From what we discussed yesterday with Pia, (2) seems like the easiest and more logical solution so it's the preferred one right now.
It could also be helpful to have a tooltip above the follow button with a message like:

You will receive all the public updates from {collective}. Become a backer to also receive the private updates!

Yep, sounds good. If you're not sure of the design or wording, have a look
at how Patreon explains backer-only posts.
--
Alanna Irving
hello@alanna.space
https://alanna.space
On Thu, 25 Apr 2019 at 19:36, Benjamin Piouffle notifications@github.com
wrote:

@alannallama https://github.com/alannallama Yes, it is the reason why
they want private updates. We actually got this feature request from the
Dokku collective and we're co-financing the bounty for it so it's something
important to them.
From what we discussed yesterday with Pia, (2) seems like the easiest and
more logical solution so it's the preferred one right now.
It could also be helpful to have a tooltip above the follow button with a
message like:
You will receive all the public updates from {collective}. Become a backer
to also receive the private updates!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opencollective/opencollective/issues/1445#issuecomment-486554366,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABJ6P7RG2ZH5A6WEWEINMT3PSFNO7ANCNFSM4GEWOPEQ
.

Still want to offer this to our users!

This looks like a highly requested feature. Also in https://github.com/opencollective/community/issues/2
Maybe worth considering for a bounty @znarf ?

The Dokku collective would be willing to sponsor/co-sponsor a bounty for this issue. Feel free to reach out to me via email/slack (I'll re-add the OC slack tomorrow).

Thank you @josegonzalez - Do you know any developers who have the skills/capacity to work on this? Open Collective could co-sponsor the bounty funding, but the real bottleneck for us is dev capacity.

Not sure I know anyone personally but can dig through contacts :)
Is there a tag that we can add to this to show that it has a bounty or something? Might be a good way to raise awareness.

Can I work on this?

@bolariin sorry for the late reply, feel free to work on it! This issue is quite complex, so feel free to ask for help here on on Slack if ever needed.

Hi @bolariin, any news on this one, can we do anything to help?

@Betree Sorry no news on this. I had started but the last couple of months have been busy and I let this slip.

@bolariin No problem :slightly_smiling_face: I'll de-assign you in case someone wants to tackle it, but feel free to re-assign yourself if you want to go back to it later

I still think this is a great idea but I'm not sure how to prioritise it. Maybe worth doing some scoping?

I still think this is a great idea but I'm not sure how to prioritise it. Maybe worth doing some scoping?

@Betree Can I work on this one?

@Betree Can I work on this one?

@snitin315 Thanks for proposing, we'll need to discuss it internally first to make sure we have the bandwidth to review and maintain. I'll let you know.

@snitin315 Thanks for proposing, we'll need to discuss it internally first to make sure we have the bandwidth to review and maintain. I'll let you know.

I realised this is the issue blocking us from switching from Mailchimp for host Updates for OSC and OCF. So I'm adding important because I think it would be great to use our own systems for these important comms.
The other issue on my mind for that is deliverability and whether we'll get through spam filters as well as mailchimp, but that's another issue.

We internally discussed an important blocker for this feature: while we want to keep this free for posting updates to your contributors, there will be a real infrastructure cost for us if people start using this as a public newsletter service and we don't set some kind of limitations or pricing first, as it will basically become a free version of Mailchimp. An update sent to 10.000 persons is at least a $8 USD charge for us. We need to think about ways to prevent abuse in order to make this change possible. Hopefully, something with a minimal impact on existing collectives.
The simplest I can think of right now, without locking us to a specific model is to have a tolerance based on their number of contributors (eg. if you have 10,000 contributors, it's ok to send 12,000 emails but it's not ok to send 12,000 emails if you only have 30 contributors). We can then ask collectives to contact us if they reach that limit to find an agreement, preventing them from publishing more updates before the situation is resolved.
Technically, we could achieve an MVP with:

Adding a new emailsSentCount column on Updates, increment this number when the update gets published
Before publishing a new update, check the total number of updates already published for this month. If the total number is more than 150% (we need to think of a number that makes sense) of the total number of contributors to the collective,(SUM(emailsSentCount) + nbEmailsToSend > nbUpdates * nbContributors * 1.5), prevent publishing the update and ask collective admins to contact support
When/if we receive such a request, we can directly see with the collective for them to setup a contribution to Open Collective and set a special flag on their collective to remove the limitation
We should update the docs/FAQ to explain all that

As a longer-term solution, we can imagine surfacing the pricing before publishing the update and automatically charge the collective when it gets published (again, only when the number of emails is above the tolerance range, based on the number of contributors).

It seems like a good enough approach for now. I really want us to find a good MVP solution to get the feature out there in the wild and see how people actually use it. But it's much easier to make a restricted feature more open than go the other way (i.e. releasing it to everyone and then later saying they have to pay), so I think starting with this limitation in place is a good idea. I also like how charging for actual cost of use is straightforward and doesn't need to complicate the pricing model.
We could automate it so the system submits an expense to their budget. I think we should have a lower threshold too - I don't want to bother charging people <$1 amounts every time they send a newsletter. So maybe we only charge when it costs us over a certain amount?
We should keep in mind the benefits their usage has in addition to the cost. If someone develops a large mailing list and that exposes thousands of people to the platform, it would only take a few of those people becoming contributors or starting Collectives for it to easily pay for itself. It's just an unknown. But regardless, we need to prevent abuse, such as people using this for spamming, or just trying to get a free mailchimp without ever intending to do fundraising.

Perhaps it's possible to generate an RSS feed for the updates, and recommend piping that into a newsletter service that they setup themselves? I just want some RSS xD

@jasikpark I'd love to have RSS too, that feature request has actually been documented here: https://github.com/opencollective/opencollective/issues/3504. But not everyone uses RSS, we need something simple that works for most users.

As a user who's wanted this sort of a feature in the past (and has so far worked around it by making small $1-5 contributions to projects I want to 'follow'), I would find value in this feature even if it didn't lead to me getting emailed out updates.
Just the ability to log into my OpenCollective account and go to a page of 'projects i'm following' would be a useful start, as there are a lot of cool projects out there that I come across and then forget exist over time. Of course I could work around that by just bookmarking them in my browser.. but that generally just ends up being like throwing the link into the void never to be resurfaced. I also tend to find that I (and others I know) can often use the pages/projects we follow as part of showing what we care about /communicating that to others when they are able to be seen from our profile; in the same way that our current contributions can be seen/displayed from our profiles.
The 'next step up' from there for me would be having a sort of in-platform notification system, so that I could see any updates from projects that i've followed and whether I had seen/read them yet or not.
Then finally, email updates would sort of be a 'last tier' for me, definitely can see the value in it, but this feature would still be really useful to me without having it at all. One potential thought I had here was that instead of taking on the financial costs/risk of sending the emails, perhaps the feature could be designed in a way that various 'mail as a service' providers could be 'plugged in' as options the collective could use, and then link to their own accounts with that provider. Initially perhaps only 1 is supported, but if designed well, then it would be a much smaller piece of work for others to contribute different 'connectors' to other providers in future, if/as needed. This same system could potentially be designed in a way that it could work for sending the updates via other methods as well (eg. Slack, Telegram, etc). Then, to bring it back to the previous discussions around OpenCollective providing the email service 'built in', this could just end up being a special 'limited' version of one of these connectors based on whatever volume/cost calculations seem feasible/sustainable.
So in summary, I wonder if there are some ways to break this down into smaller chunks of work that can still provide value, even while some of the bigger blocking questions might remain unknown?
Just my /2c, perspectives, and musings. Hopefully they're helpful :)

@0xdevalias thanks for that feedback, I love the idea of having a place to track all the initiatives you follow. In-app notification management would definitely be a huge plus for this feature, it's something we're discussing in https://github.com/opencollective/opencollective/issues/5382.

I love the idea of having a place to track all the initiatives you follow

this is a consideration for #5501 too.

This would really help our mutual aid group out. We've got key volunteers who don't (because they can't) donate financially but they're still contributors, but because they don't donate they don't get emails from us. If we could add them manually or have a sign-up sheet that would be great. Having this in one spot would save us a lot of headache from having to set up a separate mailing list or something like that.

I really like the challenge presented in this issue! I think it needs some design exploration to flesh out a coherent MVP and shape the other little things that complete the experience: Managing subscriptions, the concept of membership levels for communities (And stop calling everyone just contributors, among other things) Big +1!

"Follower" vs "Patron" is useful and helpful in patreon, though that's maybe a different paradigm

source: gharchive/issue

authors: 0xdevalias BenJam Betree Memo-Es Relequestual alanna alannallama bolariin jasikpark josegonzalez piamancini simonv3 snitin315 xdamman

repo: opencollective/opencollective

license: MIT

license_type: permissive

license_source: github-api


text:
Error message for long filename is confusing

Describe the bug
When uploading a receipt, there is an error message if the name of the file is too long. However, it isn't clear that that is what is going on.

To Reproduce
Steps to reproduce the behavior:

Try and submit a receipt with a filename over 255 characters long. I don't know how to do this - I couldn't figure out how to make a filename that long on OSX.

Expected behavior
I think the warning should be: "The filename for your receipt is too long. Could you shorten it?"
Additional context
Noted here: https://opencollective.com/email-markup-consortium/expenses/125848#new-comment-on-expense

Triage Template (core team only)
This template is for members of the team to triage for prioritisation. For more guidance see https://www.loom.com/share/369ab467fbc64dec848085d38ff57ca0:
P1 high frequency, high impact
P2 low frequency, high impact
P3 high frequency, low impact
P4 low frequency, low impact
Examples of high impact - a problem affects users during an essential process (expenses and payments > onboarding and registration > contributing) with no workaround.
High frequency - >10% of users affected (measured as a proportion of total potential users for this case).

In https://github.com/opencollective/opencollective-api/pull/8533 we've increased the max URL length but not the max file length. We'll solve the root issue and add a clearer error message.

authors: Betree RichardLitt


text:
healthz parameters for cisco

1. added bgp process "bgp" and chassis component name "Rack 0"
2. Origin as "openconfig" for healthz RPCs

Pull Request Functional Test Report for #3326 / a7f16f6ba4f93fbe3488d2209f7c557188bd2156
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

gNOI-5.3: Copying Debug Files

Cisco 8000E

gNOI-5.3: Copying Debug Files

Cisco XRd

gNOI-5.3: Copying Debug Files

Juniper ncPTX

gNOI-5.3: Copying Debug Files

Nokia SR Linux

gNOI-5.3: Copying Debug Files

Openconfig Lemming

gNOI-5.3: Copying Debug Files

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

gNOI-5.3: Copying Debug Files

Cisco 8808

gNOI-5.3: Copying Debug Files

Juniper PTX10008

gNOI-5.3: Copying Debug Files

Nokia 7250 IXR-10e

gNOI-5.3: Copying Debug Files

Help

Pull Request Test Coverage Report for Build 10099358083
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.5%

Totals

Change from base Build 10093226804:
0.0%

Covered Lines:
1983

Relevant Lines:
3573

💛  - Coveralls

/fptest cisco-xrd

@dplore could you please merge this if accepted?

/fptest cisco-xrd

/fptest cisco-8808

/fptest cisco-8000e

/fptest cisco-8000e

/fptest all

/fptest cisco-8808

@karthikeya-remilla this test is not passing on Cisco in our environment.  Before we can merge, I'd like to see this passing.  What are we missing?
Details

# show version
Wed Aug 14 15:09:11.997 PDT
Cisco IOS XR Software, Version 24.3.1.28I LNT
Copyright (c) 2013-2024 by Cisco Systems, Inc.
Build Information:
Built By     : sajshah
Built On     : Thu Aug 08 10:33:18 UTC 2024
Build Host   : iox-ucs-002
Workspace    : /auto/iox-ucs-002-san2/prod/24.3.1.28I.SIT_IMAGE/8000/ws
Version      : 24.3.1.28I
Label        : 24.3.1.28I-EFT2_rev2
=== RUN   TestCopyingDebugFiles
third_party/openconfig/featureprofiles/feature/gnoi/system/tests/copying_debug_files_test/copying_debug_files_test.go:67:
*** Fetching gNOI clients for xx27.den85...
third_party/openconfig/featureprofiles/feature/gnoi/system/tests/copying_debug_files_test/copying_debug_files_test.go:73: process bgp not found on device
--- FAIL: TestCopyingDebugFiles (18.11s)
=== RUN   TestChassisComponentArtifacts
third_party/openconfig/featureprofiles/feature/gnoi/system/tests/copying_debug_files_test/copying_debug_files_test.go:120:
*** Fetching gNOI clients for xx27.den85...
third_party/openconfig/featureprofiles/feature/gnoi/system/tests/copying_debug_files_test/copying_debug_files_test.go:137: Executing Healthz Check RPC for component Rack 0
third_party/openconfig/featureprofiles/feature/gnoi/system/tests/copying_debug_files_test/copying_debug_files_test.go:140: Unexpected error on executing Healthz Check RPC: rpc error: code = Unimplemented desc = error on request {
    path: {
      origin: "openconfig"
      elem: {
        name: "components"
      }
      elem: {
        name: "component"
        key: {
          key: "name"
          value: "Rack 0"
        }
      }
    }
    }: unknown service gnoi.healthz.Healthz

--- FAIL: TestChassisComponentArtifacts (0.76s)
FAIL

@karthikeya-remilla this test is not passing on Cisco in our environment. Before we can merge, I'd like to see this passing. What are we missing?

This is a 24.4.1 feature. This failure is expected on 24.3.1

Please note test is not passing in our environment and static check fix

Please review the logic while I work on static check and merge conflicts in metadata.pb.go.

updated PR description

Hi @karthikeya-remilla can you resolve the merge conflict with proto/metadata_go_proto/metadata.pb.go?  I will and merge this after resolved.

Hi @karthikeya-remilla can you resolve the merge conflict with proto/metadata_go_proto/metadata.pb.go? I will and merge this after resolved.

Hi @dplore , resolved the conflicts. Could you please check now as the FR is delivered?

@karthikeya-remilla there are a few static check errors to be resolved.
I am not sure why we seeing this panic in go test?   Are you seeing that when you run locally @karthikeya-remilla ?
Ref to broken github check: https://github.com/openconfig/featureprofiles/actions/runs/10744182024/job/29800536390?pr=3326#step:6:443

/fptest cisco-8000e

/fptest cisco-8000e
/fptest cisco-xrd

/fptest cisco-8000e
/fptest cisco-xrd

/fptest virtual

source: gharchive/pull-request

authors: OpenConfigBot coveralls dplore karthikeya-remilla

repo: openconfig/featureprofiles

license_source: bigquery


text:
Add code to register atlas to MNI space

This may exist, but let's put a pointer to it, if so.

Duplicate.


text:
Mediatype of layers should be application/vnd.oci.image.layer.v1.tar+gz

This is another thing I noticed this morning - the mediatype for layers should be in the layers family, but there were two tests (checking for other things) that had config types instead. Should this have been caught, or given that the tests were for failures for other things, it would have been caught had those other things not been wrong?
Signed-off-by: Vanessa Sochat vsochat@stanford.edu

The tests are failing because your commit's subject line is too long -- you could just make it "schema: use correct media-types for layers in tests" or something and provide the information in the body of the commit message.
Otherwise, LGTM.

LGTM

@cyphar pattern-matcher is not catching your approval, if you will will bump that again

I'm not sure about this one. The spec says:

Manifests concerned with portability SHOULD use one of the above media types. An encountered mediaType that is unknown to the implementation MUST be ignored.

(the above media types being layer media types), but it doesn't forbid layer descriptors that point to config files.

fair, but this is just in a test case

Yeah I could take this PR or leave it :man_shrugging:
What's there isn't wrong, it's just weird.

@vbatts The tests are failing because of the commit message -- @vsoch should fix that before we merge (since we use git-validation it will cause test failures for the rest of time :wink:).

What's wrong with the git message?

Just a high level observation - it's really really really hard to contribute simple things here because of these rules.

Fair. Though they are common formatting for git messages much beyond and
unrelated to OCI
On Tue, Dec 17, 2019, 18:14 Vanessasaurus notifications@github.com wrote:

Just a high level observation - it's really really really hard to
contribute simple things here because of these rules.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opencontainers/image-spec/pull/794?email_source=notifications&email_token=AAAQL2JM2QNXTOXLN62LT33QZFMM5A5CNFSM4JJXOFFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHEI5TY#issuecomment-566791887,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAQL2JJAIOZKMREWOFO7HLQZFMM5ANCNFSM4JJXOFFA
.

What's wrong with the git message?

The subject line (the first line of the message) is longer than 90 characters. This is the cause of the CI failure for this change.

Just a high level observation - it's really really really hard to contribute simple things here because of these rules.

I agree that these rules are frustrating (especially for drive-by contributors), but on the other hand there needs to be some limit to how long subject lines should be (because if they're too long, tools like git log start being quite hard to read in a terminal or small screen). 90 characters happens to be the limit we picked.
Now, I could also fix it for you -- but I personally don't like it when maintainers push to my tree -- so I don't do it to other people unless they've already given me permission to (annoyingly, GitHub has made "allow maintainers push to my tree" an opt-out option when creating a PR -- so I can't be sure if the person who submitted the PR actually has affirmatively given permission or if they didn't notice the option). Also, pushing to someone else's tree breaks the authorship and any signatures the author might have.
All of that being said -- we could drop using git-validation to not make this a hard requirement of PRs (personally I don't mind the length of this particular commit message). After all, we now use the DCO bot to check for Signed-off-by so we no longer need git-validation for that...

okay I just did a git --amend (I hope I didn't mess it up!)

@cyphar it's definitely an interesting conversation, because I have a colleague I was talking with recently about this, and he puts beautifully detailed (many lines) of message about the details of the work per commit for a large chunk of work. It's definitely a tradeoff between quality and quantity, and I do agree that it's probably best to put a reasonable limit and then try to make the message high quality. I am most certainly guilty of short, stupid and useless commit messages that could be better stated. :)

LGTM

LGTM.

@vsoch Just to be clear, there isn't a limit on the total size of the commit message -- it's just the first line of the commit message which has a limit placed on it (in order to make it easier to reference and make git log easier to read).
Personally I found that the way the Linux kernel does git commit messages (write them as an email, with the subject line being the first line of the commit message) really helps you get a better undersanding of how to write a commit message which makes sense by itself. Unlike most projects, Linux doesn't have a formal bug tracker so all of the context for a commit is included in the message itself (as well as references to other commits).

hooray! Thanks everyone :)

authors: cyphar jonjohnsonjr vbatts vsoch

repo: opencontainers/image-spec


text:
Does curve-csi support curvefs?

It seems that only curvebs are supported.

https://github.com/opencurve/curvefs-csi

authors: glyslxq spyyang

repo: opencurve/curve-csi


text:
About page in CVAT.ai UI has a broken link and the language needs edits

As I was trying to find some things in the UI I noticed that the About -> Need help? link is blowing an error.  I also noticed that the wording on the About page needs some editing.
What needs to be done:

Change the About page wording to:
"CVAT.ai is a completely re-designed and re-implemented version of the open source CVAT Computer Vision annotation AI data platform you know and love. It is an online, SaaS, interactive video and image annotation tool for computer vision. It has been used by our team to annotate millions of objects with a wide variety of properties."

Update the "Need help?" link to point to our Discord site.

Let me know if you have any questions.  Thanks!

Link to Drive folder with screenshots (must be a cvat.ai domain member to access):  https://drive.google.com/drive/folders/1fDRYoOvlvQ1H5-Hv5F6FcpmjdnLs7QVB?usp=drive_link

Hi Bill,

Update the "Need help?" link to point to our Discord site.

Need to decide if we still support gitter channel where the link is supposed to redirect. I do not see a lot of activities there.
https://app.gitter.im/#/room/#opencv-cvat_public:gitter.im
And discuss the tool description, I believe the previous one is quite outdated.

authors: HeffRaleigh bsekachev

repo: opencv/cvat


text:
RuntimeError: AssertionFailed: perm.size() == 4 using inference_engine load function

Hi,
When I used Python API of inference_engine to load my model, the following error is thrown when load is called:
Traceback (most recent call last):
  File "/home/wd-ai/git-pkgs/OpenVINO-YoloV3/try_multi_thread.py", line 113, in <module>
    inferencers.append(Inferencer())
  File "/home/wd-ai/git-pkgs/OpenVINO-YoloV3/try_multi_thread.py", line 76, in __init__
    self.exec_net = self.plugin.load(network=self.net, num_requests=num_requests)
  File "ie_api.pyx", line 395, in openvino.inference_engine.ie_api.IEPlugin.load
  File "ie_api.pyx", line 406, in openvino.inference_engine.ie_api.IEPlugin.load
RuntimeError: AssertionFailed: perm.size() == 4

The model which throws the error is attached in the following link:
https://wdc.box.com/s/o305d7we1dn2bsr7s3fn87fozm45wemi
What is also attached in the link is a model without the error.
The only difference between two models are the "Permute" operation.
Therefore I suspect there are some problems in the permute operation of inference_engine.

Dear @wuhy08
I have seen  a similar issue before on the Intel Developer Zone OpenVino forums. I have to ask - are you using the latest and greatest 2019 OpenVino release ? Because this issue (if you agree that it's the same one as the IDZ Issue has been fixed.
Please report back here and let us know.
Sorry for the inconvenience and thanks for using OpenVino !
Shubha

Dear @shubha-ramani
I think I am using 2nd latest and still greatest OpenVINO 2019R1. I just noticed R1.1 is released. Let me try with that and get back to you. But my issue is a little different from what is on IDZ. The author there wants to permute 3 dims, while I want to permute 5 dims. However, I have a workaround in my model to avoid permutation in 5 dims.
I also have some other issues with IE. I will investigate it by myself before posting. Hopefully R1.1 will fix it. I will close this one for now.
Thank you so much and have a great weekend!

repo: opencv/dldt


text:
Change cultivated aggregation logic and make sensor choice an option

Changes:

the logic of cultivated changed from any sensor says cultivated -> cultivated to any sensor says natural -> natural as bias towards cultivated class was observed in validation
sensor choice as an option for both cultivated and woody cover
woody cover band name aligned with official definition woody instead of woody_cover

Has the impact on the accuracy of validation data been measured? Not sure we have data from different sensors in the validation but if we do, it's worth checking this.

I have to merge this to be able to run another continental scale and then on validation data. There would be retrace potentially.

repo: opendatacube/odc-stats


text:
Fix occasional duplication of dropdown values.

Happens randomly after refreshing the page.

There is no reliable reproducer and it does not break the funcionality - though it is a UX issue.
Removing it from the milestone, but keeping it open

There is no reliable reproducer and it does not break the funcionality - though it is a UX issue.
Removing it from the milestone, but keeping it open

authors: mroman-redhat vpavlin


text:
[NB] Inspect the habana accelerator support on notebooks

Plan to have separate workbench images with habana tool kits installed to support habana accelerators.
Acceptance criteria :

[ ] Estimate the works timeline
[ ] Requirments for fulfilling this request.

Resources:
https://developer.habana.ai/resources/kernel-libraries/
https://docs.habana.ai/en/latest/TPC/TPC_Tools_Installation/TPC_Tools_Installation_Guide.html
https://github.com/HabanaAI/Habana_Custom_Kernel

The work is in-progress, started in sprint 1.30.
This issue is being moved to 1.31 sprint, and would be completed there.

Documentation on testing: https://docs.google.com/document/d/1wkMVnONDzMSaCnJMK_AUO0vnoHQ-oYlVmJ1b5d6tPtg/edit
Habana setup: https://docs.google.com/document/d/13-0FcwoZliwA0cMOU1oekdau4QT2YnlilsD-vJ_1ih4/edit#heading=h.mpizlxpep9m5

repo: opendatahub-io/notebooks


text:
[volumi invasati] verificare dati di giugno 2024

Picco anomalo per lentini, poma, garcia (ma controllare tutte le dighe)

(viz non ancora pubblica)

da qui AEGIS (livello ifdrometrico - giugno 2024) https://www.protezionecivilesicilia.it:8443/aegis/map/map2d

@dennisangemi che fa le soprese ❣

Risolto!

Qui una preview della dashboard (ancora wip) https://lookerstudio.google.com/reporting/241228ac-70d4-4861-88c7-a9058ab28a11

Grazie @pigreco!

Risolto!

In che senso? C'era un errore nei dati?

In che senso? C'era un errore nei dati?

@aborruso esatto, qualcosa durante l'estrazione dei dati di giugno era andata sorta. C'erano dati errati che ho corretto sulla base del pdf della regione https://www.regione.sicilia.it/sites/default/files/2024-06/0__2024.06.01_A_Tabella_volumi_invasi.pdf
Per estrarre i dati di giugno ho usato
 curl -s https://raw.githubusercontent.com/opendatasicilia/emergenza-idrica-sicilia/refs/heads/main/risorse/sicilia_dighe_anagrafica.csv | llm -t volumi_dighe -a pdf/Tabelle/volumi_2024-06.pdf > 2024-06.csv

con template:
system: Il tuo compito è quello di estrarre dati da un pdf allegato e di incrociarli con i dati di un'anagrafica csv passata come prompt. Dalla tabella pdf, individua la data di rilevazione e poi estrai tutti i dati della colonna diga (chiamala 'diga_pdf') e quelli della colonna relativa al volume registrato nel mese più recente. Arricchisci la tabella aggiungendo una colonna chiamata 'data' che abbia in ogni riga la data della rilevazione più recente a cui si riferiscono i dati nel formato yyyy-mm-dd. Dal CSV, estrai la colonna 'diga' che chiamerai 'diga_anagrafica' popolata con il nome corretto (da includere esattamente nell'output). Confronta le colonne 'diga_pdf' e 'diga_anagrafica' per fare in modo di arricchire il dataset e assegnare a ogni diga il corrispondente codice identificativo presente nella colonna 'cod' del csv. Attenzione alla diga ogliastro e don sturzo che sono la stessa cosa. In ultimo, cestina la colonna 'diga_pdf' e  nell'output includi i valori di 'diga_anagrafica' sotto il nome di 'diga'. Attenzione ad attribuire correttamente il codice al nome della diga secondo l'anagrafica csv. Se l'anagrafica csv contiene più dighe della tabella pdf, l'output deve contenere solo ed esclusivamente le dighe presenti nel file pdf. Se nell'anagrafica ci sono più dighe del pdf, il volume non deve essere 0 ma deve essere vuoto. L'output deve avere questa struttura 'cod,diga,data,volume'. Tieni presente che i valori di 'diga' devono essere esattamente coincidenti con quelli di 'diga_anagrafica'. I separatori di decimali dei volumi devono essere i punti e non le virgole. L'output non deve contenere i backtips all'inizio e alla fine ma solo il contenuto del file csv a cominciare dagli header.

e gemini-1.5-pro-latest come modello.
Non sarà il più bel system prompt di sempre... però funziona (l'ho dovuto modificare un paio di volte)

Sarà bello raccontarlo!!

C'è da aggiungere di rimuovere le righe vuote.
Ma è bellissimo

Hai ragione @aborruso! In realtà per lo scopo di questo repo c'è anche da modificare la data in dd/mm/yyyy perchè per qualche ragione dall'inizio di questo repo è stato utilizzato questo formato.
Anche se io convertirei le date del repo da dd/mm/yyyy a yyyy-mm-dd... Magari apro issue dedicata e ne parliamo

authors: aborruso dennisangemi pigreco


text:
Bunker Defenses?  (Can't figure out how to add tags sorry.)

Maybe you could add some way of defending your bunker? Not sure if you are planning on making anything to do with attacks on bunkers (by AI or other players), but it could be an interesting feature.

The current idea is that the bunker is a level just like any other (like dungeons; it's not an open world game). But we could add enemies in the bunker level which try to break in. That would probably require the development of interactive physical items like barricades first though. That sounds like it could make the game a bit harder and interesting, so thanks for the idea.

repo: opendevleague/bunkernz


text:
BeV Speed RL Pretrain Model

ISSUE TEMPLATE
Hi DI-Drive team,
I appreciate your work and am trying to use this platform. Could you provide any access to your pretrained models of the BEV Speed RL? Thank you very much.

[ ] I have marked all applicable categories:

[ ] exception-raising bug
[ ] RL algorithm bug
[ ] system worker bug
[ ] system utils bug
[ ] code design/refactor
[ ] documentation request
[x] new feature request

[x] I have visited the readme and doc
[x] I have searched through the issue tracker and pr tracker
[x] I have mentioned version numbers, operating system and environment, where applicable:import core, torch, sys
print(core.__version__, torch.__version__, sys.version, sys.platform)

Hi, we have provided a DQN pretrain model of BEV speed RL training in the following link.
Plus25.pth
We will soon update pretrains into documents.
thx

repo: opendilab/DI-drive


text:
LlamaFlashAttention2 __init__ is undefined.

The LlamaFlashAttention2 has no __init__(). As a result running the system with flash-attn will crash.
https://github.com/opendilab/LMDrive/blob/ae0643d071b08b38cd326314bcbfb44aa4e60232/LAVIS/lavis/models/blip2_models/modeling_llama.py#L415

Hi!
Sorry for the late reply. I've been very busy lately.
It's an experimental feature, and you can simply replace the forward function and other related functions from LlamaAttention with those from LlamaFlashAttention2. I also update the code.

I've included that in my local repo, but not a bad thing for you to include in your public repo.

repo: opendilab/LMDrive


text:
add make_lazy and make_collect

Closes #860

Current dependencies on/for this PR:

main

PR #763

PR #765

PR #767

PR #769

PR #771

PR #862   👈
PR #774

PR #795

PR #819

Closing as FFI-based code is no longer being used post-refactor.

repo: opendp/opendp


text:
chore(openapi): use openapi uuid format

Set the Replica, Nexus and Volume with a UUID format within openapi.
The pool/node are other candidates, which could either be a UUID or remain
as a "string" but still unique.
Note this is only about openapi, there is no strict enforcement on the
data because how would we handle when a resource created under us in
mayastor is not on the UUI format?
In such case, we might want to validate these only in the rest frontend?

bors merge

repo: openebs/mayastor-control-plane


text:
docs(ndm): update NDM docs with new features

removed GPTBasedUUID from alpha features
modified user guide to remove partitions and unsupported disks in general

Signed-off-by: Akhil Mohan akhil.mohan@mayadata.io

@kmova PTAL.

repo: openebs/openebs-docs


text:
Add snapshot controller to helm

NOTE: Raising this for initial reviews. The values need to be updated with the release tags, once the releases of individual components are made.
What this PR does / why we need it:
This PR adds the snapshot operator ( controller and provisioner) deployment to helm charts. The snapshot operator has already been tested by adding it to the openebs-operator.yaml. This PR also does the following:

Renames the snapshot controller to snapshot operator
Adds sample yamls for creating snapshot and clone to percona demo application.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:

LGTM

authors: kmova ksatchit

repo: openebs/openebs


text:
side effect of contextual tuple

There are two issues of contextual tuple I discovered. Below is my model:
type user
type repository
  relations
    define admin as self
    define user as self
type group
  relations
    define member as self
type tenure
  relations
    define user as self
type artifact
  relations
    define allowed_tenure as self
    define can_download as user from repo and member from group
    define can_upload as can_download and user from allowed_tenure
    define group as self
    define repo as self

And I populate the model with the following relation:
{
  "tuple_key": {
    "user": "user:anne",
    "relation": "member",
    "object": "group:engineering"
  }
}

{
  "tuple_key": {
    "user": "user:anne",
    "relation": "user",
    "object": "repository:us-east"
  }
}

{
  "tuple_key": {
    "user": "group:engineering",
    "relation": "group",
    "object": "artifact:doc1"
  }
}

{
  "tuple_key": {
    "user": "repository:us-east",
    "relation": "repo",
    "object": "artifact:doc1"
  }
}

{
  "tuple_key": {
    "user": "tenure:gt3",
    "relation": "allowed_tenure",
    "object": "artifact:doc1"
  }
}

It's apparent that user:anne has a can_download relation with artifact:doc1. And this can be verified with a check API. However, if I add a contextual tuple to the request in the body:
{
  "tuple_key": {
    "user": "anne",
    "relation": "can_download",
    "object": "artifact:doc1"
  },
  "contextual_tuples": {
    "tuple_keys": [
      {
        "user": "user:anne",
        "relation": "user",
        "object": "tenure:gt3"
      }
    ]
  }
}

The returned response is false. Is this an undesirable side effect of contextual tuple?
Another question is that I found that contextual tuple does not really work. The returned answer to a can_upload query is still false with the following request:
{
  "tuple_key": {
    "user": "anne",
    "relation": "can_upload",
    "object": "artifact:doc1"
  },
  "contextual_tuples": {
    "tuple_keys": [
      {
        "user": "user:anne",
        "relation": "user",
        "object": "tenure:gt3"
      }
    ]
  }
}

Hi @mango009 👋🏽

Did you verify that your checks are working without the contextual tuples? I tried to check them here and they were (correctly) returning false.

The reason they are returning false is that in the checks you are forgetting the user type. It should be:
{
  "tuple_key": {
    "user": "user:anne",
    "relation": "can_upload",
    "object": "artifact:doc1"
  }
}

Tried reproducing on the FGA Playground: https://play.fga.dev/stores/create/?id=01GG41ZGQZD6GMDBM84RK2FG49
curl -X POST 'https://api.playground.fga.dev/stores/01GG41ZGQZD6GMDBM84RK2FG49/check' \
 -d '{
  "tuple_key": {
    "user": "user:anne",
    "relation": "can_download",
    "object": "artifact:doc1"
  },
  "contextual_tuples": {
    "tuple_keys": [
      {
        "user": "user:anne",
        "relation": "user",
        "object": "tenure:gt3"
      }
    ]
  }
}'

returns {"allowed":true,"resolution":""} - which is correct. This would return the same result if the contextual tuple was not sent as placement in a tenure should not affect ability to download (according to the model).
curl -X POST 'https://api.playground.fga.dev/stores/01GG41ZGQZD6GMDBM84RK2FG49/check' \
 -d '{
  "tuple_key": {
    "user": "user:anne",
    "relation": "can_upload",
    "object": "artifact:doc1"
  },
  "contextual_tuples": {
    "tuple_keys": [
      {
        "user": "user:anne",
        "relation": "user",
        "object": "tenure:gt3"
      }
    ]
  }
}'

returns {"allowed":true,"resolution":""} - which is correct. This is different from if the contextual tuple was not passed, as if user:anne was not in that tenure, then they would not have had upload access.
Note: Unfortunately the Playground does not support intersections in the Graph preview.

I'll close this issue for now. Please reopen it if it has not solved your problem.

Hi @mango009
Have you been able to successfully utilize OpenFGA? If so, I would love to hear about your experience and any feedback you may have.
If you don't mind sharing, please email me directly at andres.aguiar at openfga.dev
Thanks!

authors: aaguiarz craigpastro mango009 rhamzeh

repo: openfga/openfga


text:
AGALMiniAssembler doesn't support .rgba swizzling on any target.

Any sequence starting with r, g, b, or a gets removed (as well as the dot in front). This means "v0.r" becomes just "v0," so even though I tried to access only the first component, all four end up being copied.
To test this, I replaced line 64 with the following.

"mov v0.r, va1.r", which ought to throw an error.
"mov v0.rgb, va1.rrr", which ought to produce a grey-black-black triangle.
"mov v0.rgb, va1.rgg", which ought to produce a red-cyan-black triangle.
"mov v0.rzzz, va1.rzzz", which ought to produce erratic behavior as reported in issue #1460.

Instead of doing any of these things, every single example here produces the normal red-green-blue spinning triangle. I tested this on Flash, Neko, and Windows, and I assume it works the same everywhere else.

I think this is the newest AGALMiniAssembler from the Adobe Gaming SDK:
https://github.com/Gamua/Starling-Framework/blob/master/starling/src/com/adobe/utils/AGALMiniAssembler.as
(which I think is the same as https://github.com/adobe-flash/graphicscorelib/blob/master/src/com/adobe/utils/v3/AGALMiniAssembler.as)
Do you think this supports rgba color accessors, or do you think we had an error in porting?
I see "xyzw" in the regexes, but nothing for "rgba" or similar 😕

Huh... looks like Adobe's documentation is wrong. Never mind, then!

Do you think that they removed rgba from the AGAL specification, or do you think they just broke support in their assembler? We could patch it if the latter is the case

I suspect it was never in the specification in the first place, and whoever wrote the documentation got AGAL confused with GLSL.
That said, I wouldn't complain if you patched it in.

Hmm, I'm on the fence about it.
From the looks of it, I think we'd need to add "rgba" as acceptable letters in the regexes here:
https://github.com/openfl/openfl/blob/develop/openfl/utils/AGALMiniAssembler.hx#L230-L236
Then I believe we would need to update the "maskmatch" routine here to map "rgba" to the correct indices:
https://github.com/openfl/openfl/blob/develop/openfl/utils/AGALMiniAssembler.hx#L480
Or do a string replace in advance to translate to "xyzw" format

The string replace sounds easier to do and a lot easier to debug.

repo: openfl/openfl

license: mit


text:
FEAT: confirmation added when setting a photo from the photos tab

Description
Added a toast to let user know the image is set

Related issues

Fixes #3832

Screenshots

As Android Docs recommends, I'd like to use snackbar for this.

@VaiTon made the changes

Thanks! 🎉

repo: openfoodfacts/openfoodfacts-androidapp


text:
It's impossible to expand the last section of food preferences in the onboarding

What

It's impossible to expand the last section of food preferences in the onboarding

Says who?

Probably fixed by #2306.

authors: monsieurtanuki teolemon

repo: openfoodfacts/smooth-app


text:
[Feedback requested] Reorg. of the code

Hi everyone!
The code of the project mixes many different concepts: data, transformation, ui, app stuff…
Viewing the hierarchy doesn't help to easily and quickly find things:

In red: data-related (DB, transformation, background tasks, queries…)
In blue: UI-related (mainly screens + widgets)
In green: app-related (entrypoints + main)
Before proposing any change, I would like to know if I'm the only one in the situation of always wondering "where should I put this, or that?".
And if true, do you have any suggestions to improve this?

background might be renamed background_tasks
A lot of files don't mean a lot to me, the wording is not always the same as elsewhere (eg server)
When naming files, I tend to put the common part first for better legibility (kp already follow this convention):
helper_toto
helper_tata
helper_totorototoro

I haven't been in the codebase myself for a while, but yes, it has often been said, especially by new contributors, that it is difficult to find the right files.
I think suggestions for changes are good for now. The only question is how we can do it without making too many changes


text:
新增加 LawVersion

增加法律的三讀版本紀錄 api /law_versions

https://v2.ly.govapi.tw/law_versions
https://v2.ly.govapi.tw/law_versions/1931-01-20-制定
done

https://v2.ly.govapi.tw/laws/04102/versions
https://v2.ly.govapi.tw/law_version/1948-04-18-制定/contents
增加兩個 relations api


text:
Requirement for uvloop

Check on uvloop requirement for Fn.

Just add it back in, speeds up functions but it's only available  on Linux and macOS which is fine.

repo: openghg/openghg


text:
Update README.md with more support options

As they highlighted here, we never promoted our ideas platform. https://github.com/opengisch/QField/discussions/5393#discussioncomment-9878195

@suricactus LGTM

authors: mbernasocchi suricactus

repo: opengisch/qfieldcloud


text:
add cookie set

Changes
Please provide a brief description of the changes here.
Merge Requirements
For new features contributions please make sure you have completed the following
essential items:

[ ] CHANGELOG.md updated to document new feature additions
[ ] Appropriate documentation updates in the docs

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

we need pull request in adservice-v2 instead

repo: openinsight-proj/opentelemetry-demo


text:
Discuss joining the Open Regulatory Compliance Working Group

The Open Regulatory Compliance Working Group (ORC WG) is working with the open source community, the European Commission, industry organizations, and European Standards Organizations to help with the implementation of the Cyber Resilience Act.
Getting involved now could really help make sure that the compliance requirements won't conflict with the JavaScript ecosystem.
Full disclosure: the Eclipse Foundation is one of my company's clients, and I'm actively involved in driving the ORC WG.

What's the relationship with the Commission? I guess we should be involved in whatever WG matters for the CRA to represent JS. I knew the LF was doing some kind of other initiatives, maybe @rginn can make the necessary intros.
Anyhow, we should have a good idea of how that matters for us and our projects.

I've given a lot more context in today's weekly call. I believe the recording will be shared here as soon as it is ready.
Relevant links:

How to join the WG: https://orcwg.org/membership/ (it's free)
Inventory of existing practices and related README.

authors: mcollina tobie

repo: openjs-foundation/security-collab-space


text:
Update README.md

Double written in README.md

Customization
Customization

Thank you @lizzymax96👍

repo: openlab-x/GithubFlareStats


text:
Remove use of goog.math.Rect

fixes #4906

Looks good.  Please merge if the control still works.

authors: fredj tschaub


text:
ci: remove next from build targets

Overview
We no longer use next

Next branch is removed, so merging.

repo: openmeterio/openmeter


text:
Pwd required false and email config for web

cc @manics @kennethgillen
this temporary change is necessary for testing of RC2 see lines 3 and 5.
The playbook should be re-run only against pub-omero which is used for the RC2 testing.
The change for the demo server will be done in another PR later on.

This is deployed on pub-omero

@pwalczysko if you want to keep pub-omero set up like this, we could set up a separate set of configuration for pub-omero v.s. ome-demoserver like we do for the two Nightshade webclients, ns-web and ns-web-pub.
See https://github.com/openmicroscopy/prod-playbooks/blob/master/nightshade-webclients.yml#L207
Otherwise, we can't merge this, given we don't actually want to apply https://github.com/openmicroscopy/prod-playbooks/pull/92/files#diff-896819b5bdf43f197f838c7cc66babf4R359 to ome-demoserver during next week's 5.4.7 deployment.

Thanks @pwalczysko.

authors: kennethgillen manics pwalczysko

repo: openmicroscopy/prod-playbooks


text:
deprecate react-hot-loader

see: https://codeburst.io/react-hot-loader-considered-harmful-321fe3b6ca74

https://github.com/gaearon/react-hot-boilerplate/issues/97#issuecomment-249862775

see #69

repo: openpitrix/dashboard


text:
Show Balance, or Rather, Available Credit Above Debt Limit

We should show the user's, "balance" communicated as an amount remaining toward credit limit.

At a minimum this should show up on the Profile page.
Better this should follow the user throughout the website.
Architecture:
Have an API call which auto-calculates the balance based upon same formula used in profile (or use currently existing API which is used to access balance).
http://localhost/api/v0/user/{USERNAME}
Include API call on sidebar
Unfortunately API is called on every time side bar is called hypothetically.
The advantage would be that it's updated consistently and statelessly.

Note, the current API call already works:
http://localhost/api/v0/userinfo/patrick

For example:
username	"patrick"
displayname	"Patrick"
usertype	"REGULAR"
initialAccountBalance	0
accountBalance	-51
personalEmoji	"🐺"
description	"Stuff"
personalink1	"https://www.google.com/"

Under the hood, this uses the user's, "wallet" balance which is cached.
func GetPublicUserInfo(db *gorm.DB, username string) PublicUserType {

	var user models.User
	db.Where("username = ?", username).First(&user)

	return PublicUserType{
		Username:              user.Username,
		DisplayName:           user.DisplayName,
		UserType:              user.UserType,
		InitialAccountBalance: user.InitialAccountBalance,
		AccountBalance:        user.AccountBalance,
		PersonalEmoji:         user.PersonalEmoji,
		Description:           user.Description,
		PersonalLink1:         user.PersonalLink1,
		PersonalLink2:         user.PersonalLink2,
		PersonalLink3:         user.PersonalLink3,
		PersonalLink4:         user.PersonalLink4,
	}
}

So it's basically a database query, no advanced calculation going on here. Same goes for all of the other queries into the database on this function.
So basically, we can just call this within the sidebar and show the balance.

The above being said, if we want to really display JUST the remaining available credit, e.g. whatever the user can still spend given the debt limit, e.g., "Credit" then we should take the total amount available in credit plus the balance (which, if a negative will subtract from the credit remaining).

repo: openpredictionmarkets/socialpredict


text:
Upgrade Ruby to 2.5.0

Context
This PR upgrades Ruby from version 2.4.2 to 2.5.0.

No changes in gemfile.lock?

No changes.

Does this mean people using the gem will need to be on this ruby version?

It does @gidsg.

Or higher.

I don't think that is true actually. The gemspec sets the "rules" for dependancy versions. .ruby-version only sets the ruby version via rvm etc in development

Actually, yes, you're right Dan.

authors: danmitchell- gidsg karlbaker02

repo: openregister/registers-ruby-client


text:
Allow upgrading non-semver Maven dependencies

When an existing Maven dependency has a version which is non-semver-friendly (like org.springframework.cloud:spring-cloud-dependencies:Camden.SR5), the UpgradeDependencyVersion and ChangeParentPom recipes should be able to do the upgrade anyway.
Introduces a new Semver#isVersion(String) utility to check if a given version string is a valid semver version.

These awful Spring Cloud versions (I am glad they have now gone away from this) are even worse in the context of ChangeParentPom:
Exception while visiting project file 'pom.xml', caused by: java.lang.IllegalStateException: Illegal state while comparing versions : [Dalston.SR4.0.0.0.0.0.0] and [2022.0.2]. Metadata = [null], at org.openrewrite.semver.LatestRelease.compare(LatestRelease.java:135)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:347)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.openrewrite.maven:rewrite-maven-plugin:4.43.0:run failed: Exception while visiting project file 'pom.xml', caused by: java.lang.IllegalStateException: Illegal state while comparing versions : [Dalston.SR4.0.0.0.0.0.0] and [2022.0.2]. Metadata = [null], at org.openrewrite.semver.LatestRelease.compare(LatestRelease.java:135)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:133)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:342)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.openrewrite.internal.RecipeRunException: Exception while visiting project file 'pom.xml', caused by: java.lang.IllegalStateException: Illegal state while comparing versions : [Dalston.SR4.0.0.0.0.0.0] and [2022.0.2]. Metadata = [null], at org.openrewrite.semver.LatestRelease.compare(LatestRelease.java:135)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:324)
    at org.openrewrite.TreeVisitor.visitAndCast (TreeVisitor.java:356)
    at org.openrewrite.xml.XmlVisitor.lambda$visitTag$2 (XmlVisitor.java:91)
    at org.openrewrite.internal.ListUtils.lambda$map$0 (ListUtils.java:144)
    at org.openrewrite.internal.ListUtils.map (ListUtils.java:125)
    at org.openrewrite.internal.ListUtils.map (ListUtils.java:144)
    at org.openrewrite.xml.XmlVisitor.visitTag (XmlVisitor.java:91)
    at org.openrewrite.maven.MavenIsoVisitor.visitTag (MavenIsoVisitor.java:38)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:163)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:156)
    at org.openrewrite.xml.tree.Xml$Tag.acceptXml (Xml.java:426)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.TreeVisitor.visitAndCast (TreeVisitor.java:356)
    at org.openrewrite.xml.XmlVisitor.visitDocument (XmlVisitor.java:71)
    at org.openrewrite.maven.MavenIsoVisitor.visitDocument (MavenIsoVisitor.java:23)
    at org.openrewrite.maven.MavenIsoVisitor.visitDocument (MavenIsoVisitor.java:20)
    at org.openrewrite.xml.tree.Xml$Document.acceptXml (Xml.java:151)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.RecipeScheduler.lambda$scheduleVisit$3 (RecipeScheduler.java:258)
    at org.openrewrite.RecipeScheduler.lambda$mapAsync$0 (RecipeScheduler.java:58)
    at org.openrewrite.scheduling.ForkJoinScheduler.lambda$schedule$0 (ForkJoinScheduler.java:41)
    at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec (ForkJoinTask.java:1375)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:373)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1182)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1655)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1622)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:165)
Caused by: java.lang.IllegalStateException: Illegal state while comparing versions : [Dalston.SR4.0.0.0.0.0.0] and [2022.0.2]. Metadata = [null]
    at org.openrewrite.semver.LatestRelease.compare (LatestRelease.java:135)
    at org.openrewrite.maven.ChangeParentPom$2.lambda$findNewerDependencyVersion$2 (ChangeParentPom.java:221)
    at java.util.stream.ReferencePipeline$2$1.accept (ReferencePipeline.java:178)
    at java.util.stream.ReferencePipeline$2$1.accept (ReferencePipeline.java:179)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1625)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:499)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:682)
    at org.openrewrite.maven.ChangeParentPom$2.findNewerDependencyVersion (ChangeParentPom.java:222)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:175)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:156)
    at org.openrewrite.xml.tree.Xml$Tag.acceptXml (Xml.java:426)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.TreeVisitor.visitAndCast (TreeVisitor.java:356)
    at org.openrewrite.xml.XmlVisitor.lambda$visitTag$2 (XmlVisitor.java:91)
    at org.openrewrite.internal.ListUtils.lambda$map$0 (ListUtils.java:144)
    at org.openrewrite.internal.ListUtils.map (ListUtils.java:125)
    at org.openrewrite.internal.ListUtils.map (ListUtils.java:144)
    at org.openrewrite.xml.XmlVisitor.visitTag (XmlVisitor.java:91)
    at org.openrewrite.maven.MavenIsoVisitor.visitTag (MavenIsoVisitor.java:38)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:163)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:156)
    at org.openrewrite.xml.tree.Xml$Tag.acceptXml (Xml.java:426)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.TreeVisitor.visitAndCast (TreeVisitor.java:356)
    at org.openrewrite.xml.XmlVisitor.visitDocument (XmlVisitor.java:71)
    at org.openrewrite.maven.MavenIsoVisitor.visitDocument (MavenIsoVisitor.java:23)
    at org.openrewrite.maven.MavenIsoVisitor.visitDocument (MavenIsoVisitor.java:20)
    at org.openrewrite.xml.tree.Xml$Document.acceptXml (Xml.java:151)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.RecipeScheduler.lambda$scheduleVisit$3 (RecipeScheduler.java:258)
    at org.openrewrite.RecipeScheduler.lambda$mapAsync$0 (RecipeScheduler.java:58)
    at org.openrewrite.scheduling.ForkJoinScheduler.lambda$schedule$0 (ForkJoinScheduler.java:41)
    at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec (ForkJoinTask.java:1375)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:373)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1182)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1655)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1622)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:165)
Caused by: java.lang.IllegalStateException: No match found
    at java.util.regex.Matcher.group (Matcher.java:644)
    at org.openrewrite.semver.LatestRelease.compare (LatestRelease.java:120)
    at org.openrewrite.maven.ChangeParentPom$2.lambda$findNewerDependencyVersion$2 (ChangeParentPom.java:221)
    at java.util.stream.ReferencePipeline$2$1.accept (ReferencePipeline.java:178)
    at java.util.stream.ReferencePipeline$2$1.accept (ReferencePipeline.java:179)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1625)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:499)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:682)
    at org.openrewrite.maven.ChangeParentPom$2.findNewerDependencyVersion (ChangeParentPom.java:222)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:175)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:156)
    at org.openrewrite.xml.tree.Xml$Tag.acceptXml (Xml.java:426)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.TreeVisitor.visitAndCast (TreeVisitor.java:356)
    at org.openrewrite.xml.XmlVisitor.lambda$visitTag$2 (XmlVisitor.java:91)
    at org.openrewrite.internal.ListUtils.lambda$map$0 (ListUtils.java:144)
    at org.openrewrite.internal.ListUtils.map (ListUtils.java:125)
    at org.openrewrite.internal.ListUtils.map (ListUtils.java:144)
    at org.openrewrite.xml.XmlVisitor.visitTag (XmlVisitor.java:91)
    at org.openrewrite.maven.MavenIsoVisitor.visitTag (MavenIsoVisitor.java:38)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:163)
    at org.openrewrite.maven.ChangeParentPom$2.visitTag (ChangeParentPom.java:156)
    at org.openrewrite.xml.tree.Xml$Tag.acceptXml (Xml.java:426)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.TreeVisitor.visitAndCast (TreeVisitor.java:356)
    at org.openrewrite.xml.XmlVisitor.visitDocument (XmlVisitor.java:71)
    at org.openrewrite.maven.MavenIsoVisitor.visitDocument (MavenIsoVisitor.java:23)
    at org.openrewrite.maven.MavenIsoVisitor.visitDocument (MavenIsoVisitor.java:20)
    at org.openrewrite.xml.tree.Xml$Document.acceptXml (Xml.java:151)
    at org.openrewrite.xml.tree.Xml.accept (Xml.java:50)
    at org.openrewrite.TreeVisitor.visit (TreeVisitor.java:276)
    at org.openrewrite.RecipeScheduler.lambda$scheduleVisit$3 (RecipeScheduler.java:258)
    at org.openrewrite.RecipeScheduler.lambda$mapAsync$0 (RecipeScheduler.java:58)
    at org.openrewrite.scheduling.ForkJoinScheduler.lambda$schedule$0 (ForkJoinScheduler.java:41)
    at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec (ForkJoinTask.java:1375)
    at java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:373)
    at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec (ForkJoinPool.java:1182)
    at java.util.concurrent.ForkJoinPool.scan (ForkJoinPool.java:1655)
    at java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1622)
    at java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:165)

Depending on what we can agree on, I will also make a corresponding change there.

Maybe we just need to be resilient with respect to non-semver versions.

It should also be possible to upgrade TO any valid maven version, including version ranges, literal or resolved?

It should also be possible to upgrade TO any valid maven version, including version ranges, literal or resolved?

I also thought about this, but decided to wait with this until a user requests this, to not open another can of worms :-)

authors: knutwannheden pjotteri

repo: openrewrite/rewrite


text:
Update HTCondor upgrade information

I was lazy and just grabbed the bullet points from the 8.9.x release announcements. I'll replace that with a link when flightworthy makes a better doc.

I think this is good enough for now. It will change substantially when 8.9.12/9.0.0 configuration is finalized.

repo: opensciencegrid/docs


text:
Update OpenSDS POC

In the latest version of OpenSDS, we have finished OpenSDS integration of Cinder.

Hi Leon, please provide an abstract of what you modified in the new patches

Yeah, the changes are as follows:

We did some changes to OpenSDS SB Interface and make sure that it's highly standard.
We have enhanced the OpenStack-GoClient module and right now OpenSDS works well with Cinder in volume operations.
We also modified the grpc module code and change it from multiple server instance to one single server instance, which will cost less memory resource.
Finally we add more choice when user wants to list all volumes. Right now he/she can choose to watch summarized volume list or detailed volumes list.

Please do wait for other reviewers to merge the PR in the later PRs

authors: hannibalhuang leonwanghui

repo: opensds/opensds


text:
I'm missing something simple !

[testing locally with Xubuntu, VisualStudioCode and Chromium-browser ]
I've  got a 4000x4000 px  image which I can view with seadragon (zooming and dragging)  as
follows
<div id="openseadragon1" style="width: 800px; height: 600px; background-color: #434343;">/div>
<script src="./seadragon/openseadragon.min.js"></script>
    var viewer = OpenSeadragon({
        id: "openseadragon1",
        prefixUrl: "./seadragon/images/",
        tileSources: {
            url: "./tile_source/bigmap.jpg",
            type: 'image
        }});
</script>

I then created tiles (apparently successfully) with  MagickSlicer. bigmap.dzi :
<?xml version="1.0"?>
<Image TileSize="256" Overlap="0" Format="jpg" xmlns="http://schemas.microsoft.com/deepzoom/2008">
<Size Width="4000" Height="4000"/>
</Image>

When I replace the viewer with
var viewer = OpenSeadragon({
    id: "openseadragon1",
    prefixUrl: "./seadragon/images/",
    tileSources: "./tile_source/bigmap.dzi"
});

I get  "Unable to open [object Object]: Unable to load TileSource"
DevTools Console shows
Access to XMLHttpRequest at 'file:///home/iain/Data/iain/doxeyca/www/tile_source/bigmap.dzi' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

tilesource.js:692 No TileSource was able to open ./tile_source/bigmap.dzi #document

tile_source/bigmap.dzi:1 Failed to load resource: net::ERR_FAILED
```

Where should I be looking ?

(as you can probably tell my js knowledge is very limited)
thanks

[I've edited your comments to fix the code blocks, using ```.]
It looks like you're running your web page directly from your file system without starting a local web server. You're likely to run into a number of issues doing that. See the note at the bottom of this page:
http://openseadragon.github.io/docs/
I'd recommend getting that sorted out first.
Another thing you might try is changing the dzi extension to xml; OSD expects either (and DZI is just a specialized XML), but some servers know what to do with XML better.

authors: iainrs iangilman

repo: openseadragon/openseadragon


text:
No image loads and 304 not modified

I am having trouble getting images to display with OpenSeadragon. Logs indicate that the correct path is being found, as it finds the first couple tiles (but gives a 304 not modified). No controls are visible.
If I change the tileSources path to something that does not exist,  I get controls, but of course a 404 error as well).
<!DOCTYPE html>

        <meta charset="utf-8">

Under construction

{% include "footer.jinja2" %}

The output from my wsgi server:
127.0.0.1 - - [26/May/2023 04:23:23] "GET /static/openseadragon/images/next_grouphover.png HTTP/1.1" 304 -
127.0.0.1 - - [26/May/2023 04:23:23] "GET /static/openseadragon/images/next_pressed.png HTTP/1.1" 304 -
127.0.0.1 - - [26/May/2023 04:23:23] "GET /static/dzi2/onion_tonecurves.dzi HTTP/1.1" 304 -
127.0.0.1 - - [26/May/2023 04:23:23] "GET /static/dzi2/onion_tonecurves_files/2/0_0.jpeg HTTP/1.1" 304 -

Why might the image not be loading and is the 304 even related?

I don't know... I'm not aware of there being an issue with 304 results. Is it possible for you to try giving the correct URL to avoid the 304, just to see if that makes a difference?

What do you mean by the "correct url"? If it found any of the files in subdirectories, I assume it to have gotten the correct url. Am I missing something?

Nevermind, I think I have it sorted out. I just didn't realize that I had to explicitly define a size for the viewer in the css style.
#openseadragon1 {
  width: 100vw;
  height: 100vh;
}

in my main.css did the trick.

Oh yes... A common gotcha! Glad you got it sorted out. :)

Oh yes... A common gotcha! Glad you got it sorted out. :)

Something for the to-be-created FAQ maybe? Or perhaps a viewer with unreasonably small actual dimensions could be detected and throw a console warning? I've been using OSD for years and this still trips me up sometimes when I'm using different CSS layouts than I'm used to!

Yeah, an FAQ would probably be a good idea! Hmm... Looks like we already had an issue for that over in the site-build repository, but now I've made a new one here: https://github.com/openseadragon/openseadragon/issues/2368
But yeah, I think it would be even better if the app could warn you via the console, since not everyone is going to read the FAQ. That said, I'm concerned that in some cases, it would be normal operation for the viewer to have 0 size, for instance if it gets hidden sometimes. We'd want the warning to not happen in those cases. I'm not sure how best to detect that.

Another good place to mention this would be on the starting page of the docs (https://openseadragon.github.io/docs/). The example there does include sizing for the div, but it's not explicitly called out.

authors: iangilman jbhanks pearcetm


text:
Built-in support for German words decompounder

name
about
title
labels
assignees

💭 Proposal
Better support for German words decompounder
[PROPOSAL]
proposal

What kind of business use case are you trying to solve? What are your requirements?
We would like to have an out-of-the-box solution for German words decompounder, where OpenSearch have some analyzer that we can simply use it, similar to the level of support that Japanese as a language has (with kuromoji analysis plugin).
What is the problem? What is preventing you from meeting the requirements?
Many German words are actually a combination of shorter words, for example Fallschirmspringerschule (Skydiving school) = Fallschirm (parachute) + spring (jump) + schule (school). To get good quality search results, we need a decompounder to "break" words into components, to search by each individual word.
Currently, there is some support for Germanic language decompounder in Lucene and OpenSearch (for example, documentation taken from Elasticsearch https://www.elastic.co/guide/en/elasticsearch/reference/7.9/analysis-hyp-decomp-tokenfilter.html and https://www.elastic.co/guide/en/elasticsearch/reference/7.9/analysis-dict-decomp-tokenfilter.html), however, we still need to find a good dictionary file to effectively use the token filters.
There are some effort to build such dictionary, for example, at https://github.com/uschindler/german-decompounder
Another effort to solve the same problem that we can find, is to write a prebuilt Trie into a plugin, for example, at https://github.com/jprante/elasticsearch-analysis-decompound
The problem attracts good level of interest, when searching on search engine. For example, in this SO post https://stackoverflow.com/questions/59595689/elasticsearch-handling-german-compound-words, both of the approaches above are mentioned.
I think a better language support for German will be beneficial for OpenSearch users. We will not need to reinvent the wheel or reconstruct/look for a dictionary (with questionable accuracy).
What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
I do not have any specific solution in mind.
What are your assumptions or prerequisites?
I assume that there is demand for such German decompounder token filter and users are not satisfied with existing solution (or not being able to install plugin onto OpenSearch)
What are remaining open questions?

search/index latency implication of different approaches
"quality" of the solution, i.e. will it work for most of the German words?

Hi team, is there any guidance/suggestion for this issue? Should I start working on some PR for this?

Hi team, is there any guidance/suggestion for this issue? Should I start working on some PR for this?

No need to ask for permission! Comment here if you're working on it so we don't duplicate work.

Hi @quangmaubach, are you still working on this?

authors: anasalkouz dblock quangmaubach

repo: opensearch-project/OpenSearch


text:
[Zone Decommission] Abdicating the cluster manager if in decommissioned zone

Design Proposal
https://github.com/opensearch-project/OpenSearch/issues/3402
Feature Proposal
https://github.com/opensearch-project/OpenSearch/issues/3917
Describe the solution you'd like
Abdicating the cluster manager if in decommissioned zone .
We can use voting exclusion for the same. Once new master takes over, we can remove  voting exclusion config.

Implemented as part of #4084

https://github.com/opensearch-project/OpenSearch/pull/4084

authors: Bukhtawar gbbafna imRishN


text:
Adding configurable connection count setting for S3 Sync Client

Description

Add configurable S3 plugin's  setting max_sync_connections for sync client's max connections.
Uses  existing setting connection_acquisition_timeout for sync client as well . Today it is only used in async client.

Related Issues
Resolves #12027

Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)
[ ] ~Public documentation issue/PR created~

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Code test coverage check not passing. Might need to add some more tests?

@gbbafna Why wasn't max_connections reused? What scenarios lead to needing two different settings?

@gbbafna Why wasn't max_connections reused? What scenarios lead to needing two different settings?

We use sync client for get, list , delete and put for smaller sized files. Whereas async client is only used for multipart upload.
The sync client would always be used in create shard, which we want to give dedicated connections. Else , it might wait much longer for connection, causing a node drop. That's why we have introduced dedicated connections for now.
As we move everything to asyn client, we will need to address the cluster state applier thread prioritisation work as well.

authors: dblock deshsidd gbbafna


text:
Moved Gradle check into OpenSearch repo

Signed-off-by: Owais Kazi owaiskazi19@gmail.com
Description
Moved gradle check from private jenkins instance to OpenSearch repo.
Sample run: https://github.com/owaiskazi19/OpenSearch/runs/4705950671?check_suite_focus=true
Issues Resolved
Part of https://github.com/opensearch-project/opensearch-build/issues/982
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Let's see if this actually succeeds on GHA. I was under the impression that it's too slow/takes too long.

1> [2021-12-08T02:47:40,694][INFO ][o.o.i.IndexingMemoryController] [testTranslogRecoveryWorksWithIMC] now throttling indexing for shard [[index][0]]: segment writing can't keep up
  1> [2021-12-08T02:47:41,087][INFO ][o.o.i.IndexingMemoryControllerTests] [testTranslogRecoveryWorksWithIMC] after test
  1> [2021-12-08T02:47:41,095][INFO ][o.o.i.IndexingMemoryControllerTests] [testNegativeMaxIndexBufferSize] before test
  1> [2021-12-08T02:47:41,097][INFO ][o.o.i.IndexingMemoryControllerTests] [testNegativeMaxIndexBufferSize] after test
  1> [2021-12-08T02:47:41,106][INFO ][o.o.i.IndexingMemoryControllerTests] [testShardAdditionAndRemoval] before test
  1> [2021-12-08T02:47:42,048][INFO ][o.o.i.IndexingMemoryControllerTests] [testShardAdditionAndRemoval] after test
  1> [2021-12-08T02:47:42,057][INFO ][o.o.i.IndexingMemoryControllerTests] [testSkipRefreshIfShardIsRefreshingAlready] before test
  1> [2021-12-08T02:47:42,277][INFO ][o.o.i.IndexingMemoryController] [testSkipRefreshIfShardIsRefreshingAlready] now throttling indexing for shard [[index][0]]: segment writing can't keep up
  1> [2021-12-08T02:47:52,284][INFO ][o.o.i.IndexingMemoryControllerTests] [testSkipRefreshIfShardIsRefreshingAlready] after test
         but: was <0L>
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
        at org.junit.Assert.assertThat(Assert.java:956)
  1> [2021-12-08T02:48:22,319][INFO ][o.o.i.IndexingMemoryControllerTests] [testActiveInactive] before test
  1> [2021-12-08T02:48:24,029][INFO ][o.o.i.IndexingMemoryController] [testActiveInactive] now throttling indexing for shard [[index][0]]: segment writing can't keep up
  1> [2021-12-08T02:48:24,048][INFO ][o.o.i.IndexingMemoryControllerTests] [testActiveInactive] after test
        at org.junit.Assert.assertThat(Assert.java:923)
        at org.opensearch.indices.IndexingMemoryControllerTests.lambda$testSkipRefreshIfShardIsRefreshingAlready$6(IndexingMemoryControllerTests.java:490)
        at org.opensearch.test.OpenSearchTestCase.assertBusy(OpenSearchTestCase.java:1048)
        at org.opensearch.test.OpenSearchTestCase.assertBusy(OpenSearchTestCase.java:1021)
        at org.opensearch.indices.IndexingMemoryControllerTests.testSkipRefreshIfShardIsRefreshingAlready(IndexingMemoryControllerTests.java:488)

This is similar to what I saw before, not sure if disabling or fixing or rewriting these tests is the thing to do.

Let's see if this actually succeeds on GHA. I was under the impression that it's too slow/takes too long. What are the time differences?

The time it took is almost the same as Jenkins run but for a failed build.

Let's see if this actually succeeds on GHA. I was under the impression that it's too slow/takes too long. What are the time differences?

The time it took is almost the same as Jenkins run but for a failed build.

I remembered previously @Rishikesh1159 did some experiments to run gradle check through Github Actions, the whole check took 120 minutes in the GitHub hosted machines.

Let's see if this actually succeeds on GHA. I was under the impression that it's too slow/takes too long. What are the time differences?

The time it took is almost the same as Jenkins run but for a failed build.

I remembered previously @Rishikesh1159 did some experiments to run gradle check through Github Actions, the whole check took 120 minutes in the GitHub hosted machines.

It's worth trying harder this time and seeing whether it's because some timeouts are being hit causing retries, or something else. Ideally we'd use GHA for gradle checks.

Having gradle check in the open would bring in:

Community can see whats going on and how the code is tested.
No more maintaining Jenkins infrastructure for PR checks.
We can report code coverage to codecov.io.

For next steps, I would:

comment out the tests which are failing and iterate forward to make it run successfully on Github Actions.
start understanding why those tests are failing, I dont see a difference between github runner vs Jenkins runners. Probably more beefy instances.
If needed we could provide our infrastructure for github to run these checks.
Ref: https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners

@saratvemulapalli hosted runners inside AWS infra are a non-starter, this has been explored plenty - there are alternatives to GHA but they aren't better than our Jenkins instance otherwise

@saratvemulapalli hosted runners inside AWS infra are a non-starter, this has been explored plenty - there are alternatives to GHA but they aren't better than our Jenkins instance otherwise

Interesting, curious why though?

@saratvemulapalli hosted runners inside AWS infra are a non-starter, this has been explored plenty - there are alternatives to GHA but they aren't better than our Jenkins instance otherwise

Interesting, curious why though?

I don't have the detail, but I'll point you where to ask.
There's also https://github.com/aws-actions/aws-codebuild-run-build, which may be a better solution.

Let's see if this actually succeeds on GHA. I was under the impression that it's too slow/takes too long. What are the time differences?

The time it took is almost the same as Jenkins run but for a failed build.

I remembered previously @Rishikesh1159 did some experiments to run gradle check through Github Actions, the whole check took 120 minutes in the GitHub hosted machines.

When I tried to run gradle check on Github Actions, the rate of Random Test fails was higher compared to jenkins CI. This is because of slower machines Github Actions uses. There were couple integTests constantly failing.

@owaiskazi19 So this just works if we fix the timeouts/random failures?

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

Can we parallelize, get this down to ~1h?

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

Can we parallelize, get this down to ~1h?

I have it like ./gradlew check --parallel. Is there any other way to parallelize I should be looking into?

Also, I think we can get a better instance for GHA that would help to speed up the gradle check.

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

This is nice, do you know if all the tests (which are ignored on your fork) are flaky, and have issues opened ?

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

This is nice, do you know if all the tests (which are ignored on your fork) are flaky, and have issues opened ?

I might be missing few but for the most recent failures I have opened: https://github.com/opensearch-project/OpenSearch/issues/1852 and reopened: https://github.com/opensearch-project/OpenSearch/issues/39.

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

Can we parallelize, get this down to ~1h?

I have it like ./gradlew check --parallel for now. Is there any other way to parallelize I should be looking into?

I'm thinking multiple jobs across different kinds of tests. For example, If there's a way to generate a list of all the test tasks with gradle test:tasks, you could spawn GHA workflows for each of these tasks in parallel, see https://code.dblock.org/2021/09/03/generating-task-matrix-by-looping-over-repo-files-with-github-actions.html for an example.

@owaiskazi19 So this just works if we fix the timeouts/random failures?

Yeah, it does and takes around 180 mins if there's no flaky tests.

Can we parallelize, get this down to ~1h?

I have it like ./gradlew check --parallel for now. Is there any other way to parallelize I should be looking into?

I'm thinking multiple jobs across different kinds of tests. For example, If there's a way to generate a list of all the test tasks with gradle test:tasks, you could spawn GHA workflows for each of these tasks in parallel, see https://code.dblock.org/2021/09/03/generating-task-matrix-by-looping-over-repo-files-with-github-actions.html for an example.

The simplest I can think of is splitting BWC tests and the rest to start with. Because they take a lot of time to run on Jenkins too.
The rest would be unit and integration tests, if needed we should figure out how to split them up.


text:
[1.x] distribution/packages: Fix filename format for deb archives (#621)

Backport #621
This fixes the filename of the generated Debian package to follow the standard filename format similar to what dpkg itself would create.
Debian packages are formatted with the following filename structure:
name_[epoch:]version-release_arch.deb
Make generated Debian packages follow this convention.
Signed-off-by: Neal Gompa ngompa13@gmail.com
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

LGTM!

start gradle check

authors: abbashus setiah


text:
[Backport 2.13] add missing ctx variables (#710)

Description
Backport #710 to 2.13
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Closing in favor of: https://github.com/opensearch-project/common-utils/pull/719

repo: opensearch-project/common-utils


text:
FIX: missed exception in plugin error

Description
This PR fixes a miss in assigning pluginError with exception
Issues Resolved
Resolves #[Issue number to be closed when this PR is merged]
Check List

[ ] New functionality includes testing.
[ ] New functionality has a documentation issue. Please link to it in this PR.

[ ] New functionality has javadoc added

[ ] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@chenqi0805 , Should we backport this to 2.10?

@dlvenable Thanks for the reminder. I added the label

repo: opensearch-project/data-prepper


text:
[DOC] Create documentation for Client Side Encryption in OpenSearch

This is a placeholder for documentation addition/update that we will be required as part of https://github.com/opensearch-project/OpenSearch/issues/6353.
What do you want to do?

[ ] Request a change to existing documentation
[x] Add new documentation
[ ] Report a technical problem with the documentation
[ ] Other

Tell us about your request. Provide a summary of the request and all versions that are affected.
As part of feature proposal of Client Side Encryption in OpenSearch, this will assist in documentation of the same.
What other resources are available? Provide links to related issues, POCs, steps for testing, etc.

Closing since #2995 has been created.


text:
update delete model TransportAction to support custom model

Description
Delete all chunks in delete Model API for custom models.
DELETE _plugins/_ml/models/"model-ids"
{
"_index" : ".plugins-ml-model",
"_id" : "x95LqoMBr6prntZN5AQJ",
"_version" : 2,
"result" : "deleted",
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"_seq_no" : 37,
"_primary_term" : 7
}
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #462 (85f294f) into custom_model (c873946) will increase coverage by 0.16%.
The diff coverage is 93.20%.

@@                Coverage Diff                 @@
##             custom_model     #462      +/-   ##
==================================================
+ Coverage           91.43%   91.59%   +0.16%
- Complexity            528      618      +90
==================================================
  Files                  59       67       +8
  Lines                1529     1761     +232
  Branches              122      149      +27
==================================================
+ Hits                 1398     1613     +215
- Misses                 89       94       +5
- Partials               42       54      +12

Flag
Coverage Δ

ml-commons
91.59% <93.20%> (+0.16%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...java/org/opensearch/ml/rest/RestMLStatsAction.java
94.89% <ø> (-0.06%)
:arrow_down:

.../java/org/opensearch/ml/utils/RestActionUtils.java
86.84% <88.00%> (-6.50%)
:arrow_down:

...java/org/opensearch/ml/profile/MLProfileInput.java
89.28% <89.28%> (ø)

...main/java/org/opensearch/ml/utils/MLNodeUtils.java
92.30% <90.90%> (-7.70%)
:arrow_down:

...va/org/opensearch/ml/rest/RestMLProfileAction.java
93.33% <93.33%> (ø)

...pensearch/ml/action/profile/MLProfileResponse.java
94.73% <94.73%> (ø)

...earch/ml/action/profile/MLProfileNodeResponse.java
95.23% <95.23%> (ø)

...ch/ml/action/profile/MLProfileTransportAction.java
95.65% <95.65%> (ø)

...h/ml/action/models/DeleteModelTransportAction.java
97.61% <95.83%> (-2.39%)
:arrow_down:

.../opensearch/ml/action/profile/MLProfileAction.java
100.00% <100.00%> (ø)

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

authors: Zhangxunmt codecov-commenter

repo: opensearch-project/ml-commons