Wrong content for Facebook share?

Hey there,
I have a mention, which is a share on Facebook with a text included. Somehow the content says "name" for the text instead of "text". Is this correct?
Example is:
{"author":{"name":"beyond tellerrand","photo":"https://graph.facebook.com/v2.2/181579715213817/picture?type=large","url":"https://www.facebook.com/181579715213817"},"published":"2016-01-05T12:59:40+00:00","name":"Help getting a better image of how people plan their journey to and for events. With a bit of luck you can also win a book for taking part. Thanks!","text":"shared this.","url":"https://www.facebook.com/181579715213817/posts/1019399561431824","type":"mention"}
Let me know if you need more input.
/marc

interesting! i'll take a look.
your Kirby webmention plugin fetches HTML from bridgy, so i'm curious how it converts it to that JSON. it looks like there was more processing than just parsing mf2. @bastianallgeier could you describe that?

bridgy log:
<IP_ADDRESS> - - [05/Jan/2016:05:11:31 -0800] "POST /_ah/queue/propagate HTTP/1.1" 200 84 "http://brid.gy/_ah/queue/poll" "AppEngine-Google; (+http://code.google.com/appengine)"

Params: NestedMultiDict([('response_key', u'aglzfmJy...')])
Source: Marc Thiele (Facebook)<PHONE_NUMBER>8413916, http://brid-gy.appspot.com/facebook/10152730008413916
Created by this poll: http://brid-gy.appspot.com/log?start_time=1451999428&key=aglzfmJyaWQtZ3lyIwsSDEZhY2Vib29rUGFnZSIRMTAxNTI3MzAwMDg0MTM5MTYM
Starting Response repost tag:facebook.com,2013:1019399561431824 https://www.facebook.com/181579715213817/posts/1019399561431824
Webmention from https://brid-gy.appspot.com/repost/facebook/10152730008413916/10154447849633916/1019399561431824 to http://marcthiele.com/notes/planning-event-trips
Sending...
Starting new HTTP connection (1): marcthiele.com
"GET /notes/planning-event-trips HTTP/1.1" 200 None
Starting new HTTP connection (1): marcthiele.com
"POST /webmention HTTP/1.1" 200 None
Sent! {'body': u'{"status":"success","code":200,"message":"Yay","data":202}', 'request': u'POST http://marcthiele.com/webmention (with source=https://brid-gy.appspot.com/repost/facebook/10152730008413916/10154447849633916/1019399561431824, target=http://marcthiele.com/notes/planning-event-trips)', 'http_status': 200}
Setting last_webmention_sent

here are the relevant parts of bridgy's mf2 HTML for that share:
https://brid-gy.appspot.com/repost/facebook/10152730008413916/10154447849633916/1019399561431824

  tag:facebook.com,2013:1019399561431824
...
  Help getting a better image of how people plan their journey to and for events. With a bit of luck you can also win a book for taking part. Thanks!

  shared this.

...

...so yes, you're absolutely right, we could include the text of the share in the content as opposed to "shared this" when there is text
cc @kylewm since he knows more about mf2 than me. think that would be ok?

(btw @bastianallgeier feel free to ignore my earlier question!)

Absolutely, I think it makes sense to switch p-name and e-content here.
The p-name could also be something more descriptive like "shared this and added a comment" or "shared this and said: ..."

researching this is a bit confusing so far. i haven't yet found anywhere we're doing anything wrong that would result in the HTML above.

handlers seems to correctly map /repost/facebook/10152730008413916/10154447849633916/1019399561431824 to granary's Facebook.get_share('10154447849633916', '10154447849633916', '1019399561431824')
that get_share call correctly fetches /1019399561431824 from the FB API, which returns this share object
facebook correctly converts FB API message to AS content
microformats2.object_to_json/html correctly propagate AS content in a share object into mf2 e-content

aha, found it, it's this code in bridgy's repost handler:
# webmention receivers don't want to see their own post in their
# comments, so remove content before rendering.
for key in 'content', 'attachments':
  if key in repost:
    del repost[key]

introduced in ebdca44828d192474acf6dda29fc704b2b0c3f82. so, to keep the spirit of that change, i guess we need to detect when the content is from the repost and not the original post, and not remove it then.

...easier said than done. @kylewm, any chance you remember the background to ebdca44828d192474acf6dda29fc704b2b0c3f82?
as data points, it looks like we currently omit AS content entirely for FB shares with no message, and here's example current AS content field that we generate for a retweet:
  "content": "RT @julien51: It takes years to make the most important decision of your life.",

It's that thing where marking up reposts is tricky -- do we err on the side of making consumption easier for readers (where the "content" of the "share" object should at least be "shared a post by @\julien51" or maybe even include the content of the shared post "RT @\julien51 ..."), or do we make it easier for webmention receivers (who just want to see "shared this." or maybe "shared this and said: ..."?)
Likes have a similar but less dramatic problem; is the name "liked a post by so-and-so" or "liked this"?
The RepostHandler is one place where it makes sense to do the latter because it's only ever being seen by webmention receivers. And deleting content was probably the expedient way to do that at the time. I don't think the changes I made for quote tweets would affect it.
Maybe we want microformats2.render_content to have a parameter for who the intended recipient is? And then RepostHandler would tell it to render the content for a webmention receiver... Not ideal.

great point about how rendering is consumer specific, i hadn't thought about it that way before.
i agree that an intended consumer arg is maybe a bit clunky. what if we framed it instead as whether to synthesize content or not? if true, we do what we do now; false, we only include content explicitly authored by the activity's actor. in practice i think this would only be messages in FB/G+ shares and maybe FB RSVPs, and maybe similar things in Flickr that I'm not familiar with.

Hmm, what do we actually want the property values to be for the above example? name = "shared this." and content = "Help getting a better image of how people plan... etc"?
I think it could also make sense for name = content = "shared this and said, "Help getting a better image of how people plan... etc"" or something along those lines

for this example, if synthetic_content=False (or whatever we call it), i think we'd actually leave both content and name as exactly what the author entered: ""Help getting a better image...".
If synthetic_content=True - which i think is what you're asking? - then your second suggestion sounds good to me: 'shared this and said, "Help getting a better image...' or anything along those lines.

I hate to say it but shouldn't we handle quote tweets and facebook shares with commentary the same? Quote tweets were simply a mention with the original in an h-cite (that'd be similar to just always doing  the synthetic_content=False suggestion).

sure! i still don't think everyone agrees on whether quote tweets are reposts or replies or something else yet, but sure, once we've settled on what we want here, we could definitely include them.

It might be interesting to discuss in channel again at some point. I have a feeling people have a firmer idea of the semantics of an FB Share than a Quote Tweet.

sure! we could also maybe not block on quote tweets in the meantime. if we're OK with this proposal for FB shares and other unambiguous reposts, we could move ahead with it.

Hmm, sorry I don't think I was being very clear. I'm not trying to block at all, more I was saying "we've already litigated the markup for quote tweets, so let's just use that same thing for FB reposts-with-comment". In which case the markup is unambiguously

Help getting a better image...

And there's no need to complicate things with a syntethic_content switch

oh! i see. I'm not convinced though. FB shares seen to be reposts much more clearly. I'm not sure I'd want to denote then to mentions.

that's exactly how I felt about quote tweets! except you're right that the case for FB shares being reposts is stronger (e.g., bc they are included in the count of "shares"). so you won't get any argument from me. I really don't feel strongly either way though. sorry for dragging this out, I'm done now :speak_no_evil:

we've discussed this a bit on IRC, but just for the record, one side effect of this is that webmention receivers that don't special case likes and reposts now show blank webmentions for them since they don't have built in content any more. :( e.g. http://marcthiele.com/notes/atomic-design-book

True. Already recognised this. Just did not find the time to work on this. Going to sort Facebook likes and Twitter favourites under one category (you can use the given link structure to do this) and mentions with "content" (text) under mentions.


Missing icons

After following installation process as documented in README.md, after accessing the dashboard, you can notice that icons on the top bar and sidebar navigation are missing.

Dupe of #1


GitHub Copilot Can Not Install

VS Code Version: 1.76.2
OS Version: MacOs 13.6
Logs: Can't install 'github.copilot-chat' extension because it is not compatible with the current version of Visual Studio Code (version 1.76.2).

Steps to Reproduce:

I want to install copilot (not copilot chat)
it shows Can't install 'github.copilot-chat' extension because it is not compatible with the current version of Visual Studio Code (version 1.76.2).

Can anyone help to install copilot

I upgrade vscode version to fix this problem


Re-check Authentication button for Providers in the GTL view

Purpose or Intent
In https://github.com/ManageIQ/manageiq/pull/8912, a Re-check Authentication button was added for providers in the Provider detail page (Summary screen).
This PR is an extension to the above PR, in the sense, it implements the Re-check Authentication button in the GTL view so that multiple providers can be selected at a given time in order to re-check (and save) their authentication status.
This PR is also darga specific, meaning, middleware is deliberately left out here.
A separate PR for middleware would be created (for upstream), once this one gets merged.
Fixes https://github.com/ManageIQ/manageiq/issues/9632

@miq-bot add_label darga/yes

Darga cherry-pick merge conflict:
$ git cherry-pick -x -m 1  1cf14a1
error: could not apply 1cf14a1... Merge pull request #10609 from AparnaKarve/recheck_auth_in_gtl
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

$ git status
On branch darga
Your branch is up-to-date with 'upstream/darga'.
You are currently cherry-picking commit 1cf14a1.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:

        modified:   app/helpers/application_helper/toolbar/ems_clouds_center.rb
        modified:   app/helpers/application_helper/toolbar/ems_containers_center.rb
        modified:   app/helpers/application_helper/toolbar/ems_infras_center.rb

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   app/controllers/ems_common.rb

$ git diff
diff --cc app/controllers/ems_common.rb
index 5f59f65,9b0e3b0..0000000
--- a/app/controllers/ems_common.rb
+++ b/app/controllers/ems_common.rb
@@@ -431,23 -453,31 +431,41 @@@ module EmsCommo
          return
        end
        if params[:pressed] == "refresh_server_summary"
 -        javascript_redirect :back
 +        render :update do |page|
 +          page << javascript_prologue
 +          page.redirect_to  :back
 +        end
          return
        end
 -      if params[:pressed] == "ems_cloud_recheck_auth_status"     ||
 -         params[:pressed] == "ems_infra_recheck_auth_status"     ||
 -         params[:pressed] == "ems_middleware_recheck_auth_status" ||
 +      if params[:pressed] == "ems_cloud_recheck_auth_status" ||
 +         params[:pressed] == "ems_infra_recheck_auth_status" ||
           params[:pressed] == "ems_container_recheck_auth_status"
++<<<<<<< HEAD
 +        @record = find_by_id_filtered(model, params[:id])
 +        result, details = @record.authentication_check_types_queue(@record.authentication_for_summary.pluck(:authtype),
 +                                                                   :save => true)
 +        if result
 +          add_flash(_("Authentication status will be saved and workers will be restarted for this #{ui_lookup(:table => controller_name)}"))
++=======
+         if params[:id]
+           table_key = :table
+           _result, details = recheck_authentication
+           add_flash(_("Re-checking Authentication status for this %{controller_name} was not successful: %{details}") %
+                         {:controller_name => ui_lookup(:table => controller_name), :details => details}, :error) if details
++>>>>>>> 1cf14a1... Merge pull request #10609 from AparnaKarve/recheck_auth_in_gtl
          else
-           add_flash(_("Re-checking Authentication status for this #{ui_lookup(:table => "ems_cloud")} was not successful: %{details}") % {:details => details}, :error)
+           table_key = :tables
+           ems_ids = find_checked_items
+           ems_ids.each do |ems_id|
+             _result, details = recheck_authentication(ems_id)
+             add_flash(_("Re-checking Authentication status for the selected %{controller_name} %{name} was not successful: %{details}") %
+                           {:controller_name => ui_lookup(:table => controller_name),
+                            :name            => @record.name,
+                            :details         => details}, :error) if details
+           end
          end
+         add_flash(_("Authentication status will be saved and workers will be restarted for the selected %{controller_name}") %
+                       {:controller_name => ui_lookup(table_key => controller_name)})
          render_flash
          return
        end
@@@ -477,6 -504,22 +495,25 @@@
      end
    end

++<<<<<<< HEAD
++=======
+   def recheck_authentication(id = nil)
+     @record = find_by_id_filtered(model, id || params[:id])
+     @record.authentication_check_types_queue(@record.authentication_for_summary.pluck(:authtype), :save => true)
+   end
+
+   def arbitration_profile_edit
+     assert_privileges("arbitration_profile_edit")
+     id = params[:show] ? params[:show] : find_checked_items.first
+     # rubocop:disable LineLength
+     @arbitration_profile = id ? find_by_id_filtered(ArbitrationProfile, from_cid(id)) : ArbitrationProfile.new
+     @refresh_partial = "arbitration_profile_edit"
+     @redirect_id = @arbitration_profile.try(:id) || nil
+     @in_a_form = true
+     @title = _("Arbitration Profiles")
+   end
+
++>>>>>>> 1cf14a1... Merge pull request #10609 from AparnaKarve/recheck_auth_in_gtl
    def provider_documentation_url
      "http://manageiq.org/documentation/getting-started/#adding-a-provider"
    end

Backported to Darga via #10719
$ git log
commit a61b952759339e0b771ad9c89c33f3bc58ff3153
Merge: 5ed3060 4150e83
Author: Oleg Barenboim<EMAIL_ADDRESS>Date:   Wed Aug 24 09:14:11 2016 -0400

    Merge pull request #10719 from AparnaKarve/darga_recheck_auth_in_gtl

    [DARGA] Re-check Authentication button for Providers in the GTL view

https://bugzilla.redhat.com/show_bug.cgi?id=1375329


feat(ComponentDocs): support experimental.md

Fixes #519.
Changelog
New

experimental prop support in <ComponentDocs>, which attempts to bring in experimental.md if it exists

Thank you for reviewing @alisonjoseph! What is the Storybook thing BTW...?


Combine disclaimer with chart footer

Combine disclaimer with chart footer for positive test rate.

 Positive Test Rate graph summary (Location page below the fold)


Settle on Py_ssize_t type and sys.maxsize value

The sys.maxsize constant defines the maximal value of the Py_ssize_t type, which is a type for indexing collections (and thus, it is the theoretical maximal size of given Python implementation collections).
CPython defines Py_ssize_t as C ssize_t (signed int of the machine’s pointer size, equivalent to Rust isize). And justifies the use of signed type in the PEP-353 with two reasons:

Python allows negative indexes in many contexts anyway (so using isize makes arithmetic on indices easier – but nothing that can’t be done with BigInts and usize anyway),
the CPython codebase has many places where it depends on indexing variable being signed (for loops checking the variable being non-negative, possibly also some error handling by returning -1) – this does not concern RustPython in any way.

At the moment, RustPython defines sys.maxsize as the maximal value of usize:
ctx.set_attr(&sys_mod, "maxsize", ctx.new_int(std::usize::MAX));

and documents it as ‘the largest supported length of containers’.
But at the same time, it starts to use isize for maximal size of containers. At the moment list.insert() checks if the index fits in isize.
Using usize sounds like it makes sense because that is what Rust expects for vector indexing (so all indices must be cast to it eventually), but apparently Rust Vec will panic anyway if you try to grow it over isize::MAX bytes (because Rust has no way to allocate more as a single chunk of memory) – on the other hand it lets you get usize::MAX-long vectors of 0-bytes sized values (but those afaik have no use in RustPython).
And using isize would probably make it easier to eventually implement the Python C API (eg. PyList_Size() function) and C-based FFI.
I think RustPython should settle on either usize or isize (and for the sake of interoperability, and because of technical limitations, probably isize, even though I personally like usize more and find it cleaner) as the underlying indexing type, and raise OverflowErrors in collection functions when indices cannot be converted to isize and perhaps when growing a collection to more than isize::MAX elements (hmm, is it even possible? wouldn’t that panic earlier because of unsuccessful allocation anyway?).
Perhaps adding an alias like type PySize = isize (or PySsize, or PySSize) and using that instead of isize directly would also make sense?
Sorry for a wall of text…

Good explanation! I have no strong preference on this topic. Probably it is best to stick to the cpython way. What do pypy and micropython do?

What do pypy and micropython do?

MicroPython uses ssize_t's max or any equivalent form (Direct 0x7fff...)

fixed by #1124


RSA signature is invalid if Parameters omitted for DigestInfo::digestAlgorithm.parameters

I've got two RSA PKCS1 v1.5 signatures. BouncyCastle verifies them successfully. But OpenSSL returns false for a signature where algorithm identifier parameters omitted.
https://github.com/openssl/openssl/blob/8020d79b4033400d0ef659a361c05b6902944042/crypto/rsa/rsa_sign.c#L425-L429
As I can see from the source code OpenSSL encodes computed data digest and compares it with decrypted signature. That's why encoded data has Null parameters, but decrypted doesn't.
Decripted signature: MDEwDQYJYIZIAWUDBAIBBQAEIBNRk05odUAkFkvUI9130m39UwewnTYlDalQ7Tz5duXF
SEQUENCE (2 elem)
  SEQUENCE (1 elem)
    OBJECT IDENTIFIER 2.16.8<IP_ADDRESS>.4.2.1 sha-256 (NIST Algorithm)
  OCTET STRING (32 byte) 1351934E68754024164BD423DD77D26DFD5307B09D36250DA950ED3CF976E5C5

Decripted signature: MDEwDQYJYIZIAWUDBAIBBQAEIBNRk05odUAkFkvUI9130m39UwewnTYlDalQ7Tz5duXF
SEQUENCE (2 elem)
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 2.16.8<IP_ADDRESS>.4.2.1 sha-256 (NIST Algorithm)
    NULL
  OCTET STRING (32 byte) 1351934E68754024164BD423DD77D26DFD5307B09D36250DA950ED3CF976E5C5

Incoming data for testing
Data(HEX): 4d65737361676520746f207369676e
Public Key:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnA9e7rbX5VnoRSu/PXkW
cHitjac5Vv9sO0BcJqDGG13RLQXeiaLlyOYr88qzJ1hCOOifal++zA5AsU3dL7b0
Scb4Q1JdHXK0crgDJNTxEZOaKDWaIAJwNMuvPYmIX3tSG/nIrOlNiv2zut3NiNfv
A//l5kwzQDYhpDkdFSa7CK4Pp/p3+Wv2dkJiyxJDQmSiOKFHvSNW4OKFoI5Xk4Gj
YXVNGrXaqKIGbgHl3RH7wxgUOFWt5ZN+Y6mfa1IqBh04Qwnq/bDgq+626bx3u/uv
zuR7P6GLMv96PIEGVq+ESzpGFxEjOtRoHf4NRUASxBn5XBhZg59XoStTfiJwqDLf
vQIDAQAB
-----END PUBLIC KEY-----

Signature 1 (HEX):
7e494f2bcfd319a97b2a4b41d9245bf5497567e8075cebe46b4fa4a11a03257a555266e9aed5e85566c4386ebf5da1bd9162bac1b96ae6445f45fead88d5ee5cc1d25e2bf671703082fb17c56bd87866ead3f4a5b5096c857d704c13dccef8f27e22bda4dd3b9889f38dbd1894b1618dc7c781ade2356c72b99b6f175561bd2ef9832cbe2f5933cd5b043104083e6d78431351c015f398f845a5a2a1ada37ce5b411eebd9e47a809a84c990592b4189be83cecf47b715d1a0766cd3b0f5131fda88a013321752c7d41e76fd9d3db8c7cf1a9928cfdfe8ba26dfba30fbef3dfde11429b2e607e32bc17016e3303defe2a34c8c43469bfedd8eedf459d76c6e19c

Signature 2 (HEX):
5853ccac1b74b90bda0771e60e93cd21c3887d35ef96aa5ef2356629c9f286d956322b2e25ba9771c9aa73eda5ae690ac58309bf34c7583c5c16de0b2845600042f4ecd190e03060449bb6f7231ddf28d159e078433dbf7a23426de6f41d5eb65c87d98c4d6f239d4104ed35402fa38eb3de6955dbe95c0fdeba9d2fef9423704033d8514174206a2952b7b2b8fc1e2d95ea12912c96d7130fed7385deb0a9a32840db1e6f933386fbd0458350905359ba6053de7e4d43d7a79f066c7be42a701c797e463cc317a430da0c382235433ef8c8ce8ff083d6b1ec70ca86837c54fba543ba0be23997310fe98aaf020ff4f815646291a81588e31dd5d54fa80fb4a1

The one without NULL is invalid. RFC8017 is pretty clear on this. The verification algorithm is expressed in terms of encoding the expected output, EM', and then comparing it with the actual output, EM. (It does later say decoding it is a valid implementation strategy, but you would need to produce the same output as the reference algorithm, so that doesn't change things. Decoding it is also a more dangerous method, as, done laxly, it can admit attacks like this one.)
https://tools.ietf.org/html/rfc8017#section-8.2.2
That means there is one and only one input that is valid. The one that is valid is the one with the NULL, as noted in the appendix here:
https://tools.ietf.org/html/rfc8017#appendix-A.2.4
Where did the other signature come from? Whatever software is producing it should be fixed.

@davidben Thank you for the answer. I think that issue can be closed


Build issue on aarch64 Macos

Hi! I'm not sure if this is at all related to this crate, but I wanted to see if you had any thoughts about it either way. I'm seeing a new error, even though I don't think I've changed anything, here's the error
error: linking with `/nix/store/xzhppl1kydagd12hpymdr077in85015c-clang-wrapper-16.0.6/bin/cc` failed: exit status: 1
  |
  = note: env -u IPHONEOS_DEPLOYMENT_TARGET -u TVOS_DEPLOYMENT_TARGET LC_ALL="C" PATH="/nix/store/v1d55z24gf9lm1rawy2g8nfbg558y7r2-rust-nightly-com>
  = note: Undefined symbols for architecture arm64:
            "_nvim_buf_del_keymap", referenced from:
                nvim_oxi_api::buffer::Buffer::del_keymap::hd9f8542644d643b4 in libnvim_oxi_api-1810259784ad2574.rlib(nvim_oxi_api-1810259784ad2574.>
            "_nvim_set_keymap", referenced from:
                nvim_oxi_api::vim::set_keymap::h8728ff711adbca21 in libnvim_oxi_api-1810259784ad2574.rlib(nvim_oxi_api-1810259784ad2574.nvim_oxi_ap>
            "_luv_loop", referenced from:
                nvim_oxi_libuv::loop::init::h1cf99579f43be02f in libnvim_oxi_libuv-53f5f9439c8e56aa.rlib(nvim_oxi_libuv-53f5f9439c8e56aa.nvim_oxi_l>
            "_nvim_buf_set_keymap", referenced from:
                nvim_oxi_api::buffer::Buffer::set_keymap::h59fbaafc7f1c8fdf in libnvim_oxi_api-1810259784ad2574.rlib(nvim_oxi_api-1810259784ad2574.>
            "_nvim_notify", referenced from:
                nvim_oxi_api::vim::notify::hf21af98bdd3e6a47 in libnvim_oxi_api-1810259784ad2574.rlib(nvim_oxi_api-1810259784ad2574.nvim_oxi_api.f2>
            "_nvim_get_keymap", referenced from:
                nvim_oxi_api::vim::get_keymap::h55874fd420b01b62 in libnvim_oxi_api-1810259784ad2574.rlib(nvim_oxi_api-1810259784ad2574.nvim_oxi_ap>
            "_nvim_get_current_buf", referenced from:
                nvim_oxi_api::vim::get_current_buf::hfd7904501a7c055c in libnvim_oxi_api-1810259784ad2574.rlib(nvim_oxi_api-1810259784ad2574.nvim_o>
            "_nvim_eval", referenced from:
                ned::lines::hda2f6019118f7760 in ned.ned.61793e39bdfed096-cgu.01.rcgu.o
            "_nvim_create_user_command", referenced from:
                nvim_oxi_api::command::create_user_command::hefe9569b023769ec in ned.ned.61793e39bdfed096-cgu.05.rcgu.o
            "_nvim_buf_get_lines", referenced from:
                ned::lines::hda2f6019118f7760 in ned.ned.61793e39bdfed096-cgu.01.rcgu.o
          ld: symbol(s) not found for architecture arm64
          clang-16: error: linker command failed with exit code 1 (use -v to see invocation)

and I'm using a flake for local dev
https://github.com/zdcthomas/ned/blob/cd4c9605b1b256c22aa63aff7d24119f0cbb6ca4/flake.nix#L1
I might be doing something super dumb, and I can definitely close if this is totally unrelated, but I thought I'd ask anyway.
Thanks!

Ok, I figure it out! For some reason cargo wasn't picking up the build flags to tell the compiler to use dynamic lookup for the nvim_* calls. In nix, I put the env var in the build step with
          RUSTFLAGS = [
            "-C link-arg=-undefined"
            "-C link-arg=dynamic_lookup"
          ];

Can you reproduce it on an x86 Mac? If not, it sounds like this could be a Cargo bug since those exact flags are already defined in the .cargo/config.toml file.


Add README note re: API stability.

This is a follow-up of a discussion that took place along PR #87.

:+1:


Refactoring configurators & Validate JSONSchema of default request config file.

[x] Refactoring: Split configurator logic to separate modules.
[x] JSON Schema validation for the DRC(default request config) file format.
[x] Unit test.

@kdh0102 @pigbug419 Many lines of this PR is related to the refactoring. Please take a look carefully just for files related to the deployment.

@pigbug419 Can you please review this PR again today?


[BUILD] -std=c++1? compiler flag v.s. non-standard alloca(3) usage

Describe the bug
-std=c++11 compiler flag is set in src/cmake/compiler.cmake,
whereas alloca(3) is used in various source codes.
For alloca(3), compiler built-in implementation should be used, but,
if -std= flag is set and forced to use certain standard language specification,
such non-standard buint-in alloca() may be hidden.
At least, it is happend on NetBSD with GCC.
To Reproduce
Steps to reproduce the behavior:

cmake
make
error in the link phase, "Warning: reference to the libc supplied alloca(3); this most likely will not work. Please use the compiler privided version of alloca(3), by supplying the appropriate compiler flags (e.g. not -std=c89).

Expected behavior
Not such warnings, GCC builtin alloca(3) is used.
Evidence
If -std=gnu++11 is used instead of -std=c++11, or include <stdlib.h> before alloca(3) usage, such warning will be disappeared.
Platform information:

OIIO branch/version: 1.8.15
OS: NetBSD 8.1
C++ compiler: gcc (nb3 20180905) 5.5.0
Any non-default build flags when you build OIIO:

Proposed https://github.com/OpenImageIO/oiio/pull/2367 as a way to fix and clean this up. This is just a patch for master branch. I might backport just the include to RB-2.0.

Yes, it resolve the issue absolutely!
In src/include/OpenImageIO/platform.h and src/include/OpenImageIO/sysutil.h
#ifdef __MINGW32__
#    include <malloc.h>  // for alloca
#endif

It might the approach to the issue on Windows.

My falut :( , remaining -std=gnu++11 flag for testing.
#include <cstdlib> only declare C standards, not including alloca.

The NetBSD man pages (https://netbsd.gw.com/cgi-bin/man-cgi?alloca+3+NetBSD-current) seems to indicate that stdlib is the right header to include. If this is not correct, do you know which one is? I'd like to avoid -std=gnu++11 because I don't know what other problems that will cause down the road, it's nonstandard.

It is right header for alloca, but comiler builtin alloca is disabled if -std=c++11, then libc compat alloca symbol will be picked up.

rewrite nonstandard alloca usage with C++ standard way --- right way but troublesome
use -std=gnu++11 nonstandard flag if compiler accept it because alloca is not in standard -- maybe side effect as you said
treat NetBSD as a special -- minimal changes

example minimal code changes for the last case (MinGW case already exists):
// for alloca
#ifdef __MINGW32__
#    include <malloc.h>
#elif defined(__NetBSD__) && defined(__GNUC__)
#  ifndef alloca
#    define alloca __builtin_alloca
#  endif
#endif

Other platforms may require another treatments, for example, it seems that AIX with IBM XL C/C++ require #pragma alloca:
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/m_bostechref/malloc.html#malloc__alloca

Amended #2367 to include this logic (more or less -- I use __builtin_alloca for all gcc now, which seems even safer).

This was fixed by #2367.


Added note on async stretch failover

Behavior change in RS3

Hi, Ned - same comment here on branding, plus you have "THis" instead of "This" in the first word of one of your paras. Thanks, LP

Done thanks
NP | PM
From: Liza Poggemeyer<EMAIL_ADDRESS>Sent: Tuesday, October 24, 2017 10:17 AM
To: MicrosoftDocs/windowsserverdocs<EMAIL_ADDRESS>Cc: Ned Pyle<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/windowsserverdocs] Added note on async stretch failover (#237)
Hi, Ned - same comment here on branding, plus you have "THis" instead of "This" in the first word of one of your paras. Thanks, LP
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fwindowsserverdocs%2Fpull%2F237%23issuecomment-339065433&data=02|01|nedpyle%40microsoft.com|4969113ed2994fda733a08d51b03127d|72f988bf86f141af91ab2d7cd011db47|1|0|636444622365998209&sdata=KWepupp37303barhjNOMx5mB%2FQ1fRgbURmeg2CfT8Fo%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FARndN6aZe1BFSb-d4D--7LmTUdotW6BBks5svhuagaJpZM4P_vE8&data=02|01|nedpyle%40microsoft.com|4969113ed2994fda733a08d51b03127d|72f988bf86f141af91ab2d7cd011db47|1|0|636444622365998209&sdata=XlS8EIKW9XIq2VK6ieA3VfSGu%2BVt0gLBuX4ibRpK6Ps%3D&reserved=0.


Automate newest projects - Resolves #141

This PR resolves #141.
GitHub repositories fetch filter:

type=sources
sort=created
direction=desc
per_page=100

Additional repositories filter:

name != '.github' (doesn't include Comcast.github.io)
has description
is not archived

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


Fix: Deletes scan jobs if their pods have been deleted and logs can't be c…

Fixes #873 and for other scan types which are not mentioned in this issue
The problem which is fixed in this PR is the following:
When a scan job creates the pod which handles scans, if this pod has been deleted before starboard parses the pod's logs, these jobs are never deleted which means when the max concurrent job setting is hit, part of this threshold is eaten up by jobs which never get deleted.
Signed-off-by: Joel Whittaker-Smith<EMAIL_ADDRESS>

Thank you for working on this enhancement @jw-s Overall the controllers code looks good to me.
The only thing I'm not comfortable with are integration tests that you wrote for "relatively rare" corner case when the operator's cache cannot catch up with K8s API Server state and parse logs.
What's more, I'm afraid that the integration tests might became flaky because we cannot reliably control Pods managed by JobController, which is part of K8s controller-manager. (See failed PR checks.)
To sum up, I'd just add unit tests whenever possible to keep integration (~ e2e) test nice and lean so we can afford running them on each PR. See this nice and detailed explanation why I think we should not validate everything at the integration tests phase martinfowler.com/articles/practical-test-pyramid.html.

Yeah I completely agree, this area is definitely flake provoking and i'm happy to remove these tests. Do we have an area where we can add unit tests to cover these cases? I couldn't seem to find it.

Thank you for working on this enhancement @jw-s Overall the controllers code looks good to me.
The only thing I'm not comfortable with are integration tests that you wrote for "relatively rare" corner case when the operator's cache cannot catch up with K8s API Server state and parse logs.
What's more, I'm afraid that the integration tests might became flaky because we cannot reliably control Pods managed by JobController, which is part of K8s controller-manager. (See failed PR checks.)
To sum up, I'd just add unit tests whenever possible to keep integration (~ e2e) test nice and lean so we can afford running them on each PR. See this nice and detailed explanation why I think we should not validate everything at the integration tests phase martinfowler.com/articles/practical-test-pyramid.html.

Yeah I completely agree, this area is definitely flake provoking and i'm happy to remove these tests (Though the failure is not because of a flake but actually something else). Do we have an area where we can add unit tests to cover these cases? I couldn't seem to find it.

We'd have to add _test.go files to implement unit tests for reconcilers. So far we only have integration tests for controllers. If this requires too much effort I'm also happy to approve this PR without very strict requirement for unit testing.


out of gas failure

add liquidity
https://kovan.etherscan.io/tx/0x1630dea31ad947965f8cc4130134c60e91d1b06d8f6bc333897d508bf9426936
buy
https://dashboard.tenderly.co/tx/kovan/0x5ee7f61e96dbe2d7f73343944327a16bc22fc691e26d367808060dacd1179462
Transactions are running out of gas, add liquidity and the buy tx.
Thoughts:

Is MM not estimating gas correctly?
Does the UI need to manually estimate gas?

@justinbarry
Are the above legit running out of gas and the estimate was low or is there run away logic?

Stale.


@/techlabblog mdxjs

Description
This PR standardise the use of mdxjs for all things markdown in @/techlabblog app from the current soupe of libraries.

[x] Same configuration is used in Next.js' next.config.mjs as in our own lib/data.
[x] Frontmatter and syntax highlighting uses recommendations from mdxjs.

Type of change

[x] Chore

Screenshots

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas

Happy to hear your thoughts @CodeForAfrica/tech before finalising the PR.

Any other feedback @CodeForAfrica/tech ? Happy with this direction?

🚀


Lazily evaluate variable references before parsing blocks.

Here is a basic Lakefile with some things places a bit out of order to help demonstrate our support of parsing things in dependency order:
store "busybox_store" {
  inputs = [install_script]
  shell  = ["${busybox_tar}/busybox-x86_64", "sh"]
  script = <<EOH
    ${busybox_tar}/busybox-x86_64 sh ${install_script}
  EOH
}

install_script = "./install.sh"

store "busybox_tar" {
  env     = { fetch_url = "true", url = "https://brmbl.s3.amazonaws.com/busybox-x86_64.tar.gz" }
  network = true
}

command "busybox" {
  shell  = ["${busybox_store}/bin/sh"]
  script = <<EOH
  PATH=$PATH:$busybox_store/bin
  sh $@
  EOH
}

In this file the two store blocks become the variables busybox_store and busybox_tar and the command becomes variable  busybox (not used anywhere). We also have a string variable called install_script.
Naively this hcl would be turned into the JSON below, you can see that the variable references still need to be expanded:
{
  "command": [
    {
      "busybox": [
        {
          "script": "  PATH=$PATH:$busybox_store/bin\n  sh $@\n  ",
          "shell": [
            "${busybox_store}/bin/sh"
          ]
        }
      ]
    }
  ],
  "install_script": "./install.sh",
  "store": [
    {
      "busybox_store": [
        {
          "inputs": [
            "${install_script}"
          ],
          "script": "    ${busybox_tar}/busybox-x86_64 sh ${install_script}\n  ",
          "shell": [
            "${busybox_tar}/busybox-x86_64",
            "sh"
          ]
        }
      ]
    },
    {
      "busybox_tar": [
        {
          "env": [
            {
              "fetch_url": "true",
              "url": "https://brmbl.s3.amazonaws.com/busybox-x86_64.tar.gz"
            }
          ],
          "network": true
        }
      ]
    }
  ]
}

We must assemble all variables, figure out what they reference, and then parse each block or variable reference as their values become available. In this example we can start with install_script and busybox_tar as they have no references and then proceed to busybox_store and then busybox.
In the Go implementation we

Grab the name from each block to use as the variable
Find variables referenced in each block and add them to a graph
Walk the graph and parse each block as it is availabel
As we parse we either add an evaluated attribute as a new variable that other things can reference or evaluate a block, turn it into a Recipe and then add the hash of that recipe into the variables as a has string

Then we're done!
So far, the work in rust has involved:

Breaking out each block and attribute and searching for variable references
Those variables are then added to a dag
Which we can then walk in topological order

We still need to:

[ ] Parse each block/attribute in the walk callback
[ ] Add each parsed block and attribute to the available variables
[ ] Construct each Recipe (some work on that has begun here)

Confused about where this task starts and end, does it encompass parts of these?

[ ] Turn store/command/file blocks into Recipe structs. Implement a hash algorithm for them and use their hash value as a string reference in Lakefiles.
[ ] For each Lakefile, return a map with variable references and their corresponding values.

Confused about where this task starts and end, does it encompass parts of these?

[ ] Turn store/command/file blocks into Recipe structs. Implement a hash algorithm for them and use their hash value as a string reference in Lakefiles.
[ ] For each Lakefile, return a map with variable references and their corresponding values.


Handle 404 Responses in Local Production Build

When the production build of the example OSCAL Viewer is served on localhost, refreshing any page, or navigating to any url besides localhost:port, (eg. localhost:5000/catalog) will cause a 404 response that shows an error page instead of the desired page.
Steps to Reproduce

build the production build with npm run build in the example directory
serve the production build to localhost
view the viewer in a browser
refresh the page

Acceptance Criteria
Pressing refresh when viewing the production build of the OSCAL Viewer refreshes the page instead of taking the user to an error page.
Navigating to any url in the production build of the Viewer acts as it would in the live demo.

This is likely due to Spring Boot not knowing about the URL paths that React re-writes, so we should be able to configure to configure Spring to direct those known path requests to the static resources.
We currently set the location of static resources through an environment variable in the Docker image.

There was a similar issue in CloudFront that was handled by transforming 404 errors from S3 into 200s pointing to /index.html.


Implement a Storage Subsystem based on CouchDB/PouchDB

Objective: Provide an alternative to Firebase for storing data.  A PouchDB solution can be run by a user on their own server or cloud provider.
The provided solution will offer functionality that provides:

A distribution of the static Arcs Runtime and Shell that can connect to
... an instance of the experimental pouchdb-server
... bundled into a Docker image.

In the future a production ready version of this solution would include full CouchDB installation.

This was implemented a while back.  Updates to Pouch will be filed as separate issues.


python312Packages.py-serializable: 1.1.1 -> 1.1.2

Diff: https://github.com/madpah/serializable/compare/refs/tags/v1.1.1...v1.1.2
Changelog: https://github.com/madpah/serializable/blob/v1.1.2/CHANGELOG.md

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

14 packages built:

checkov
checkov.dist
cyclonedx-python
cyclonedx-python.dist
pip-audit
pip-audit.dist
python311Packages.cyclonedx-python-lib
python311Packages.cyclonedx-python-lib.dist
python311Packages.py-serializable
python311Packages.py-serializable.dist
python312Packages.cyclonedx-python-lib
python312Packages.cyclonedx-python-lib.dist
python312Packages.py-serializable
python312Packages.py-serializable.dist


Fix engine.json location

According to the Spec, engine specification file must be in the root of FS.

Good catch! The package.json files should be in /usr/src/app though, so would you mind adjusting the PR so you're only moving the engine.json file, please?
Thank you for the contribution.

It goes into working directory(./) which is /usr/src/app.

Gah, I misread it this morning. Sorry about that!


1.1.0 OnBuild Error

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
kind bug
Description
Look ups of local images seems to be failing.
Steps to reproduce the issue:
# FILE=./Dockerfile
/bin/cat <<EOM >$FILE
FROM docker.io/library/alpine:latest
RUN touch /foo
ONBUILD RUN touch /bar
EOM
chmod +x $FILE

# FILE=./Dockerfile-2
/bin/cat <<EOM >$FILE
FROM onbuild-image
RUN touch /baz
EOM
chmod +x $FILE

# podman build -f ./Dockerfile --format=docker -t onbuild-image .
# podman build -f ./Dockerfile-2 --format=docker -t result-image .
STEP 1: FROM onbuild-image
Error: error creating build container: The following failures happened while trying to pull image specified by "onbuild-image" based on search registries in /etc/containers/registries.conf:
* "localhost/onbuild-image": Error determining manifest MIME type for docker://localhost/onbuild-image:latest: pinging docker registry returned: Get https://localhost/v2/: dial tcp [::1]:443: connect: connection refused
* "docker.io/library/onbuild-image": Error determining manifest MIME type for docker://onbuild-image:latest: Error reading manifest latest in docker.io/library/onbuild-image: errors:
denied: requested access to the resource is denied
unauthorized: authentication required

* "registry.fedoraproject.org/onbuild-image": Error determining manifest MIME type for docker://registry.fedoraproject.org/onbuild-image:latest: Error reading manifest latest in registry.fedoraproject.org/onbuild-image: manifest unknown: manifest unknown
* "quay.io/onbuild-image": Error determining manifest MIME type for docker://quay.io/onbuild-image:latest: Error reading manifest latest in quay.io/onbuild-image: error parsing HTTP 404 response body: invalid character '<' looking for beginning of value: "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>404 Not Found</title>\n
Not Found
\n
The requested URL was not found on the server.  If you entered the URL manually please check your spelling and try again.
\n"
* "registry.access.redhat.com/onbuild-image": Error determining manifest MIME type for docker://registry.access.redhat.com/onbuild-image:latest: Error reading manifest latest in registry.access.redhat.com/onbuild-image: unknown: Not Found
* "registry.centos.org/onbuild-image": Error determining manifest MIME type for docker://registry.centos.org/onbuild-image:latest: Error reading manifest latest in registry.centos.org/onbuild-image: manifest unknown: manifest unknown

Describe the results you received:
See steps to reproduce.
Describe the results you expected:
Happy image build.
Additional information you deem important (e.g. issue happens only occasionally):
This passes on the same VM with v1.0 installed.
Output of podman version:
# podman version
Version:       1.0.0
Go Version:    go1.11.4
Git Commit:    "49780a1cf10d572edc4e1ea3b8a8429ce391d47d"
Built:         Mon Jan 14 15:38:17 2019
OS/Arch:       linux/amd64

Output of podman info --debug:
# podman info --debug
debug:
  compiler: gc
  git commit: '"49780a1cf10d572edc4e1ea3b8a8429ce391d47d"'
  go version: go1.11.4
  podman version: 1.0.0
host:
  BuildahVersion: 1.6-dev
  Conmon:
    package: podman-1.0.0-1.git82e8011.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 49780a1cf10d572edc4e1ea3b8a8429ce391d47d'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree:<PHONE_NUMBER>
  MemTotal:<PHONE_NUMBER>
  OCIRuntime:
    package: runc-1.0.0-68.dev.git6635b4f.fc29.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: ef9132178ccc3d2775d4fb51f1e431f30cac1398-dirty
      spec: 1.0.1-dev
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 1
  hostname: localhost.localdomain
  kernel: 4.20.3-200.fc29.x86_64
  os: linux
  rootless: false
  uptime: 3h 22m 26.06s (Approximately 0.12 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
  ImageStore:
    number: 0
  RunRoot: /var/run/containers/storage

Additional environment details (AWS, VirtualBox, physical, etc.):

Hmmm, and this works with Buildah v1.7 released.

Could be the --pull-all default being changed

Sorry, --pull-always (--always-pull?)

And works on 1.8-dev which is at this point 1.7.1.

@mheon same error with --pull-always

Different vendored c/image than buildah? Running out of ideas here, there aren't many differences.

We've the same vendoring for c/image and c/storage....

Confirmed, I can reproduce locally

We're trying to pull onbuild-image and failing when we can't find it in registries (because it's not there).
This is 100% --pull-always - setting it to false fixes.
I think we need to change --pull-always to check locally if pulling from all sources fails.

@rhatdan It looks like this is going to break people trying to do a FROM with an image they tagged themselves

Ah, I tried setting it to true, not false.  Nice catch @mheon.

FWIW, I can confirm that this:
docker build -f ./Dockerfile -t onbuild-image .
docker build -f ./Dockerfile-2 -t result-image .

works, so I think we need to make it work again without the pull-always.

I think we need to refile this against Buildah and get a fix landed there and vendored here

My understanding is we wanted to turn on --pull not --pull-always.

@rhatdan We enabled --pull-always by default, so if that was a mistake, we need to fix it.
The reason was that we weren't pulling the latest version of the tag if it was present on disk, so we need to verify that --pull does that.

I'll take a look at this.


IMAP Agent causing strange UTF errors

Noticed for the second time that my agents were not running for a day or two, logged in to 10k+ jobs queued. Checking logs I find this:
Agent#48: Emitting an event for mail<EMAIL_ADDRESS>Agent#48: Connection closed
Agent#48: Exception during check: "\x99" from ASCII-8BIT to UTF-8 -- ["/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/core_ext/object/json.rb:34:in `encode'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/core_ext/object/json.rb:34:in `to_json'", "/
usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/core_ext/object/json.rb:34:in `to_json_with_active_support_encoder'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/json-1.8.1/lib/json/common.rb:223:in `generate'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/json-1.8.1/lib/json/common.rb:223:
in `generate'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/json-1.8.1/lib/json/common.rb:394:in `dump'", "/usr/local/huginn/lib/json_with_indifferent_access.rb:7:in `dump'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods/serialization.rb:105:in `serialize'", "/usr/loc
al/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods/serialization.rb:95:in `serialized_value'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods/serialization.rb:181:in `typecasted_attribute_value'", "/usr/local/rvm/gems/ruby-2.0.0-p
353/gems/activerecord-4.1.5/lib/active_record/attribute_methods.rb:433:in `block in arel_attributes_with_values'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods.rb:432:in `each'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribu
te_methods.rb:432:in `arel_attributes_with_values'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods.rb:412:in `arel_attributes_with_values_for_create'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/persistence.rb:500:in `_create_reco
rd'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods/dirty.rb:87:in `_create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/callbacks.rb:306:in `block in _create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesuppo
rt-4.1.5/lib/active_support/callbacks.rb:113:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:113:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `block in halting_and_conditional'", "/usr/local/
rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `block in halting_and_conditional'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/
callbacks.rb:215:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `block in halting_and_conditional'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gem
s/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `block in halting_and_conditional'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:215:in `block i
n halting_and_conditional'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:86:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:86:in `run_callbacks'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/
lib/active_record/callbacks.rb:306:in `_create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/timestamp.rb:57:in `_create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/persistence.rb:482:in `create_or_update'", "/usr/local/rvm/gems/
ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/callbacks.rb:302:in `block in create_or_update'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:113:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:113:i
n `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:166:in `block in halting'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:166:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_s
upport/callbacks.rb:166:in `block in halting'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:166:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:166:in `block in halting'", "/usr/local/rvm/gems/ruby-2.0.0-p353/
gems/activesupport-4.1.5/lib/active_support/callbacks.rb:86:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:86:in `run_callbacks'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/callbacks.rb:302:in `create_or_update'", "/usr/l
ocal/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/persistence.rb:125:in `save!'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/validations.rb:57:in `save!'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/attribute_methods/dirty.
rb:29:in `save!'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/transactions.rb:273:in `block in save!'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/transactions.rb:329:in `block in with_transaction_returning_status'", "/usr/local/rvm/gems/ruby-2.
0.0-p353/gems/activerecord-4.1.5/lib/active_record/connection_adapters/abstract/database_statements.rb:199:in `transaction'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/transactions.rb:208:in `transaction'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_r
ecord/transactions.rb:326:in `with_transaction_returning_status'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/transactions.rb:273:in `save!'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/associations/has_many_association.rb:38:in `insert_record'"
, "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:44:in `block (2 levels) in create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/associations/collection_association.rb:389:in `add_to_target'",
"/usr/local/rvm/gems/ruby-2.0.0-p353/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:42:in `block in create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/associations/collection_association.rb:168:in `block in transaction'", "/usr/
local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/connection_adapters/abstract/database_statements.rb:201:in `block in transaction'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/connection_adapters/abstract/database_statements.rb:209:in `within_new_transactio
n'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/connection_adapters/abstract/database_statements.rb:201:in `transaction'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.1.5/lib/active_record/transactions.rb:208:in `transaction'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gem
s/activerecord-4.1.5/lib/active_record/associations/collection_association.rb:167:in `transaction'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:41:in `create_record'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/protected_attributes-1
.0.8/lib/active_record/mass_assignment_security/associations.rb:30:in `create!'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:64:in `create!'", "/usr/local/huginn/app/models/agent.rb:103:in `create_event'", "/usr/local/huginn/app/mod
els/agents/imap_folder_agent.rb:296:in `block in check'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:384:in `block (3 levels) in each_unread_mail'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:383:in `each'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:383:in `block (2 leve
ls) in each_unread_mail'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:336:in `each'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:336:in `block in each_unread_mail'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:442:in `open'", "/usr/local/huginn/app/models/agents/imap_folde
r_agent.rb:325:in `each_unread_mail'", "/usr/local/huginn/app/models/agents/imap_folder_agent.rb:232:in `check'", "/usr/local/huginn/app/models/agent.rb:421:in `async_check'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/performable_method.rb:26:in `perform'", "/usr/local/rvm/gems/ruby-2.0
.0-p353/gems/delayed_job-4.0.2/lib/delayed/backend/base.rb:105:in `block in invoke_job'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `block in initialize'", "/usr/local/
rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `execute'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:38:in `run_callbacks'", "/usr/local/rvm/g
ems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/backend/base.rb:102:in `invoke_job'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:207:in `block (2 levels) in run'", "/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/timeout.rb:66:in `timeout'", "/usr/local/rvm/gems/rub
y-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:207:in `block in run'", "/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/benchmark.rb:296:in `realtime'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:206:in `run'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_j
ob-4.0.2/lib/delayed/worker.rb:274:in `block in reserve_and_run_one_job'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `block in initialize'", "/usr/local/rvm/gems/ruby-2
.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `execute'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:38:in `run_callbacks'", "/usr/local/rvm/gems/ruby-2.0.0-
p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:274:in `reserve_and_run_one_job'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:190:in `block in work_off'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:189:in `times'", "/usr/local/rvm/gems/r
uby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:189:in `work_off'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:154:in `block (4 levels) in start'", "/usr/local/rvm/rubies/ruby-2.0.0-p353/lib/ruby/2.0.0/benchmark.rb:296:in `realtime'", "/usr/local/rvm/gems/ruby-2.0.0
-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:153:in `block (3 levels) in start'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `block in initialize'", "/usr/local/rv
m/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `execute'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:38:in `run_callbacks'", "/usr/local/rvm/gem
s/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:152:in `block (2 levels) in start'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:151:in `loop'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/worker.rb:151:in `block in start'", "/usr/local
/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/plugins/clear_locks.rb:7:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/plugins/clear_locks.rb:7:in `block (2 levels) in <class:ClearLocks>'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/life
cycle.rb:78:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:78:in `block (2 levels) in add'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/li
fecycle.rb:60:in `block in initialize'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:78:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:78:in `block in add'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/dela
yed/lifecycle.rb:65:in `call'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in `execute'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:38:in `run_callbacks'", "/usr/local/rvm/gems/ruby-2.0.0-p353/gems/delayed_job-4.0.2/lib/delayed/w
orker.rb:150:in `start'", "bin/threaded.rb:46:in `block (2 levels) in <top (required)>'", "bin/threaded.rb:16:in `safely'", "bin/threaded.rb:43:in `block in <top (required)>'"]

happening every 2-3 seconds. Agent #48 is an IMAP agent with the following configuration:
{
  "expected_update_period_in_days": "1",
  "host": "imap.gmail.com",
  "ssl": true,
  "port": 993,
  "username": "<omitted>",
  "password": "<omitted>",
  "folders": [
    "INBOX"
  ],
  "conditions": {
  }
}

Removing the offending email from my inbox cleared the issue and allowed all queued up jobs to begin processing.
Running Huginn on master from commit<PHONE_NUMBER>3c383ba928694203c8b0039d2e6f27 which is a bit old (9/27)
This is the second time I have experienced an issue with malformed characters in the IMAP agent causing my entire installation to stop working and queue up pending jobs forever. I will make the suggestion that seems logical: we should treat incoming emails just as any other input; it is untrusted and could be Bad. Verifying/sanitizing/converting text to valid UTF before attempting to send it to a DB or function expecting valid UTF may be the solution

I'm getting this error with a heroku build from 2015-03-06.  Was this fix merged into the main branch or do I need to apply it manually?

It should have been merged.  Are you erroring in the same spot?

Yep, pretty sure.  Agent errors out with:
Exception during check. "\xB7" from ASCII-8BIT to UTF-8: /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/core_ext/object/json.rb:34:in encode' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/core_ext/object/json.rb:34:in to_json'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/core_ext/object/json.rb:34:in to_json_with_active_support_encoder' /app/vendor/bundle/ruby/2.0.0/gems/json-1.8.2/lib/json/common.rb:223:in generate'
/app/vendor/bundle/ruby/2.0.0/gems/json-1.8.2/lib/json/common.rb:223:in generate' /app/vendor/bundle/ruby/2.0.0/gems/json-1.8.2/lib/json/common.rb:394:in dump'
/app/lib/json_with_indifferent_access.rb:7:in dump' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods/serialization.rb:110:in serialize'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods/serialization.rb:100:in serialized_value' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods/serialization.rb:186:in typecasted_attribute_value'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods.rb:438:in block in arel_attributes_with_values' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods.rb:437:in each'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods.rb:437:in arel_attributes_with_values' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods.rb:417:in arel_attributes_with_values_for_create'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/persistence.rb:501:in _create_record' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods/dirty.rb:87:in _create_record'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/callbacks.rb:306:in block in _create_record' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:113:in call'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:113:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in block in halting_and_conditional'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in block in halting_and_conditional'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in block in halting_and_conditional'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in block in halting_and_conditional'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:215:in block in halting_and_conditional'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:86:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:86:in run_callbacks'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/callbacks.rb:306:in _create_record' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/timestamp.rb:57:in _create_record'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/persistence.rb:483:in create_or_update' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/callbacks.rb:302:in block in create_or_update'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:113:in call' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:113:in call'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:166:in block in halting' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:166:in call'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:166:in block in halting' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:166:in call'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:166:in block in halting' /app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:86:in call'
/app/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.8/lib/active_support/callbacks.rb:86:in run_callbacks' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/callbacks.rb:302:in create_or_update'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/persistence.rb:125:in save!' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/validations.rb:57:in save!'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/attribute_methods/dirty.rb:29:in save!' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/transactions.rb:273:in block in save!'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/transactions.rb:329:in block in with_transaction_returning_status' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/database_statements.rb:199:in transaction'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/transactions.rb:208:in transaction' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/transactions.rb:326:in with_transaction_returning_status'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/transactions.rb:273:in save!' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/associations/has_many_association.rb:38:in insert_record'
/app/vendor/bundle/ruby/2.0.0/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:44:in block (2 levels) in create_record' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/associations/collection_association.rb:389:in add_to_target'
/app/vendor/bundle/ruby/2.0.0/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:42:in block in create_record' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/associations/collection_association.rb:168:in block in transaction'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/database_statements.rb:201:in block in transaction' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/database_statements.rb:209:in within_new_transaction'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/connection_adapters/abstract/database_statements.rb:201:in transaction' /app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/transactions.rb:208:in transaction'
/app/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.8/lib/active_record/associations/collection_association.rb:167:in transaction' /app/vendor/bundle/ruby/2.0.0/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:41:in create_record'
/app/vendor/bundle/ruby/2.0.0/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:30:in create!' /app/vendor/bundle/ruby/2.0.0/gems/protected_attributes-1.0.8/lib/active_record/mass_assignment_security/associations.rb:64:in create!'
/app/app/models/agent.rb:107:in create_event' /app/app/models/agents/imap_folder_agent.rb:296:in block in check'
/app/app/models/agents/imap_folder_agent.rb:384:in block (3 levels) in each_unread_mail' /app/app/models/agents/imap_folder_agent.rb:383:in each'
/app/app/models/agents/imap_folder_agent.rb:383:in block (2 levels) in each_unread_mail' /app/app/models/agents/imap_folder_agent.rb:336:in each'
/app/app/models/agents/imap_folder_agent.rb:336:in block in each_unread_mail' /app/app/models/agents/imap_folder_agent.rb:442:in open'
/app/app/models/agents/imap_folder_agent.rb:325:in each_unread_mail' /app/app/models/agents/imap_folder_agent.rb:232:in check'
/app/app/models/agent.rb:425:in async_check' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/performable_method.rb:26:in perform'
/app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/backend/base.rb:105:in block in invoke_job' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in call'
/app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60:in block in initialize' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in call'
/app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:65:in execute' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:38:in run_callbacks'
/app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/backend/base.rb:102:in invoke_job' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/worker.rb:207:in block (2 levels) in run'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/timeout.rb:66:in timeout' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/worker.rb:207:in block in run'
/app/vendor/ruby-2.0.0/lib/ruby/2.0.0/benchmark.rb:296:in realtime' /app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/worker.rb:206:in run'
/app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/worker.rb:274:in `block in reserve_and_run_one_job'
/app/vendor/bundle/ruby/2.0.0/gems/delayed_job-4.0.2/lib/delayed/lifecycle.rb:60

On Mar 11, 2015, at 6:00 PM, Andrew Cantino<EMAIL_ADDRESS>wrote:
It should have been merged. Are you erroring in the same spot?
—
Reply to this email directly or view it on GitHub https://github.com/cantino/huginn/issues/613#issuecomment-78391503.

It looks like this is happening on models/agent.rb:107 in create_event when it tries to make a new Event.
You could try editing the imap_folder_agent.rb and changing line 296 to something like:
          create_event :payload => {
            'folder' => mail.folder,
            'subject' => mail.subject.encode('utf-8', invalid: :replace, undef: :replace, replace: '??'),
            'from' => mail.from_addrs.first,
            'to' => mail.to_addrs,
            'cc' => mail.cc_addrs,
            'date' => (mail.date.iso8601 rescue nil),
            'mime_type' => mime_type,
            'body' => body.encode('utf-8', invalid: :replace, undef: :replace, replace: '??'),
            'matches' => matches,
            'has_attachment' => mail.has_attachment?,
          }

Perhaps those .encode('utf-8', invalid: :replace, undef: :replace, replace: '??') will help.

That fixed it.  Thanks!

Any word on making this an official patch?  I'm seeing the same error a couple of times an hour.

@virtadpt, so this is still happening for you?  I was hoping that @knu's fix in https://github.com/cantino/huginn/commit/49eb43459db750b7a62319e1c0ea29ff404680ca would have fixed it.

Yup, still happening.

@virtadpt Did the amove code fix this for you?

I'm going to close this issue.  Please reopen if this is still happening.


new items????

fill in the placeholders for me plox

Wow sad merge conflicts

Wow sad merge conflicts

F

IDK how to resolve these conflicts... Ima just wait for hithere to get on lol

ok i'll do it

THANKS THONKS THINGS THANKSSSS

Closing this pr because merge conflicts are very annoying & items were already added to the code.


ErrInitIssuer x509: certificate has expired or is not yet valid

Bugs should be filed for issues encountered whilst operating cert-manager.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
Cert-manager is unable to init Lets Encrypt cluster issuer.
Result of kubectl describe clusterissuers letsencrypt-staging:
Name:         letsencrypt-staging
Namespace:
Labels:       <none>
Annotations:  API Version:  cert-manager.io/v1
Kind:         ClusterIssuer
Metadata:
  Creation Timestamp:  2020-09-28T13:53:24Z
  Generation:          1
  Managed Fields:
    API Version:  cert-manager.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .:
          f:kubectl.kubernetes.io/last-applied-configuration:
      f:spec:
        .:
        f:acme:
          .:
          f:email:
          f:privateKeySecretRef:
            .:
            f:name:
          f:server:
          f:solvers:
    Manager:      kubectl
    Operation:    Update
    Time:         2020-09-28T13:53:24Z
    API Version:  cert-manager.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        .:
        f:acme:
        f:conditions:
    Manager:         controller
    Operation:       Update
    Time:            2020-09-28T13:55:09Z
  Resource Version:  21964
  Self Link:         /apis/cert-manager.io/v1/clusterissuers/letsencrypt-staging
  UID:               d9288e2c-88d9-41fc-8abb-d4630635b853
Spec:
  Acme:
    Email<EMAIL_ADDRESS>    Preferred Chain:
    Private Key Secret Ref:
      Name:  letsencrypt-staging
    Server:  https://acme-staging-v02.api.letsencrypt.org/directory
    Solvers:
      http01:
        Ingress:
          Class:  traefik
Status:
  Acme:
  Conditions:
    Last Transition Time:  2020-09-28T13:53:24Z
    Message:               Failed to verify ACME account: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:55:09Z is after 2017-10-24T21:09:52Z
    Reason:                ErrRegisterACMEAccount
    Status:                False
    Type:                  Ready
Events:
  Type     Reason                Age                    From          Message
  ----     ------                ----                   ----          -------
  Warning  ErrVerifyACMEAccount  6m19s (x2 over 6m19s)  cert-manager  Failed to verify ACME account: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:53:24Z is after 2017-10-24T21:09:52Z
  Warning  ErrInitIssuer         6m19s (x2 over 6m19s)  cert-manager  Error initializing issuer: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:53:24Z is after 2017-10-24T21:09:52Z
  Warning  ErrVerifyACMEAccount  6m14s (x2 over 6m14s)  cert-manager  Failed to verify ACME account: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:53:29Z is after 2017-10-24T21:09:52Z
  Warning  ErrInitIssuer         6m14s (x2 over 6m14s)  cert-manager  Error initializing issuer: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:53:29Z is after 2017-10-24T21:09:52Z
  Warning  ErrVerifyACMEAccount  5m54s (x2 over 5m54s)  cert-manager  Failed to verify ACME account: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:53:49Z is after 2017-10-24T21:09:52Z
  Warning  ErrInitIssuer         5m54s (x2 over 5m54s)  cert-manager  Error initializing issuer: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:53:49Z is after 2017-10-24T21:09:52Z
  Warning  ErrVerifyACMEAccount  4m34s (x2 over 4m34s)  cert-manager  Failed to verify ACME account: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:55:09Z is after 2017-10-24T21:09:52Z
  Warning  ErrInitIssuer         4m34s (x2 over 4m34s)  cert-manager  Error initializing issuer: Get "https://acme-staging-v02.api.letsencrypt.org/directory": x509: certificate has expired or is not yet valid: current time 2020-09-28T13:55:09Z is after 2017-10-24T21:09:52Z

Expected behaviour:
Should init the issuer
Steps to reproduce the bug:

Install k3s single node cluster as shown here
kubectl create ns cert-manager
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.2/cert-manager.yaml
Create Lets Encrypt cluster issuer

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email<EMAIL_ADDRESS>    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: traefik

Anything else we need to know?:
Environment details::

Kubernetes version: v1.18.9+k3s1
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): Self hosted
cert-manager version: 1.0.2
Install method (e.g. helm or static manifests): static manifests

/kind bug

/remove-kind bug
/triage support
It looks like something in your network it MiTMing acme-staging-v02.api.letsencrypt.org and is injecting an invalid certificate.

I ran into this issue and was able to solve it by first manually deleting the secrets cert-manager-webhook-ca and cert-manager-webhook-tls which were created from a previous deployment and had expired. Once deleted the controller will recreate and then I was able to create the issuer resource.

can this issue be closed? seems it is solved
/close

I ran into this issue and was able to solve it by first manually deleting the secrets cert-manager-webhook-ca and cert-manager-webhook-tls which were created from a previous deployment and had expired. Once deleted the controller will recreate and then I was able to create the issuer resource.

i deleted all associated ，but it still appeared the same error, how can i fix it ? please help me ,thanks

facing  a similar issuewith kind, argoCD and cert-manager v1.15.3. I can't even create an Issuer, due to an invalid x509 cert at LE side, ..
>  k logs -n cert-manager cert-manager-9647b459d-r76bs
I0829 00:05:12.780155       1 sync.go:62] "Error initializing issuer: Get \"https://acme-v02.api.letsencrypt.org/directory\": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2024-08-29T00:05:12Z is after 2022-06-22T20:05:55Z" logger="cert-manager.controller" resource_name="letsencrypt-prod" resource_namespace="cert-manager" resource_kind="Issuer" resource_version="v1"
E0829 00:05:12.780493       1 controller.go:162] "re-queuing item due to error processing" err="Get \"https://acme-v02.api.letsencrypt.org/directory\": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2024-08-29T00:05:12Z is after 2022-06-22T20:05:55Z" logger="cert-manager.controller" key="cert-manager/letsencrypt-prod"

with both staging and prod LE endpoints. DNS Resolving seems to work:
> kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup acme-v02.api.letsencrypt.org
warning: couldn't attach to pod/busybox, falling back to streaming logs: Internal error occurred: unable to upgrade connection: container busybox not found in pod busybox_default
Server:    <IP_ADDRESS>
Address 1: <IP_ADDRESS> kube-dns.kube-system.svc.cluster.local

Name:      acme-v02.api.letsencrypt.org
Address 1: <IP_ADDRESS>


[5.4] Allow route groups to be loaded from a file directly

Since keeping the route definitions for each group in its own file is a common pattern, this PR allows the file path to be passed directly to the group method on the router.

Will convert this:
Route::prefix('api')
     ->middleware('api|auth:api')
     ->namespace($this->namespace)
     ->group(function ($router) {
         require base_path('routes/api.php');
     });

into this:
Route::prefix('api')
     ->middleware('api|auth:api')
     ->namespace($this->namespace)
     ->group(base_path('routes/api.php'));

This is another attempt at #14572

Nice one, @JosephSilber. Thanks :+1:


Replace DASM dependency

DASM is the only non-.NET dependency in the project. Replacing it with a .NET-compatible assembler will be necessary for full portability.
6502.Net looks to be the best candidate to replace DASM with, though it currently targets .NET Framework.
Given the maturity of DASM, it might be best to abstract out how assembly code is emitted. That way we can easily toggle between DASM and an alternative implementation to gauge if everything works right.

Work has been finished for a while. Now using a slightly modified version of 6502.Net.


Enable LazyVector::isScalar() without loading lazy vector.
Make sure to update the vector pointer after calling
EvalCtx::ensureFieldLoaded.

Without these change, expression evaluation over lazy vectors wrapped in
dictionaries and sequences would fail.
First, Expr::evalWithNulls or Expr::removeSureNulls would try calling
DictionaryVector::mayHaveNulls on a Dict(Lazy) and hit VELOX_DCHECK (initialized_);.
Second, evaluating over dictionary that adds nulls for all positions reaches a
path in Expr::peelEncodings where leaf->isConstant(rows) is true. In this case,
the Dict(Lazy) gets loaded via context.ensureFieldLoaded(fieldIndex, rows), but
the resulting vector is a different dictionary. Hence, the original 'leaf' is
still uninitialized and triggers the same check as above further down in
BaseVector::wrapInConstant.
Finally, wrapping lazy vector in a dictionary and a sequence (e.g. creating
Seq(Dict(Lazy))) triggers SequenceVector::isScalar(), which calls
DictionaryVector::isScalar(), which calls LazyVector::isScalar(), which loads
the vector from underneath the dictionary and leaves the dictionary in an
inconsistent state.

Accepted the diff. Can you add a description of the error this is fixing?

—
Reply to this email directly, view it on GitHub https://github.com/facebookincubator/velox/pull/2131#event-7077309507 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKPPPTYXH3IZPYLIXNKH4ATVWHIEJANCNFSM543N7EJA .
You are receiving this because your review was requested.Message ID: @.***>

@oerling Orri, thank you for review. I updated the description to:
Fix a few bugs and enable all tests in ExprEncodingsTest.

- Disable peeling off nulls for inputs that a not-loaded yet lazy vectors.
- Enable LazyVector::isScalar() without loading lazy vector.
- Make sure to update the vector pointer after calling
  EvalCtx::ensureFieldLoaded.

Without these change, expression evaluation over lazy vectors wrapped in
dictionaries and sequences would fail.

First, Expr::evalWithNulls or Expr::removeSureNulls would try calling
DictionaryVector::mayHaveNulls on a Dict(Lazy) and hit `VELOX_DCHECK
(initialized_);`.

Second, evaluating over dictionary that adds nulls for all positions reaches a
path in Expr::peelEncodings where leaf->isConstant(rows) is true. In this case,
the Dict(Lazy) gets loaded via context.ensureFieldLoaded(fieldIndex, rows), but
the resulting vector is a different dictionary. Hence, the original 'leaf' is
still uninitialized and triggers the same check as above further down in
BaseVector::wrapInConstant.

Finally, wrapping lazy vector in a dictionary and a sequence (e.g. creating
Seq(Dict(Lazy))) triggers SequenceVector::isScalar(), which calls
DictionaryVector::isScalar(), which calls LazyVector::isScalar(), which loads
the vector from underneath the dictionary and leaves the dictionary in an
inconsistent state.


[Feature Request] Add support for IORedis.Cluster

IORedis has support to connect to redis clusters. I didn't find a way for bull_exporter to connect to redis clusters without a small adjustment (changing the constructor from IORedis(opts) to IORedis.Cluster([opts]).
Opening up this issue to track the status of the feature.

I tried implementing the workaround, but IORedis.Cluster does not implement ping or scanstream? This looks a bit more complex that simply changing the constructor. Could you share the changes made, please?


Lightweight library for implementing APIServer extensions

The other API extension libraries were too opinionated, or not flexible enough to provide exactly what we need -- register a single noun in the API, not have storage, give full control over the http lifecycle.
This provides just enough functionality for what we need, while also providing extension points in case we need to expand the API surface area in the future - such as a more explict OpenAPI spec.
This is the foundational work that is required for converting GameServerAllocations into an API Extension - next step will be to use this library to implement that functionality.

It will likely make things easier to review, but here is a (slightly out of date) example - https://github.com/markmandel/agones/blob/feature/gsa-api-server/pkg/gameserverallocations/controller.go#L104
So you can see how the pieces end up fitting together.
(I need to update this to use go.mod instead as well)

Another thing but I'm ok with it, I don't think https is a good package name I understand why but I would prefer that you named it http and import it as https.

LGTM - What kind of operations do we want to support ? GET/POST for sure but have you anything else in mind ?

So, since we control the entire HTTP response - all HTTP verbs will be passed down to the Handler - then it's up to the handler to decide what to do with  them. For example, we do this here: https://github.com/markmandel/agones/blob/feature/gsa-api-server/pkg/gameserverallocations/controller.go#L153-L157
So I guess we already support all of them? :smile:

Another thing but I'm ok with it, I don't think https is a good package name I understand why but I would prefer that you named it http and import it as https.

As you may have guessed, this server has to be https, so it felt like https was a good package name. Maybe it should just be something more like web or httpsserver - but that didn't feel very go like? http feels misleading, since it has to be https - maybe http/TLSServer ? I'm not sure :man_shrugging: Happy to do a refactor PR if we can come up with a better package name :+1:

let's keep it like this, may be later we will have a better view.


Broken because latest cargo 0.20.0+ creates bare crate index

rustc 1.19.0-nightly (75b056812 2017-05-15)
cargo 0.20.0-nightly (13d92c64d 2017-05-12)
cargo-tree compiled against cargo 0.18.0

$ cargo tree
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: An unknown error occurred

$ RUST_LOG=trace cargo tree

<snip>

TRACE:cargo::core::source: loading SourceId; registry https://github.com/rust-lang/crates.io-index
    Updating registry `https://github.com/rust-lang/crates.io-index`
TRACE:cargo::sources::registry::remote: [registry https://github.com/rust-lang/crates.io-index] updating to rev 335e8a73a2d33fd1999bd9fdcbf52dd21e696af8
DEBUG:cargo: exit_with_error; err=CliError { error: Some(Error { code: -8, klass: 6, message: "Cannot reset hard. This operation is not allowed against bare repositories." }), unknown: true, exit_code: 101 }

The local crate index is indeed a bare repo (due to https://github.com/rust-lang/cargo/commit/15cc376b90c1dcc54cc4959f2e621cb8fa6de6f6 ) but cargo-tree compiles against an older cargo (0.18.0), so tries to git reset --hard the crate index repo (repo.reset(&object, git2::ResetType::Hard, None)?;), which fails.
I don't know if this can be fixed by changing cargo-tree to use cargo 0.20.0 (ie will it then stop working against crate index created by older cargo that isn't bare?) but I figured I'd atleast document this here.
cc @alexcrichton

I believe this error is caused by https://github.com/rust-lang/cargo/issues/4058, fixed in https://github.com/rust-lang/cargo/pull/4060

Cool, thanks. I'll close this then since cargo-tree doesn't need to change.


initDocument only inits after the document is ready

Fixes #250.

0.12.x and 0.13.x should have the fix from #249 backported, too.


Include examples of JSON use in SSO request bodies

While the OAuth 2.0 standard suggests the use of application/x-www-form-urlencoded encoded request bodies, EVE Online SSO supports the use of JSON encoded request bodies, which are already used both for requests and responses in CREST, and for responses in the SSO itself.
Thus, it might be beneficial for the documentation to describe the use of JSON for SSO request bodies, to avoid format inconsistencies between requests and responses in CREST and SSO.
Aside from the change to JSON, I've also made multiple smaller edits to fix some typos, modify wording and change formatting to make the two pages clearer. If the main changes are not considered to be beneficial, feel free to close the PR.

Mentioning JSON support and including examples is good. However, keep in mind that the SSO and CREST are separate systems -- CREST and the SSO are no more coupled together than the XML API and the SSO are, for example.
The SSO implements OAuth 2.0 and keeping the documentation consistent with that standard seems like a better alternative than making the SSO look more like CREST.
Also, can you make your commit messages a bit more descriptive than Update file.md, please? :)
Thanks!

Yeah, I get that, especially now that the SSO can be used to access the XML API and the XML API still doesn't have a JSON counterpart. Made further commits taking into account your suggestions.

Be aware we are not ignoring these PRs and issues. Really busy with a few things and while I hoped to go over this all last week I was unable to and am hoping to do it next week. Thanks for your contributions and patience. :)


[WIP][Tentative] Implement BeginRead/EndRead and BeginWrite/EndWrite on netstandard1.7

Possible workaround for SslStream issue after update to CoreFX 4.4 packages: https://github.com/dotnet/corefx/issues/14698#issuecomment-269725058
Likely not the right thing to do.
cc @davidfowl @pakrym @benaadams

Not needed after https://github.com/dotnet/corefx/commit/6031c507a0ea912ede85ca9fc3b8afc9a0fe70f0.


⚠ Spryr has degraded performance

In b1b7d0d, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 3274 ms

Resolved: Spryr performance has improved in b41ba9e after 15 minutes.


How to adding hipparcos catalogue

Hi, i want to add hipparcos catalogue to star list but i saw different value for proper motion speed when i look at hipparcos catalogue. At the same time, there is not proper motion angle value in catalogue. I guess, there aş not proper motion speed, i calculated using euclidean.

The built-in star data I am using are currently being populated from in-the-sky.org so it is possible it has a different proper motion speed than what you are looking at
If you don't have the proper motion speed and proper motion angle, do you have the proper motion along the Right Ascension and Declination? in-the-sky.org uses a proper motion speed and proper motion angle (example: Pollux) but some places like Wikipedia use proper motion along the RA and declination (example: Pollux)
Out of curiosity, which star/data are you looking at? If you have details I might be able to add functionality to account for your data in the next release

I am using hipparcos catalogue where . There are pmRA and pmDEC values. Can I pass pmSpeed and pmAngle from pmRA and pmDEC? Or do i download new catalogue in-the-sky.org. I can't this.

The current behavior of this package uses about a hundred handpicked built-in stars where I've taken their data from in-the-sky.org The stars aren't web scrapped or downloaded, they are part of the backend and are distributed as part of the package so you shouldn't need to do anything on your end to uses these built-in stars.
The backend uses this CSV file for the built-in 100+ stars
If you want to add a star that isn't currently in the built-in star list, you can use the newStar() function. When you add a newStar(), you have the option to make the new star with either the PM speed/angle or the PM Declination/RA and it will be incorporated into the rest of the plotting like any the built-in stars
Do you have a link for the Hipparcos catalogue star you want to add or an example of what you are trying to do? I might be able to answer your question or add some new functionality to incorporate it

I will add stars where hiparcos catalogue after limiting magnitude as 5. I got catalogue from hipparcos catalogue.

I updated repo, I will add new stars now.

To add a new star with the PM RA/DEC values, you want to use the newStar function that uses PM RA/Declination and then set the HIP as the star name
import star_chart_spherical_projection as scsp

hip_star = scsp.newStar(starName="<HIP>",
				ra="<RA Hours Information Here>",
				dec=<Declination Information Here>,
				properMotionSpeedRA=<PM RA>,
				properMotionSpeedDec=<PM Dec>,
				magnitudeVisual=<Magnitude>)
scsp.plotStereographicProjection(northOrSouth="North",
				userDefinedStars=[hip_star])


Uncaught DOMException: Failed to execute 'createElement' on 'Document': The result must not have attributes(…)

Currently seeing this in a a project that uses OnsenUI, which depends on Custom Elements. Error didn't occur until the latest update to chrome but is now persistent. The issue seems to come from this line here.
Current Environment Setup that might be relevant.
Onsen 2
React 15
Linux Mint 17, Chrome 54.0.2840.71 (64-bit)

that line tells me nothing, or better, it suggests me the problem is not from this polyfill.
I need a basic example to reproduce the issue without 3rd parts frameworks involved and/or transpiled.

P.S. You can use the test page to simplify this task.

Chrome 54 has native custom elements and isn't DRE's issue. The spec says explicitly that this error will be thrown if you try and set attributes in the constructor. You can set properties, but attributes mist be deferred until connectedCallback.

Thank You