Mark People with a similar name

An Enhancement to the Program would be a Highlight (like the Cheater highlight) of people with similar names (e.g same in-game name but one extra character)

Using the steam api in conjunction with some regex and simple logic it is very possible to create a rule set that allows for very high specificity and sensitivity detection of generic name stealing. Terrible pseudo code: If ((steamName != inGameName) && otherPlayerName.find(inGameName))

Yeah, thats what i meant. It might be worth implementing that, to make detecting bots that arent in the lists already, easier.

So this would help to prevent real players from being kicked whose names have been copied by the bots?

Kind of. From a tool perspective its just automating something most users (at least I assume based on how myself and friends use it) have been doing by hand. It would also future proof against new name stealing characters since it is acting based on the same metrics we are instead of just looking for one character. This would allow for the tool to more quickly identify and kick users with stolen names. Effectively reducing the likelihood that another non-tool user would kick the legitimate user sharing a name with the newly joined bot/cheater. This doesn't address the issue of communication to non-tf2bd users. See #203 and #189 as potential solutions to that problem.

Additionally you could make the program  print the command to kick the bot to chat
e.g "A cheater with the name GenericNameCopy is on the other team. Please kick them or paste this command into your Console to initiate a vote on the bot 'callvote kick {client id}' "

There has been discussion of commands in chat in general. We don't want to train players into entering commands from chat into their console. Further talk of this should be done over on #203

seems like this has been done in the recent rule update?

seems like this has been done in the recent rule update?

Not exactly, I just added another zero-width character.

Not exactly, I just added another zero-width character.

Alright, good to know.
Once it has been implemented, a chat message warning that the Bot is Imposting a Legit Player would be nice to further avoid conflicts.
Thank you for your Hard work

Alright, good to know.
Once it has been implemented, a chat message warning that the Bot is Imposting a Legit Player would be nice to further avoid conflicts.
Thank you for your Hard work

Is there any legit reason why your steamName != inGameName? I don't even know if that's possible for legit players to do. That might be a good way to at least flag someone as suspicious and warn the user that they might be a bot. You might not even need to compare their name to the other players.

Is there any legit reason why your steamName != inGameName? I don't even know if that's possible for legit players to do.

Yes, it's pretty easy to do even by accident. If you change your name twice in a small enough window of time (say... 15 minutes) the second change will only happen in game if you rematch. So your name becomes different.
Also, if you use certain, very common, characters like ~ that the in-game name doesn't like, the game will omit those when setting the in-game name
All-in-all, noticing a person has a different in-game name is just one thing to consider when trying to know if someone is cheating, but it's pretty easy to happen to legit players too.

I think the best approach to this would be an Additional Color Category.
i.e 2 different People with almost Matching name, both get Marked as "Possible Imposter", rules like "If Possible imposter has nickname, mark as Imposter" to find the true Imposter and sending an Appropriate Chat Message like:
"Attention! There is an Imposter Bot on the Enemy Team that goes by the name [name]! Make sure you kick the Bot!"
As soon as one of them leaves, both "Possible Imposter" Marked people get Unmarked and the Imposter marked as Cheater or Suspicious.

I think the best approach to this would be an Additional Color Category.

I disagree, I think that is unnecessarily complicated for a simple issue.
Just create a logic for looking for names that are the same once a list of characters (stored in a JSON) gets subtracted from both, and mark the one that has been in the match for the least amount of time as cheater (iirc, lobby returns the player time in the current server reliably).
A custom chat command MAY be implemented to curb people voting yes without looking amidst the voice spam. But it wouldn't be too useful since asking people to paste commands in console is not a good idea, and normal players can't discern between the impostor and the original to properly create a vote. It would be something like: "Attention: A bot/cheater is stealing the name of a player, be careful not to vote the wrong person off!"

Just create a logic for looking for names that are the same once a list of characters (stored in a JSON) gets subtracted from both

This would fail because of all the characters in unicode that look the same.
Example:
Kenajcrap and 𝗞enajcrap might show up the same in TF2 but be considered different when comparing the strings.
There are also a whole bunch of substitutions that can be used that look very similar like α in place of a. If you just delete these "special" characters then the strings will appear to be different when you compare them. You need to use a library that is designed to compare strings that could be visually confused with one another.

yea, after reading the other issue I understand it's not as straight forward as I initially thought. The suggestion I made there still stands though

Would it really be that hard?
id imagine that if that list of unicode character gets subtracted, the strings either are the same, or not. That can be used to Detect the Imposter.
(imagine the ? is the unicode character)
"Kenjacr?ap" and "Kenjacrap" - With unicode char, they are not the same.
"Kenjacrap" and "Kenjacrap" - Without Unicode char, they are the same.
You could use the Before and After unicode removal string to compare it.
If ( (postRemovalPlayer1 == preRemovalPlayer1) && (preRemovalPlayer1 != preRemovalPlayer2) && playerTimeInMatch < playerTimeInMatchOfOtherPerson) { MarkasCheater }

Look at the example I gave.
You have "Kenajcrap" and "Kenajcrap"  if you remove the Kelvin symbol (K) which looks identical in TF2 to a capital K then you have "enajcrap" which is not the same as "Kenajcrap" so your check fails. The same applies for lots of characters. You can't just remove them because they are substitutes for letters.
Yes, if they just insert a zero width character you could remove it, but there are lots of other unicode characters that they can use.

in TF2 they might look the same but im sure the program can differenciate the unicode U+039A from U+004B which would be the Kelvin Symbol and the Latin Letter K.
As i said, a list of non-alphabetical and default numbers (their code), and remove those Accordingly, leaving only the standard alphabetical and numerical ones, which then can be used to do the thing in my comment.

Out of interest of sanity comparing to steam name is still of value. Especially considering some work is being done on that already.
We are less concerned about actual Unicode replacements at this time since that method has not been seen in the wild. Not to mention the tf2 font does make Unicode lettering stick out.
Also the addition of categories will likely not be a thing given the goal is for user defined categories and the current set is a good enough base.

I agree, I think comparing the steam name could be useful if most of the time it's a bot and only sometimes a real player. You could perhaps even have a variety of different checks like steam name, avatar the same as someone else in the game etc. and if a player failed all of them you would have a higher confidence that it's a bot.
I think you should be concerned about Unicode replacement as it is very easy to lookup characters that look the same as letters in someone's name and then create a table of the ones that actually display the same or very similar in TF2. I found a bunch just testing for a few minutes that look identical to the Latin letters that most people use in their name.
It seems obvious to me that if the bot detector was able to filter out zero-width characters and diacritic marks then character replacement is what the bots would start using next. Just like how they changed the characters they were using recently once this tool was updated to flag them.
I also think it's possible that the bots might update to change their steam name as well if this tool starts flagging differences. In the long term I think normalizing and comparing the strings might be the hardest for them to overcome.

Unicode has technical standard 39 which talks about how to compare strings with confusables (identical chars): http://unicode.org/reports/tr39/#Confusable_Detection. You essentially convert everything so that things look the same are converted to the same things, after which you can compare them byte-for-byte. The data updates with unicode, so this might be work long term.
Im not sure if you could somehow use the fonts tf2 uses to check what becomes what.
Either way, it sounds easier to use the unicode method at first (which has implementations) rather than trying to disectect ttf files.
There are still some quirks that can't be removed this way, like (if i remember correctly) vv looking like M in one font.

@astability I tried to implement this here: https://github.com/PazerOP/tf2_bot_detector/issues/138#issuecomment-797767597 If you have Visual Studio you can run the code and see if you can find a string that looks the same in TF2 but doesn't get detected.


Support for transducer

Thanks for creating this and simplifying onnx export.

Do you have a timeline for the transducer ASR model support?

from espnet2.bin.asr_inference import Speech2Text
import os
import yaml
from espnet_onnx.export import ModelExport
from pathlib import Path

m = ModelExport()

os.chdir("egs2/librispeech_100/asr1/")

transducer_conf = yaml.safe_load(Path('conf/decode_rnnt_conformer.yaml').read_text())

speech2text = Speech2Text(asr_train_config="exp/asr_train_rnnt_conformer_raw_en_bpe5000_sp/config.yaml",
                          asr_model_file="exp/asr_train_rnnt_conformer_raw_en_bpe5000_sp/latest.pth",
                          transducer_conf=transducer_conf["transducer_conf"],
                          lm_weight=0.0)

m.export(speech2text, 'onnx_export', quantize=True)

^ I was trying to export a sample transducer checkpoint like this and was running into attribute errors at espnet_onnx/export/asr/export_asr.py" _create_config function.

Can you comment if the above snippet is correct? If I just provide None to attributes that dont exist (Eg: model.beam_search), would the conversion still work ?

@gowtham1997
Thank you for using espnet_onnx!

Do you have a timeline for the transducer ASR model support?

I usually develop espnet_onnx on a whim, so there is no schedule. But I will implement transducer-related scripts this weekend! I planned to implement some scripts for TTS, so I think I can publish transducer support with some TTS support.

Can you comment if the above snippet is correct?

Your snippet is almost correct. Currently, the transducer is not supported, so the speech2text model should be some other model.

If I just provide None to attributes that don't exist (Eg: model.beam_search), would the conversion still work ?

Am I correct that you're saying that if someone can export an instance of espnet2.bin.asr_inference.Speech2Text, which does not have some attributes like beam_search?
If that's right, no, the conversion will not be completed.
Some attributes may not be required for conversion, but many attributes like encoder, decoder, and beam_search, and their configurations are required for inference of the onnx version.

Thank you for your information and suggestion! I think coding the transducer won't take that long, so I can code for it.
Please let me know when you merged the new transducer. I will support that new version then!

After discussion, the current Transducer version will stay so don't worry about working on it right now :)
If we add the new version, I'll try to take care of the export!

About the onnx export, it will be very difficult if the structure of the model changes dynamically during inference. For this reason, I split the RNNDecoder into predecoder and decoder, where predecoder only contains attention models.
So it would be better if the model does not change during inference, but there could be a way to implement the model in some way, so you don't have to care about exporting it!

Thanks for the info! Hum, it shouldn't be an issue then, I'll take a look.

Hi @gowtham1997,
I just merged the #19 and now you can convert the transducer model!
It is not published on pypi yet, but you can clone and export your model.

Thanks again.
Will test it out


Pay September salaries

I have a meeting with a friend today who ran a nonprofit for a while where I'm going to ask a couple questions about salaries. Going to send out the checks today.

Meeting was cancelled. Just going to go ahead and do this.


Documentation on error handling

I would like documentation on the error object that could be thrown when making calls with this API, how do I capture the error, and how do I obtain details of the errors so I can log it in my app.

Plus 1 to this.
I am trying to handle errors in my stream implementation.  The documentation says:

If OpenAI returns an error, ruby-openai will pass that to your proc as a Hash.

However when forcing an error state by passing bad params, my call to chat returns an empty array and never seems to enter the proc
irb(main):123:1* def handle_open_ai_response
irb(main):124:2*   proc do |response, other|
irb(main):125:2*     puts other
irb(main):126:2*     puts "In proc"
irb(main):127:2*     puts response
irb(main):128:1*   end
irb(main):129:0> end
:handle_open_ai_response
irb(main):130:1* parameters = {
irb(main):131:1*    model: "gpt-4",
irb(main):132:1*    messages: [{ role: "abuser", content: "Hello there" }],  # error on this line, invalid role
irb(main):133:1*    temperature: 0.1,
irb(main):134:1*    stream: handle_open_ai_response,
irb(main):135:0> }
{
          :model => "gpt-4",
       :messages => [
        [0] {
               :role => "abuser",
            :content => "Hello there"
        }
    ],
    :temperature => 0.1,
         :stream => #<Proc:0x000000011952d4a0 /Users/me/dir/dirpath/(irb):124>
}
irb(main):136:0> client.chat(parameters:)
[]

With no error state I get the expected result in my proc
irb(main):143:0> client.chat(parameters:)

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"role"=>"assistant", "content"=>""}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>"Hello"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>"!"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>" How"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>" can"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>" I"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>" assist"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>" you"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>" today"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{"content"=>"?"}, "finish_reason"=>nil}]}

In proc
{"id"=>"chatcmpl-7wesyhCHZP2HZM2YOmtcdSooCI30E", "object"=>"chat.completion.chunk", "created"=>1694214544, "model"=>"gpt-4-0613", "choices"=>[{"index"=>0, "delta"=>{}, "finish_reason"=>"stop"}]}
[]

Getting empty response when sending more tokens than model can accept. Any ideas how to keep streaming but also handle errors?

Maybe we could get some inspiration from the official implementation in NodeJS Maybe they have more extensive coverage of the different outcomes.

Thanks for raising - this is fixed in v6


Add upgrade instructions to README.md

We don't have instructions on how to upgrade in the cli repo readme nor in the changelogs. It might be a good idea to have a thing in both places.
pip install instructlab --upgrade worked for me, but i dont know if i have to upgrade venv as well as a good practice or whatnot

Hello! Can I be assigned to this?

Hello! Can I be assigned to this?

It's all yours now! Thanks!

I don't think we need this in the CHANGELOG.md, we just include the pip install instructlab --upgrade once we ship a release in https://github.com/instructlab/instructlab/releases.
However having this in the README is important. Thanks!


Microsoft Bot - How to receive user id

I am running Microsoft bot and enabled it for Skype.
I want to know how I can receive user id at the bot's end?
My bot needs to identify to whom it is communicating.
controller.hears(['hello', 'hi'], 'message_received', function(bot, message) {     console.log("MESSAGE-->"+message);     console.log("MESSAGE USER-->"+message.user);     controller.storage.users.get(message.user, function(err, user) {         if (user && user.name) {             bot.reply(message, 'Hello ' + user.name + '!!');         } else {             bot.reply(message, 'Hello.');         }     }); });
Console does not print anything on terminal. and I only receive "Hello" as reply.
Where can I find the documentation for message object supported by Howdyai botkit?

If you start bot with debug:true console  prints all those id's..
var controller = Botkit.botframeworkbot({
    debug: true
});
var bot = controller.spawn({
    appId: process.env.app_id,
    appPassword: process.env.app_password
});

thanks, but I need the skype user id to whom bot is communicating like "john07" is chatting with bot, then I can capture the user id "john07" even if debug is false. I am exploring to use the user id for authentication purpose.

No idea if it is the same but using slack the userId is available as message.user.

The message object passed to your bot will have a user field with an id,
but I dont know enough about bot builder or skype to know what that id
entails.
There should be some skype api call where you exchange the userid for skype
name.
On Fri, Mar 10, 2017 at 3:30 AM Jonathan Johnson<EMAIL_ADDRESS>wrote:
No idea if it is the same but using slack the userId is available as
message.user.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/howdyai/botkit/issues/672#issuecomment-285608538, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMUR23lwgLv9Bjhkbc4exlZcrL59hij0ks5rkQo8gaJpZM4MJtwo
.


Why use Qlik if your using GraphQL

This probably sounds abit random but what extra value does qlik add to a project if your already using GraphQL? GraphQL is basically its own associative engine right? Im just struggling to think why would need Qlik if your already familliar with GraphQL.

Hey Adam, actually GraphQL is not any sort of engine. It's a spec for an API format, in the same vein of REST and RPC. Qlik uses JSON-RPC today via WebSockets, but there are scenarios where other types of APIs could be useful for communicating with the engine. For example, @ralfbecher created a library called q-risotto that puts a REST API in front of the Engine. This project does something similar - it shows how you would create a GraphQL API in front of the Engine.
There are various pros and cons for RPC vs REST vs GraphQL - it all depends on what you are trying to accomplish. This article breaks it down nicely: https://blog.apisyouwonthate.com/understanding-rpc-rest-and-graphql-2f959aadebe7

Hey Speros,
Get what your saying, I’ve not used GraphQL before, thought it was some
kind of alternative to REST protocol that you write schema for - I just
assumed qlik did the same type of function, modelling data and outputting
the result.  😄.
I’m not particularly experience with GraphQL, so just trying to educate
myself abit more ;). I need to find a good experience not to try it on to
understand the value
On Tue, 28 Aug 2018 at 14:29, Speros Kokenes<EMAIL_ADDRESS>wrote:

Hey Adam, actually GraphQL is not any sort of engine. It's a spec for an
API format, in the same vein of REST and RPC. Qlik uses JSON-RPC today via
WebSockets, but there are scenarios where other types of APIs could be
useful for communicating with the engine. For example, @ralfbecher
https://github.com/ralfbecher created a library called q-risotto that
puts a REST API in front of the Engine. This project does something similar

it shows how you would create a GraphQL API in front of the Engine.

There are various pros and cons for RPC vs REST vs GraphQL - it all
depends on what you are trying to accomplish. This article breaks it down
nicely:
https://blog.apisyouwonthate.com/understanding-rpc-rest-and-graphql-2f959aadebe7
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/stefanwalther/qix-graphql/issues/53#issuecomment-416584235,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYP1qlCQtfqjC6sbqKN1w-DrbyHZKx3ks5uVUXEgaJpZM4WMWPZ
.

Fully agree with @skokenes comments!


Disable centering the map on cluster single tap

When single tapped on a clustered icon then this cluster is centered on the map.
The problem with this effect is that in the onClusterClick event, zooming or moving the map is impossible because immediately afterward, the map will move automatically to center the clustered pin that was clicked.
Is there a possibility to disable or enable this effect at will?

I faced the same issue. Waiting for resolving.

A workaround I use is send the MoveToRegion in a Async Task with a delay. that way after clicking the cluster, I can do what I want.   I face a similar problem because,  iOS behave different than Android after clicking the cluster.


Bug: Destination connector stops upon handling first message

Bug description
Right after starting a pipeline with two builtin:kafka connectors (source from one topic, output to another), the destination connector immediately stops:
2022-03-25T18:36:56+00:00 DBG starting pipeline component=pipeline.Service pipeline_id=9155d960-165d-450e-8137-3c923b2b018c request_id=5e20b661-d430-4465-b20c-f8e8722a5359
2022-03-25T18:36:56+00:00 INF pipeline started component=pipeline.Service pipeline_id=9155d960-165d-450e-8137-3c923b2b018c request_id=5e20b661-d430-4465-b20c-f8e8722a5359
2022-03-25T18:36:56+00:00 DBG starting destination connector plugin component=connector.Destination connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a
2022-03-25T18:36:56+00:00 DBG starting source connector plugin component=connector.Source connector_id=0f08dab9-3b6c-46e2-b5c1-68513fd9ba24
2022-03-25T18:36:56+00:00 INF request processed duration=0.321186 grpc_method=/api.v1.PipelineService/StartPipeline grpc_status_code=OK http_endpoint="POST /v1/pipelines/9155d960-165d-450e-8137-3c923b2b018c/start" request_id=5e20b661-d430-4465-b20c-f8e8722a5359
2022-03-25T18:36:56+00:00 DBG configuring destination connector plugin component=connector.Destination connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a
2022-03-25T18:36:56+00:00 INF Configuring a Kafka Destination... connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a plugin_name=kafka plugin_type=destination
2022-03-25T18:36:56+00:00 DBG configuring source connector plugin component=connector.Source connector_id=0f08dab9-3b6c-46e2-b5c1-68513fd9ba24
2022-03-25T18:36:56+00:00 INF destination connector plugin successfully started component=connector.Destination connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a
2022-03-25T18:36:56+00:00 INF Configuring a Kafka Source... component=plugin connector_id=0f08dab9-3b6c-46e2-b5c1-68513fd9ba24 plugin_name=kafka plugin_type=source
2022-03-25T18:36:56+00:00 INF source connector plugin successfully started component=connector.Source connector_id=0f08dab9-3b6c-46e2-b5c1-68513fd9ba24
2022-03-25T18:36:56+00:00 DBG stopping destination connector plugin component=connector.Destination connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a
2022-03-25T18:36:56+00:00 DBG tearing down destination connector plugin component=connector.Destination connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a
2022-03-25T18:36:56+00:00 INF Tearing down a Kafka Destination... connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a plugin_name=kafka plugin_type=destination
2022-03-25T18:36:56+00:00 INF connector plugin successfully torn down component=connector.Destination connector_id=1507c91d-ba2d-45a7-8222-8ee34e90db7a

Steps to reproduce
:one: Create pipeline
:two: Add source kafka connector:
  {
    "type": "TYPE_SOURCE",
    "plugin": "builtin:kafka",
    "pipelineId": "b44b63c2-aa26-4ecb-aec3-5a4ea0e1d479",
    "config": {
      "name": "kafka-in",
      "settings": {
        "servers": "localhost:9092",
        "topic": "new-json-struct",
        "readFromBeginning": "true"
      }
    }
  }

:three: Add destination kafka connector:
{
  "type": "TYPE_DESTINATION",
  "plugin": "builtin:kafka",
  "pipelineId": "b44b63c2-aa26-4ecb-aec3-5a4ea0e1d479",
  "config": {
    "name": "kafka-out",
    "settings": {
      "servers": "localhost:9092",
      "topic": "output-test-hi"
    }
  }
}

:four: Start Pipeline - you'll see the destination connector stop. The destination topic was created on the kafka cluster, but no messages were written to it.
Maybe helpful - if I stop and restart conduit, then the message will successfully write to the destination. So I wonder if something got stuck / into a bad state before restarting?
Also - I tried this with the latest conduit main branch, along with updating to the latest commit of this connector - still had this issue.
Version
v0.2.0-nightly.20220325

Maybe helpful - if I stop and restart conduit, then the message will successfully write to the destination. So I wonder if something got stuck / into a bad state before restarting?

This is helpful! So, after you restart Conduit, and then write more messages to the source topic, do they get written to the destination topic too?
From your message, I also understand that the destination topic kafka-out didn't exist at the time you created the pipeline?

This is helpful! So, after you restart Conduit, and then write more messages to the source topic, do they get written to the destination topic too?

Yup, after the restart the messages do get written to the destination topic.

From your message, I also understand that the destination topic kafka-out didn't exist at the time you created the pipeline?

Correct. However, upon the first time starting the pipeline, the destination topic was created, but no messages were written to the topic yet.

What I think is happening there is what at least I experienced when using some Kafka tools locally. When I want to consume from/produce to a topic which doesn't exist, and auto-create is enabled (even though I rarely use that), it takes some time for the broker to create the topic, which causes a timeout in the client.
What we can do here is to increase the timeout. But what I think we must do is check why don't we see in Conduit the actual error which made the destination stop.

@hariso what is the retry logic here? Does it throw a generic timeout error or something more specific?

@lyuboxa I just tested it, and when the topic doesn't exist at the moment of sending a message, and auto-create is enabled, the error message is:
Leader Not Available: the cluster is in the middle of a leadership election and there is currently no leader for this partition and hence it is unavailable for writes

The error type is specific, kafka.LeaderNotAvailable, so we can easily check for it, and retry.


Chart not working with CoreDNS v1.8.3 (missing permissions)

CoreDNS v1.8.3 image released recently but is not compatible with current version v1.14.1 of the chart.
It looks like the service account needs more permissions:
E0225 12:38:35.403129 1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1beta1.EndpointSlice: failed to list *v1beta1.EndpointSlice: endpointslices.discovery.k8s.io is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "endpointslices" in API group "discovery.k8s.io" at the cluster scope

It seems adding:
+- apiGroups:
+  - discovery.k8s.io
+  resources:
+  - endpointslices
+  verbs:
+  - list
+  - watch

Is sufficient to fix this.

https://github.com/coredns/deployment/blob/master/kubernetes/coredns.yaml.sed#L24-L30

Opened a pr to fix this 🙃

kubectl edit clusterrole system:coredns


One of the CoC filenames must be CODE_OF_CONDUCT.md

Description
There is two code of conduct files, but none of these are going to be detected by GitHub.
I tried searching if there was a way to have two codes of conduct, but I don't think that's possible.
We should rename one of the files to CODE_OF_CONDUCT.md so that GitHub detects it properly.
What do you think about this? And which one should we rename? 🤔
Thanks. 🙂

@Panquesito7 yes, would like to go ahead with this, what would you think to be the right COC for @devstrons?

https://github.com/devstrons/support/commit/0b10a909887898be2b579b7113a7ab3879bf5afb
https://github.com/devstrons/support/commit/04ff17fb2904d39cda0cc4a356db4090211c8601


server/shadow: Export API to set built-in subsystem modules for freerdp-shadow-subsystem

Fix compile error for server on windows which we discussed in #3150

@realjiangms This will not work if function visibility is activated (currently working on a patch for that). You need to FREERDP_API the subsystem function.

@realjiangms Ok, never mind, fixed that in #3168

Thanks @akallabeth . The related fix in #3168 resolves the compile issue.
However in #3150 we decide still not export (by default) Win_ShadowSubsystemEntry/X11_ShadowSubsystemEntry/Mac_ShadowSubsystemEntry as they are internal implementation.
So in this PR we introduce API shadow_subsystem_set_entry_builtin to select the built-in subsystem entries.

@realjiangms Ok, good. As stated in #3168 for the time being I need to export those functions there. Depending on which one is merged first this or my pull need to be updated.

LGTM +1 btw

+1
@realjiangms nice thanks!
@xhaakon anything still missing for you use case after merging this?

@bmiklautz this should be sufficient for my usage scenario, thanks!
 I'm updating the package this moment. Comment here once I'm done.

@xhaakon pushed the latest freerdp2 package right now. Upstream was merged. There is now a libfreerdp-shadow2 package and freerdp-shadow is "exported" with pkg-config and cmake (in the package freerdp2-dev).

@bmiklautz Thanks, I've checked the package. It builds and works well for me, but I still found some smaller issues and created separate PRs for them:
https://github.com/FreeRDP/FreeRDP/pull/3182
https://github.com/bmiklautz/debian-freerdp2/pull/3


feat: only show scroll switch when needed

When the editor is in preview-only mode, the Scroll Auto can cause confusion.
yet noScrollAuto may need to be carefully considered. Another idea is to make scrollAuto = null to represent noScrollAuto, but it seems equally elegant as this :(

Thanks! Maybe we can also try pkg.pr.new


Symbolic names don't support having duplicate symbolic names in the same file

Bicep version
Bicep on the main branch 4e8f9982e29d3278eab6357e2817759ff0c857ce
Describe the bug
Compiling the following file with symbolic names enabled causes an arm.json to be invalidly generated:
var adminUsername = 'cooluser'
var adminPassword = 'p@ssw0rd'

resource server 'Microsoft.Sql/servers@2021-02-01-preview' = {
  name: 'sql-${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  properties: {
    administratorLogin: adminUsername
    administratorLoginPassword: adminPassword
  }

  resource db 'databases' = {
    name: 'cool-database'
    location: resourceGroup().location
  }

  resource firewall 'firewallRules' = {
    name: 'allow'
    properties: {
      startIpAddress: '<IP_ADDRESS>'
      endIpAddress: '<IP_ADDRESS>'
    }
  }
}

resource server2 'Microsoft.Sql/servers@2021-02-01-preview' = {
  name: 'sql'
  location: resourceGroup().location
  properties: {
    administratorLogin: adminUsername
    administratorLoginPassword: adminPassword
  }

  resource db 'databases' = {
    name: 'cool-database2'
    location: resourceGroup().location
  }

  resource firewall 'firewallRules' = {
    name: 'test'
    properties: {
      startIpAddress: '<IP_ADDRESS>'
      endIpAddress: '<IP_ADDRESS>'
    }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "languageVersion": "1.9-experimental",
  "contentVersion": "<IP_ADDRESS>",
  "metadata": {
    "EXPERIMENTAL_WARNING": "Symbolic name support in ARM is experimental, and should be enabled for testing purposes only. Do not enable this setting for any production usage, or you may be unexpectedly broken at any time!",
    "_generator": {
      "name": "bicep",
      "version": "0.4.1301.36686",
      "templateHash": "9734393720281616781"
    }
  },
  "variables": {
    "adminUsername": "cooluser",
    "adminPassword": "p@ssw0rd"
  },
  "resources": {
    "db": {
      "type": "Microsoft.Sql/servers/databases",
      "apiVersion": "2021-02-01-preview",
      "name": "[format('{0}/{1}', 'sql', 'cool-database2')]",
      "location": "[resourceGroup().location]",
      "dependsOn": [
        "server2"
      ]
    },
    "firewall": {
      "type": "Microsoft.Sql/servers/firewallRules",
      "apiVersion": "2021-02-01-preview",
      "name": "[format('{0}/{1}', 'sql', 'test')]",
      "properties": {
        "startIpAddress": "<IP_ADDRESS>",
        "endIpAddress": "<IP_ADDRESS>"
      },
      "dependsOn": [
        "server2"
      ]
    },
    "server": {
      "type": "Microsoft.Sql/servers",
      "apiVersion": "2021-02-01-preview",
      "name": "[format('sql-{0}', uniqueString(resourceGroup().id))]",
      "location": "[resourceGroup().location]",
      "properties": {
        "administratorLogin": "[variables('adminUsername')]",
        "administratorLoginPassword": "[variables('adminPassword')]"
      }
    },
    "server2": {
      "type": "Microsoft.Sql/servers",
      "apiVersion": "2021-02-01-preview",
      "name": "sql",
      "location": "[resourceGroup().location]",
      "properties": {
        "administratorLogin": "[variables('adminUsername')]",
        "administratorLoginPassword": "[variables('adminPassword')]"
      }
    }
  }
}

In the json, the resources db and firewall should be in the resource list twice in some capacity, but the second db and firewall  definition overwrites the first definitions.
Additional context
Issue seems to be targeted around https://github.com/Azure/bicep/blob/main/src/Bicep.Core/Emit/TemplateWriter.cs#L342, writing the name here twice

Resource symbolic names must be unique in a same template. Template engine will reject a request with duplicate symbolic names.
This issue appears to be a validation gap in bicep TemplateWriter. An invalid bicep error should be raised rather than overwriting with the duplicate.

This issue appears to be a validation gap in bicep TemplateWriter.

This isn't just a validation gap, there's a feature that conflicts with how symbolic names work today :)
Syntactic nesting of resources provide namespacing for the things inside, as well as a dedicated syntax for referencing nested resource (db::firewall). It would be weird to unwind this feature because we didn't account for it during the design of symbolic names.
Two options here:

Support some kind of name-mangling for symbolic names so we can represent everything that's valid.
Removing namespacing of symbolic names for nested resources, and remove the :: operator.

The namespacing rules for nested resource type and behavior of :: operator in Bicep are correct. We should update the codegen Bicep to generate unique symbolic names correctly for the nested resources using a mangling approach.
@lwang2016 and I looked at the validation code in the service and it seems we only allow _ in addition to word chars in symbolic names. Unfortunately _ is allowed by Bicep in symbolic names, so that doesn't help. He will update the runtime to add : to the list. Then Bicep can generate db:firewall as the symbolic name on nested resources and it should solve the issue.

Why not :: instead of : for consistency for the code generation?

Was micro-optimizing for size since we have a 4MB limit, but it probably won't make much of a difference either way.

@majastrz - is there an issue tracking the update to the deployment validation code? I think @jkotalik or I would be happy to help with the compiler part of this.

@lwang2016 merged the PR into the internal deployments repo but the new package hasn't been picked up by ARM yet.

I'm pretty sure the code gen from bicep to ARM was incorrect as well. I think that's the part that @rynowak is referring to where we could potentially help.

@jkotalik You figured out my game. I'm volunteering us help with the codegen part if the deployment engine change is already moving.


Metrics UI needs favicon (a.k.a Where's Wally?)

1. description of problem
Metrics UI tab is hard to locate when you have multiple tabs open in your browser. (See screenshot)
2. steps to reproduce
Start metrics ui and have other tabs open. Switch away from metrics ui. Now, it's hard to find it again, because the tab has no favicon to distinguish it.
3. expected behavior
It's easy to find the Metrics UI tab among other tabs, because it has a favicon.
4. actual behavior
It's hard to find the Metrics UI tab among other tabs, because it doesn't have a favicon.

See: https://www.wallaroolabs.com/wp-content/uploads/2018/07/wallaroowallincircle.png
This is the current favicon for wallaroolabs.com

@pzel I'll add this for next release


Merged Filters Complex Response should Ignore Time Delay type filters.

The complex response for the time delay filter should in general be avoided.  ")

It can suffer some pretty serious phase wrapping as frequencies grow, making the plots hard to interpret
When applied to finite time series it rolls the timeseries (in the np.roll() sense) resulting in data from late time showing up at early time - i.e. non physical data which will result in incorrect processing results

In general, delay corrections should be applied in time domain before spectral processing and so these need to be treated differently.
This begs the question, should we group any other filters into time domain application?  For example, it is easy to apply coefficient filters there, but there doesn't seem to be any compelling reason to.  In general we will not have flat reponses in frequency domain and the defauly notion right now is to apply all filters merged in frequency domain with the lone exception of delay, which will be applied by pre-aligning all multivariate timeseries and interpolating them all onto the same time axis for a given "Run"

Committed a change to address this.
There is still the issue of us potentially encountering filters that have a time delay, and a non-flat frequency response.  If we encounter such a filter it will not play nice.
I put a note in the Friday Discussion page to ask Tim about examples of these filters...
The only type of filter in the StationXML reference document that has a   is the Decimation Filter.  I note that this does not have a way to describe a non-trivial frequency response ... but the decimation should have an AAF last I checked, so something is not yet 100% right here.   It could be that they factor the digital decimations into a FIR/IIR stage and then add the "decimation time delay" as a separate stage, but what they really mean is "downsample after IR" rather than "decimation".
Once that is sorted we can close this out.

The only StationXML stage that has a delay is the decimation stage.  It does not have a mechanism to apply a variable frequency response.  So we should in general be able to separate time delays from all other types of stages.


unusable if current BE is not mounted on /

A great feature would be to have sync-be work even when the current BE is mounted somewhere else then /. This is the case for example if the BE gets mounted from a LiveCD for recovery purposes etc or just after a fresh install.
Maybe it would be enough to have an option that sets ROOTFS to something else:
https://github.com/KlaraSystems/sync-be/blob/8d6e6e0e1067f97a0e75732edff9da3de2026bb9/sync-be#L90-L95
If this is something you would consider useful, I'd be glad to prepare a PR.
Cheers,
Filias

Hi!
Well if you have already something on you side, we will be pleased to add this usefull option.
Kind regards

I think my main question is: Why is this check there in the first place? Is there a reason why it has to check if the dataset is mounted on /? My first instinct was, that this check might be not needed at all and we could just take ROOTFS from e.g $3 if there is no dataset mounted on /.
I'm trying to understand how I can solve this in the best way without affecting any safeguards that might be in place for a very googd reason.
Cheers


Spring Data JPA "Quick Start" guide should include example code for minimal configuration to use a repository.

Something like:
    @Bean
    public EntityManagerFactory entityManagerFactory() {
      // fill in details
    }

    @Bean
    public DataSource dataSource() {
       // fill in details
    }

    @Bean
    public JpaTransactionManager transactionManager() {
       // fill in details
    }

And:
    public interface ThingRepository extends CrudRepository<Thing, Long> {
    }

    @Entity
    public class Thing {
         @Id
          private Long id;
    }

   class Foobar {
        @Autowired
         ThingRepository repository;

         public void work() {
              Iterable<Thing> things = repository.findAll();
              // do work
         }
   }

For the record, check out https://github.com/spring-projects/spring-data-jpa/issues/926#issuecomment-1102969007 for additional reasons why this isn't presently supported.


Feature request: option to disable certain tests

Hi Tyrone,
This is a feature request to be able to configure that some tests are disabled.
Sometimes there are good reasons to deviate from the CIS benchmark. A "Failed check" confuses people and may waist time of auditors and engineers. Typically these deviations are well documented and organisations have security processes in place with approvals.
I would prefer to be able to disable certain tests, so "Failed Checks" can become 0 when the router is configured as it was intended.
However, transparency is probably key here. I think that potential disabled tests deserve a place in the report also. I see a couple of scenario's for that.

A new category (like Passed/Failed/N.A.) with its own counters
Just a small line of text somewhere: disabled checks: "a.a.a, b.b.b, c.c.c".
Use the Compliant column and instead of reporting True or False, report Disabled.

Please consider.
Kind regards,
Jan

Hi Jan,
This is a good idea, will work on the previous issues/requests first then this.
Best regards,
Tyrone Ilisan

Awesome!


dropkick overrides my this.value on initialize and change methods

I would like to wrap dropkicks result with some extra markup. but it seems dropkick resets the value back to the original this.value. what am i missing here:
$(".dk-dropdown-compact").dropkick({
  mobile: true,
  initialize: function() {
    value = this.value;
    var text = value.split(" ");
    var first = text.shift();

    if (text.length > 0) {
      value = " <span class='first-word'" + first + " " + text.join(" ");
    } else {
      value = "" + first + "";
    }

    this.value == value; // this does not work because dropkick overrides it somehow
  },
  change: function() {
    value = this.value;
    var text = value.split(" ");
    var first = text.shift();

    if (text.length > 0) {
      value = " <span class='first-word'" + first + " " + text.join(" ");
    } else {
      value = "" + first + "";
    }

    this.value == value; // this does not work because dropkick overrides it somehow
  }

});

this.value == value

this.value = value?

I don't know what you're trying to accomplish, but if you're just looking to change the HTML  of the combobox, then that is not the way to do it. That just sets the value property of the Dropkick object.
If you did want to change the combobox HTML, you'll want to do something like the following:
var combobox = this.data.elem.firstChild;
combobox.innerHTML = value;

hey thanks for the quick reply. that solved the issue and now i see what i was doing wrong. basically i was changing the selects value rather then the combobox's innerHTML which is buried in the data.elem object.
yes; i was trying to change the combobox html to style the first word differently.
this code works:
$(".dk-dropdown-compact").dropkick({
		mobile: true,
		initialize: function() {
			var value = this.value,
					text = value.split(" "),
					first = text.shift(),
					combobox = this.data.elem.firstChild;

			if (text.length > 0) {
				value = '' + first + ' ' + text.join(" ");
			} else {
				value = '' + first + '';
			}

			combobox.innerHTML = value;
		},
		change: function() {
			var value = this.value,
					text = value.split(" "),
					first = text.shift(),
					combobox = this.data.elem.firstChild;

			if (text.length > 0) {
				value = '' + first + ' ' + text.join(" ");
			} else {
				value = '' + first + '';
			}

			combobox.innerHTML = value;
		}
  });

but how can i create a method that i can reuse for dropkick's initialize and change events. i've been hacking around with jquery for too long and just now getting more serious about my js.
thanks again!


Sonoff Door Sensor SNZB-04

Hi,
This device showing UNAVAILABLE

Not working anymore.
Please advice.
Thanks

I think in this case the SNZB-04 is discharged and the batteries need to be replaced, or [Integrations -> Sonoff -> ... -> Reload] maybe it will help.

I think in this case the SNZB-04 is discharged and the batteries need to be replaced, or [Integrations -> Sonoff -> ... -> Reload] maybe it will help.

But in the ewelink its working and do function where it can detect open and closed...not working in HA

Do you have other zigbee devices? Do they work in Hass?

Do you have other zigbee devices? Do they work in Hass?

I solved th issue. I disabled and reinstall the plugin.

Ok


Enhancement: Add preset fields to the exporter inorder to include addditional preset conditions

Hi! We could add a few preset joint criteria as shown here. Of course, it will need manual tuning to get it even close to being realistic (eg. joint-limits, calibration, damping, effort, etc), But I think this could be a good enhancement. I will try to create a pull request.
Example:

We could just input these values directly and the users can modify them at will. We will need to provide a disclaimer in the Readme file tho.
Warm Regards,
Rohit

Thank you for the comments.

Could you please double check that these criteria in URDF will be used and calculated in PyBullet?

What I mean here is: they are valid in urdf, but PyBullet will not calculate their effect.
The documentation might list them out.

When I was working on one of my project, I did met with one criteria I included in the urdf file but not used by PyBullet. (Well, I don't remember what it was but it's my case..... Also, it had been one year that I didn't use PyBullet so there might be some updates I'm not informed))

A note: (I don't have time to carefully check it through now,  but it might be helpful if you are interested in double check this problem)

Source code of the PyBullet urdf parser:
UrdfParser.h
UrdfParser.cpp

In my quick review, <safety_controller> label is actually not parsed in PyBullet.
For example, parameter lateral_friction will be parsed, because the source code have
XMLElement* friction_xml = ci->FirstChildElement("lateral_friction");

When I search k_velocity and soft, there is no appearance.

Thank you for the reply! @yanshil
Yes, you are correct. friction parameters, spring parameters, etc. have been given, but not the <safety_controller> I will edit the commit to exclude these attributes. <limit>, <calibration>, <dynamics>, and <axis> are included and I will keep them as is.

Warm Regards,
Rohit

calibration is not included in the urdf parser source codeUrdfParse.cpp.

In the pull-request you specify the limits and dynamics with some default value.

For the limits: Fusion 360 can specify limits, I would prefer to grab this data from Fusion. (But yeah I have not time to work on it now...)
For dynamics,  PyBullet have some example code suggested hard coded dampings to 0 before simulation. Setting dampings as 0 might  be fine. But.... friction? Well, I don't think it's a good idea to make it default as 0 (If I have got it right, Pybullet made the default as 0.5 ).

In summary, I think it's a good idea to also export limits data from Fusion 360 (if any).
But for the placeholder data in dynamics and dampings, I would prefer made a separate flag (something like exportPlaceHolderDynamics = True) to clarify that they do not comes from Fusion, or, just do not export them as what we have now.


Bug report - RhttpConnectionException (Autostart is broken)

Describe the bug
I have enabled Autostart after login & Autostart: Start hidden. Subsequently, when i try to send any file from my android device to the desktop, it fails with the following error [RhttpConnectionException] Connection error. URL: http://<IP_ADDRESS>:53317/api/localsend/v2/prepare-upload (hyper_util::client::legacy::Error(Connect, ConnectError("tcp connect error", Os { code: 111, kind: ConnectionRefused, message: "Connection refused" })))
To reproduce

Enable Autostart after login & Autostart: Start hidden on desktop (i am using linux kde) & reboot the system
Try sending any file from different device ( i used my android device)
The transfer won't start and it will report the error mentioned above.

Expected behavior
I have found that after booting on my desktop linux, if i click on the system tray icon and manually open localsend once & then close it again this error no longer happens. So this is most probably related to the autostart being broken, seemingly its not able to start localsend properly
Screenshots

Desktop (please complete the following information)

Smartphone (please complete the following information)
Device - Iqoo Neo 7
OS - Funtouch OS 14
Android Version - 14

我也出现了类似的状况，文件传输失败

I have this the other way around, if the app isnt open on the foreground when try to send a file from the pc to the phone.


Wrong upload path under Windows

Using the R2 Upload Action under Windows is that the file delimiter is converted to the wrong delimiter
For example, a/b is converted to a\b, causing the file to not be uploaded to the correct directory

I haven't taken into consideration running the action under Windows as most people will use Linux running this GitHub Action. However, I could add it quickly if you want.

Thank you

I faced the same problem today.
We build a ClickOnce application (which is a kind of .NET Application) and push it to R2, and then client install the application from R2.
I really want this feature too.

Sorry, I have been busy with studies but I'll push an update as soon as I can

Fixed in next release.

Thank you! It worked perfectly! @ryand56


Tests to clarify Parser/Parser0 distinction when using string interpolator

check out #341
I solved some of these but not all of these issues.


Mod button overlap with Figura in pause menu

Your mod overlaps the figura mod's button. Not sure if I should go to you or Figura about it. Or if possible some way for me to change the location

I can quite easily change the location of the button - but the problem would still be there just moved on to a solution I'd still need to fix later.
I'll look into what I can do, might make it toggleable via config (You can access the book via a keybind anyway)

Would it be possible to make it change position if another mod occupies that area? Or since it's another mod and not part of vanilla books it'd be impossible to do that

I could check if a specific mod is installed and change it - but it's quite hard to set a specific placement because quite a few mods use buttons in that vague area, so it might just end up overlapping with another mod.
I could allow the user to set their own x/y position on the screen, but that's quite a lot of manual configuring for such a simple mod.

well it isn't much of a big issue just an inconvenience. If you end up not wanting to fix it I'd understand

This is definitely something I want to try and fix, I'll probably make a config file for it where you can either change the position, or just disable them completely.

by disabling do you mean not showing the button in the pause menu?

yeah, I don't really use the key bind option so changing the position would be helpful

I am hoping to fit this into the next update in the works, 2.1.1, alongside bugfixes.
I'll add more in-depth config for the buttons in 2.1.1, and in the future I will add a proper UI for it (Like the current one, but for buttons)
I did have an idea for buttons configurable via json or similar so maybe it's time to revive that concept lol.

This issue is now fixed in the release candidate on my discord server, I'm hoping to release it to the public soon, just want to make some minor tweaks before then.
I'll close this issue for now.


"About" section content and design

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind user-interface

/kind content

/kind translation

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area blog

/area documentation

/area videos

What this PR does / why we need it:
About section redesign. This PR has About Falco and FAQ pages and styles for them
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.
:memo: Please follow instructions in the contributing guide to update your commits with the DCO
Full details of the Developer Certificate of Origin can be found at developercertificate.org.
The list of commits missing DCO signoff:

10cde82 feat: add new menu item and page, add dropdown
3e8af60 feat: add identifier field to menus in config.toml
72722bb Merge pull request #45 from akvelon/feat-dropdown-menu
b84eb6d feat: menus names, add template md files
38faaab feat: add language support to about dropdown menu
fafec47 feat: change about layout
081cd90 Merge pull request #46 from akvelon/feat-dropdown-menu
bd79444 feat: added grid mixin
e36aac4 feat: alternative css for sections to redesign
248ff3e fix: removed extra styles
347fc6b feat: renamed files
d7d9f42 Merge pull request #47 from akvelon/feat/about-alternative-css
cc966f5 feat: cards and designs import
4b70779 Merge pull request #49 from akvelon/feat/about-section-card
2d8c412 feat: added faq cards
6c5d702 fix: main restyle added
b10402d Merge pull request #50 from akvelon/feat/about-section-faq-card
1da723c feat: controllable card
550861a Merge pull request #52 from akvelon/feat/about-section-controllable-card-shortcode
cfca38e feat: about section bottom navigation
0efe693 Merge pull request #55 from akvelon/feat/about-section-controllable-card-shortcode
a76dacc feat: about baseof redesign
99b6ae4 delete test text
053571b Merge pull request #56 from akvelon/delete-test-text
a1f5e3e feat: sections redesign
af70b95 Merge pull request #57 from akvelon/feat/about-section-feedback
668f64f feat: moved footer navigation to shortcodes
229757b Merge pull request #58 from akvelon/feat/about-section-feedback
e2ca019 feat: added feedback shortcode
f83ee08 feat: added analytics script
aa93758 Merge pull request #59 from akvelon/feat/about-section-feedback
06a0c13 update content of falco.md, add img
74493e4 feat: add shortcode for 2 columns with image
3b68a7b feat: change structure, delete shortcodes from md
4fc59f4 feat: get data from shortcode
cfab702 feat: add upper card
4acf864 feat: add btn, delete aliases, add test content
f4bbbfb Merge pull request #48 from akvelon/update-about-falco-page
4082c15 fix: styles
13ac422 fix: faq section order
610942f update content of use-cases
1e64de6 Merge pull request #60 from akvelon/update-cases-page
75a6af8 fix: card text tag changed to div
1e529ec feat: add cards to falco.md
fcb5fc1 Merge pull request #61 from akvelon/feat/cards-about-falco
05ac12b feat: fixed about section home page styles
3f6e2b6 Merge pull request #62 from akvelon/feat/about-page-styles
6eb0b33 feat: faq page restyle
2044b21 Merge pull request #63 from akvelon/feat/about-section-redesign
9e5cbb1 feat: buttons redesign
c143c01 feat: btn link redesign
5861dc6 Merge pull request #65 from akvelon/feat/buttons-redesign
545f2f3 change two_column_block_img.html shortcode to show correct layout on mobile, change grid for cards
9b486c9 Merge pull request #64 from akvelon/fix/two-column-shortcode-mobile
beafb81 fix: removed unused shortcodes
e171bd4 Merge branch 'feat/about-section' of https://github.com/akvelon/falco-website into feat/about-section
2b2f204 change from png to svg, add lazy loading
cf04727 feat: added faq section content
40ee3fc Merge pull request #68 from akvelon/feat/about-faq-content
b4a1b58 feat: add lazy loading default
5f3231d Merge pull request #67 from akvelon/feat/change-png-for-svg
c92ecfe feat: card-sm class added
841ee3e feat: tabpane v1
4bb3881 feat: tabpane v2
f533527 Merge pull request #69 from akvelon/feat/tabpane
052f332 feat: updated content of about and faq sections
0bce728 fix: updated content, renamed classname to class in card
d7d322f feat: hid about section
87982ee fix: removed unused files

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

Welcome @alexakvelon! It looks like this is your first PR to falcosecurity/falco-website 🎉

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: alexakvelon
Once this PR has been reviewed and has the lgtm label, please assign jasondellaluce for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: alexakvelon, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: c88c30fae8c20f0f7425d5128ebc7930e20e01a8


"warning: the following packages contain code that will be rejected by a future version of Rust: btrfsutil v0.1"

btrfsutil 0.1.0 contains code that will become an error in the future, as reported to me by rustc 1.71.0:
$ cargo report future-incompatibilities --id 1 --package<EMAIL_ADDRESS>The following warnings were discovered during the build. These warnings are an
indication that the packages contain code that will become an error in a
future release of Rust. These warnings typically cover changes to close
soundness problems, unintended or undocumented behavior, or critical problems
that cannot be fixed in a backwards-compatible fashion, and are not expected
to be in wide use.

Each warning should contain a link for more information on what the warning
means and how to resolve it.

To solve this problem, you can try the following approaches:

- If the issue is not solved by updating the dependencies, a fix has to be
implemented by those dependencies. You can help with that by notifying the
maintainers of this problem (e.g. by creating a bug report) or by proposing a
fix to the maintainers (e.g. by creating a pull request):

  -<EMAIL_ADDRESS>  - Repository: https://github.com/cezarmathe/btrfsutil-rs
  - Detailed warning command: `cargo report future-incompatibilities --id 1 --package<EMAIL_ADDRESS>
- If waiting for an upstream fix is not an option, you can use the `[patch]`
section in `Cargo.toml` to use your own version of the dependency. For more
information, see:
https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section

The package `btrfsutil v0.1.0` currently triggers the following future incompatibility lints:
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/lib.rs:138:23
>     |
> 138 |             Err(e) => glue_error!(GlueError::Utf8Error(e)),
>     |                       ------------------------------------ in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/lib.rs:207:18
>     |
> 207 |             _ => glue_error!(GlueError::UnknownErrno(errno)),
>     |                  ------------------------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>   --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>    |
> 88 |         panic!("Glue error: {}", $glue_err);
>    |                                            ^
>    |
>   ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/common.rs:19:17
>    |
> 19 |         None => glue_error!(GlueError::BadPath(path)),
>    |                 ------------------------------------- in this macro invocation
>    |
>    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>    = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>    = note: this warning originates in the macro `glue_error` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>   --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>    |
> 88 |         panic!("Glue error: {}", $glue_err);
>    |                                            ^
>    |
>   ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/common.rs:23:19
>    |
> 23 |         Err(e) => glue_error!(GlueError::NulError(e)),
>    |                   ----------------------------------- in this macro invocation
>    |
>    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>    = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>    = note: this warning originates in the macro `glue_error` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol.rs:207:23
>     |
> 207 |             Err(e) => glue_error!(GlueError::Utf8Error(e)),
>     |                       ------------------------------------ in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:146:26
>     |
> 146 |         let uuid: Uuid = handle_uuid!(&src.uuid);
>     |                          ----------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_uuid` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:147:37
>     |
> 147 |         let parent_uuid_val: Uuid = handle_uuid!(&src.parent_uuid);
>     |                                     ------------------------------ in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_uuid` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:148:39
>     |
> 148 |         let received_uuid_val: Uuid = handle_uuid!(&src.received_uuid);
>     |                                       -------------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_uuid` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:149:36
>     |
> 149 |         let ctime: NaiveDateTime = handle_timespec!(src.ctime);
>     |                                    --------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_timespec` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:150:36
>     |
> 150 |         let otime: NaiveDateTime = handle_timespec!(src.otime);
>     |                                    --------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_timespec` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:151:40
>     |
> 151 |         let stime_val: NaiveDateTime = handle_timespec!(src.stime);
>     |                                        --------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_timespec` (in Nightly builds, run with -Z macro-backtrace for more info)
>
> warning: trailing semicolon in macro used in expression position
>    --> /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/error/glue.rs:88:44
>     |
> 88  |         panic!("Glue error: {}", $glue_err);
>     |                                            ^
>     |
>    ::: /home/josh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/btrfsutil-0.1.0/src/subvolume/subvol_info.rs:152:40
>     |
> 152 |         let rtime_val: NaiveDateTime = handle_timespec!(src.rtime);
>     |                                        --------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `glue_error` which comes from the expansion of the macro `handle_timespec` (in Nightly builds, run with -Z macro-backtrace for more info)```

Fixed on master


What is ts_with method?

Tensorflow.Binding class contains method ts_with. I can't find anything about it in the documentation.

ts_with is used in tensroflow.net source code. You should use standard using statement.

Good point, tf_with is just for internal use, will be replaced gradually.


Bug: generated source maps don't point to the exact line but to the parent selector

Hi, I have this issue that keeps bothering me on my bigger project. I have a lot of media queries in selectors and I need to be able to jump quickly to the line it is written at but source maps reference me to the parent selector.
So basically there is something wrong with how source maps are generated.
//EDIT
I think it has something to do with mixins in scss.

I'm afraid that this is out of scope. Maps, by default, have always linked to the actual CSS selector and not the line, as per the below figure.
Chrome handling a CSS file mapping automatically, as there is no map file; this links it to the sector, not the style

At the end of the day, maps are for a CSS file and not a SASS file. All the map needs to know is that "this selector can be found at this line". Not "this selector is made up of code at this line, that line and this other line".
When SASS interoperates the file, all it says is "actually... you need to look at this file and this line for this selector".
To implement a change like this SASS would need to go from mapping a single selector to mapping the selectors and the various sources of every single style. Plus browsers would need to know how to handle this array of information.
Leading on, if you wanted this feature then you'd probably be better doing a feature request with the devs at SASS themselves. They'd then have to try and change the official specification - that browsers would then have to implement. Again, they might also say this is out of scope because the file size will increase dramatically to handle every line of CSS as opposed to each selector.


Pathway missing prefix "cbd_2014_pathway:"

As found in https://github.com/trias-project/unified-checklist/issues/69, I think the prefix should be added during the mapping of this checklist. I think the problem is in dwc_mapping.Rmd#L437.

Done, see #18


request new automatic variable ${KEYWORD_NAME}

Originally submitted to Google Code by bryan.oakley on 23 Jan 2012

I think it would be useful for ${KEYWORD_NAME} defined as an automatic variable.
My use case: when developing tests we often stub out a keyword during initial development. The keyword looks something like:
| My new keyword
| | log | Not implemented yet: My new keyword | WARN
We do this so that we can run the test and get a list of warnings for all of the stubbed out keywords. This makes it really easy to create a list of keywords that need to be developed.
To make development a little easier, it would be nice if we could use a variable in the log message rather than retyping the name. For example:
| My new keyword
| | log | Not implemented yet: ${KEYWORD_NAME} | WARN

I also expected this feature to exist to build some proper automatic & context sensitive logging :/

I see the issue is closed, but I was wondering if there is any workaround to get the name of the keyword that is been currently ran?

You can use a listener to set the variable in the start_keyword method, and unset it in the end_keyword method.


[DDW-589] Refactor consolidation status screen epoch calculation

This PR refactors consolidation status screen epoch calculation to retrieve the slotId from the API.
Todo:

[x] Retrieve the slotId from the API
[x] Change the current calculation in the Block Consolidation screen

Review Checklist:
Basics

[ ] PR is updated to the most recent version of target branch (and there are no conflicts)
[ ] PR has good description that summarizes all changes and shows some screenshots or animated GIFs of important UI changes
[ ] CHANGELOG entry has been added and is linked to the correct PR on GitHub
[ ] Automated tests: All acceptance tests are passing (yarn run test)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn run dev)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn run package / CI builds)
[ ] There are no flow errors or warnings (yarn run flow:test)
[ ] There are no lint errors or warnings (yarn run lint)
[ ] Text changes are proofread and approved (Jane Wild)
[ ] There are no missing translations (running yarn run manage:translations produces no changes)
[ ] UI changes look good in all themes (Alexander Rukin)
[ ] Storybook works and no stories are broken (yarn run storybook)
[ ] In case of dependency changes yarn.lock file is updated

Code Quality

[ ] Important parts of the code are properly documented and commented
[ ] Code is properly typed with flow
[ ] React components are split-up enough to avoid unnecessary re-rendering
[ ] Any code that only works in Electron is neatly separated from components

Testing

[ ] New feature / change is covered by acceptance tests
[ ] All existing acceptance tests are still up-to-date
[ ] New feature / change is covered by Daedalus Testing scenario
[ ] All existing Daedalus Testing scenarios are still up-to-date

After Review:

[ ] Merge PR
[ ] Delete source branch
[ ] Move ticket to done on the Youtrack board

@daniloprates @DominikGuzei @MarcusHurney please DO NOT merge this one yet. I have to check something first...

@DominikGuzei this is the part which I am worried about... This screen should work regardless of the connection status 🤔
Not sure what we should do - perhaps we should keep the old code and use it when the connection is unavailable?

@daniloprates I like your changes - the only question is what numer for current epoch we show in case the API is unreachable?

@daniloprates what about system time? Do we still need to fetch it for development/demo cluster?

@daniloprates - @darko-mijic and I have discussed this and we have agreed that we should keep our current calculation of the current epoch and use it when the API info is unavailable so that it is a fallback info.

@daniloprates I have just merged @MarcusHurney PR which adds an acceptance test for the consolidation screen. Can you please merge those changes in and add a test which covers the fallback epoch calculation? 🙏

@daniloprates I have merged the latest develop - the last thing we need to do is to add the acceptance test for the fallback epoch calculation (added a TODO in the PR's description).

@daniloprates I have merged the latest develop - the last thing we need to do is to add the acceptance test for the fallback epoch calculation (added a TODO in the PR's description).

@nikolaglumac ✅

@nikolaglumac the method was using a is not working, currently:
When I inject fault named "FInjIgnoreAPI"

I'll try to find another way to test the faulty API fallback.

@daniloprates ping me if you want to discuss this.

@daniloprates can you please change the text on the button from "Support" into "Learn more"? 🙏

@daniloprates during Node-restart on Linux only we get a zero shown on the progress bar:

cc @IuliaDolishniak

@daniloprates the improvements look great! I have left only 2 small change requests.
The bad part is that I see the new test case always failing :(
Hope you can fix that! 🙏

@nikolaglumac tests are running smoothly, now


Add default package provider info for FreeBSD and DragonFly BSD

Successfully tested installing packages on FreeBSD without specifying the provider in the manifest. Default provider tested for dfly, too. It works but there's an issue with the actual package installation that I need to look into separately.

Thanks, @kraileth 🎉

Codecov Report

Merging #147 (9fa2687) into main (002a57f) will increase coverage by 2.89%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #147      +/-   ##
==========================================
+ Coverage   41.88%   44.77%   +2.89%
==========================================
  Files          45       43       -2
  Lines        1645     1541     -104
==========================================
+ Hits          689      690       +1
+ Misses        956      851     -105

Impacted Files
Coverage Δ

src/actions/package/providers/bsdpkg.rs
0.00% <0.00%> (ø)

src/actions/package/providers/mod.rs
18.18% <0.00%> (-1.82%)
:arrow_down:

src/contexts/user.rs
0.00% <0.00%> (ø)

src/actions/file/mod.rs
0.00% <0.00%> (ø)

src/actions/directory/mod.rs
0.00% <0.00%> (ø)

src/actions/package/providers/yay.rs
0.00% <0.00%> (ø)

src/actions/package/providers/winget.rs
0.00% <0.00%> (ø)

src/actions/package/providers/homebrew.rs
0.00% <0.00%> (ø)

src/atoms/command/finalizers/output_contains.rs

... and 19 more

Continue to review full report at Codecov.

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


feat: Add an option to register allowed ranges of memory

Certain kernel helpers return pointers to kernel managed memory, which the ebpf program is allowed to load and read.
In order to implement stubs for these using rbpf, we need a way to mark these ranges of memory as safe for the check_mem function.
The API specifically deals with adresses, because helpers need to be function types and not closures. This means the pointers to objects returned from them need to be static, and dealing with references to static objects gets clunky. So I have chosen to push the obtaining of the addresses into calling code.
I did do other experiments, such as trying to allow closures, but I couldn't figure out how to implement that in the jit. (I'm sure it's doable, but exhausted my yak shaving time budget for this). It also didn't end up getting rid of the 'static' requirement on references returned from helper stubs, due to the Box you have to put the closures in to store them in a hashmap.
The only real way to make this easier is to have actual maps built-in to the VM, so we can transfer the ownership of the objects to the VM. How you make that generic with regards to the map definitions in the ebpf programs is still an open question for me though.
At least with this PR I can run/test my programs and I don't have to disable the memory checks.
My apologies for the format changes: rust-analyzers autoformat seems to have different opinions than the style here.
I can try to minimize the diff if that is important to you.

Thanks a lot!

I can try to minimize the diff if that is important to you.

Yes please, that would really help for the review

I will add an end-to-end test in examples. Asserting that we can add u64s to a HashSet doesn't feel like it adds much value.
I will have to cook up a minimal ebpf program first.
My usecase is to have an easy to use way to test ebpf programs. We are building a variety of network programs, which enforce some policy and need to do a bit of packet parsing.
With rbpf I can very easily control the state of the world and inputs, and very easily test corner cases.
Since we write the programs using aya, I can also reuse all my type definitions in the tests.
I'm sure there are different ways to do this, but I liked that with rbpf we just needed a working rust toolchain to run tests.
The map interactions are the hardest bit. Currently this requires me to create static objects, which are then emitted by the helper mocks.
The rust compiler doesn't quite like this pattern, but it works.
It'd be better if there were internal map implementations, but the way the kernel api's are structured makes that harder than it should be (as I'm sure you're aware).
The main benefit of having the maps in rbpf would be that we can transfer ownership of the objects to rbpf, which removes the need for statics and would remove unsafe from caller code.
I haven't really figured out what the correct type setup would be internally though.

Thanks for the details, that's an interesting use case.

It'd be better if there were internal map implementations

No doubt about that. I'd like to have maps in rbpf, but I don't have the time to really work on the project and I don't expect to come up with an implementation myself in the foreseeable future (I understand you're not asking - I'm just clarifying). If anyone can and wants to contribute a PR for that they're welcome, obviously.

I've added an end to end example
I know what it is to be short on time.
For now, this API allows me to move forward. I might eventually give implementing maps a shot, but I also doubt I'll get to it in the coming weeks.

<Rebased with the hope that the Appveyor workflow will pass>

OK so I tried to compile the program myself, but I got mixed results.
File structure
One thing that I observe is that after your changes, we get a new warning when building the crate:
$ cargo test
warning: An explicit [[example]] section is specified in Cargo.toml which currently
disables Cargo from automatically inferring other example targets.
This inference behavior will change in the Rust 2018 edition and the following
files will be included as a example target:

* examples/ebpf-allowed-memory.rs

This is likely to break cargo build or cargo test as these files may not be
ready to be compiled as a example target today. You can future-proof yourself
and disable this warning by adding `autoexamples = false` to your [package]
section. You may also move the files to a location where Cargo would not
automatically infer them to be a target, such as in subfolders.

For more information on this warning you can consult
https://github.com/rust-lang/cargo/issues/5330

I understand this is because we don't set an edition in the Cargo.toml. I don't think editions were a thing when I created the Cargo.toml. We may want to address that in the future, but for now, it would be nice to avoid that warning. Looking at the files you added:
$ git show --pretty="" --name-only --stat -- examples/
examples/allowed-memory.o
examples/allowed_memory.rs
examples/ebpf-allowed-memory.rs

We could maybe pick up the suggestion from the warning and move the auxiliary files into a subdir? It would make it clear that the files are related to the allowed_memory.rs example, but are not example programs calling the lib themselves, and it should tame the warning?
Compiling - Part 1
So I tried to compile the eBPF program by installing the bpf-linker, and then typing the command you provided, cargo build --target=bpfel-unknown-none -Z build-std=core. But I was in rbpf's repository, and cargo tried to compile rbpf itself with this target and option, and of course it complained loudly. How exactly do you compile the program? You need a separate Cargo.toml, right? I eventually managed to run the command by adding one with:
[package]
name = "ebpf-allowed-memory"
version = "0.1.0"
edition = "2021"

[dependencies]
aya-ebpf = "0.1.0"

Coming back to my first item on the file structure, moving the example auxiliary files under their own subdirectory would allow us to add this Cargo.toml to example/allowed_memory and make it easier to recompile the example?
Compiling - Part 2
So once I had my Cargo.toml I tried the command again and hit aya-rs/bpf-linker#220, not sure if you hit that one, too. Anyway, I managed to compile by adding the --release flag.
In the end, I produced an object file that contains more eBPF functions that yours, for some reason. I have ingress_tc, but also for some reason bcmp, memcmp, and memmove in section .text, no idea why. Maybe because of the --release?
But the good thing is that ingress_tc is strictly identical to the one in your .o! :tada:
Summary
So my suggestion would be to make it easier to recompile the eBPF program, by making sure we can just run the compile command (even better, shrink it to cargo build --release, or without the --release if it's not necessary and just me hitting that bug). My changes are here: feel free to add them to your commit (or to adjust, or you can also disagree with the changes :slightly_smiling_face:)
And, nice work!

I'm sorry for the compilation troubles. I didn't get the warning when running locally, or I would have taken care of it.
You are correct that in order to compile the ebpf program you need to create a small cargo project. It can't be compiled as is. I included the source "for reference" more than anything else.
I think your suggestion is good. It makes it easier to recreate the binary.
I would still commit the binary to the repo though. The way you have done it would require you to have a functional aya environment to run the examples test, since you have to compile the ebpf program first. It's sufficiently different from the build environment of rbpf that I wouldn't go there.
I didn't bump into the bpf-linker bug, the program was compiled with --release already: I created it by making an extra entrypoint in my main project and reused its build target.


Create a vector for offline or error 404 screen

Take ideas from
Link 1 (Use it in offline mode)
Link 2
Link 3
If you need any vector or any ideas you feel free to contact any mentor.

Can i work on this issue?

@anushbhatia  May I?


proposal: all: end support for macOS 11 in Go 1.25

Proposal Details
Go added support for macOS 15 that was publicly released this September. After internal discussion, we believe the summer of 2025 will be a good time to drop support for macOS 11. The last security update it received was in September 2023.
On behalf of @golang/release, I propose we announce the end of support in the Go 1.24 release notes, and disable the builder for Go 1.25. Go 1.24 (security patches until Feb 2026) will be the last release with macOS 11 support.
For context, https://github.com/golang/go/issues/64207#issuecomment-1843590873 contains some history as well as future patterns if we keep the same cadence.
CC @golang/darwin.

Related Issues and Documentation

all: end support for macOS 10.15 in Go 1.23 #64207 (closed)
end support for macOS 10.13 and 10.14 in Go 1.21 #57125 (closed)
doc/go1.14: preannounce dropping macOS 10.11 support
doc/go1.16: preannounce dropping macOS 10.12 support
all: announce end of support for old macOS releases #23011
Go 1.23 Release Notes > Ports > Darwin
x/build/internal/task: update the minimum macOS version in the Go 1.21 installer #58105 (closed)
x/build: disable darwin-amd64-10_11 builder on master branch #37425 (closed)
doc: require macOS 10.12 or later
doc: update the minimum supported macOS version to 10.11

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.

This seems like a routine deprecation. The number of people using macOS 11 seems to be small.
(It's too bad we don't have telemetry on OS versions. @adonovan is going to file a proposal to gather that.)

Have all remaining concerns about this proposal been addressed?
The proposal is to announce the end of support for macOS 11 in the Go 1.24 release notes, and disable the builder for Go 1.25. Go 1.24 (security patches until Feb 2026) will be the last release with macOS 11 support.

Based on the discussion above, this proposal seems like a likely accept.
The proposal is to announce the end of support for macOS 11 in the Go 1.24 release notes, and disable the builder for Go 1.25. Go 1.24 (security patches until Feb 2026) will be the last release with macOS 11 support.

Pre-announcement is added to 1.24 release notes. Move to 1.25.


Delete old e2e tests with massive checked-in IR files

These were mostly added years ago before we had mechanisms for testing
models end-to-end. The tests here don't use our standard test
infrastructure and instead JIT-compile with iree-run-mlir. This is
nice to provide some small sample programs that can be iterated on
without having to think about build systems, but is not appropriate for
massive IR files. Now we have a better way. There are already
(CMake-only) end-to-end tests
in this directory
that compile using the build system with the accompanying caching,
dependency analysis and parallelism and then the test is only actually
executing the module. The immediate motivation here is to delete the
resnet50 test that is our slowest on every platform and keeps timing
out or needing to be disabled.

Putting those who originally added these models as reviewers (plus Ben, who usually has opinions on this sort of thing

Also FYI @bjacob since you were complaining about this slow test :-)

Oh... these are kind of useful tests (Sorry didnt see this before it landed).

Can you elaborate?

I have learnt how to get these benchmarks files and run them locally, but they are too many things involved to run them locally within a development cycle. These tests provide a reasonable basic testing on "realistic" things rather than lit-testing. If these dont pass then there is no point even putting up a draft PR/PR to run the benchmarks on CI. Some things need this kind of size for testing. We dont want too many of them (and I actually dont know why resnet is so slow), but I prefer having them as tests/e2e/ tests.

Sorry didnt see this before it landed

No worries. Sorry I didn't let it sit for a bit longer. I thought I'd looped in the people who would be concerned. The resnet test was repeatedly failing on CI and sending failure notifications and Benoit was also in the process of reworking test timeouts partially to address this particular tests, so I rushed things a bit.
I still think we shouldn't be checking in these giant IR files. They're not really "source code" that is human maintainable. That said, your use case seems important, so let's address it. It sounds like what you want is some largish integration tests that are easy to run. I think we have a few persistent themes here:

Giant IR files aren't really human-maintainable.
When debugging at scale, having the tests trying to do everything all together causes issues (see, for instance the recent time debugging the memory error where we couldn't even tell if it was in the compiler or runtime).
Having sources for tests hosted elsewhere adds friction to local development.
Having the build system automagically fetch things over the network causes reliability and hermeticness problems.
Having tests themselves fetch things over the network has the same issues (like we have with mnist_train_test today).

Just to confirm, the three files here were fulfilling a role that is not satisfied by the remaining smaller IR samples, correct?


chore: update carbon to 10-27

Updates to Carbon 10-27 and related updates
M       package.json
M       packages/core/package.json
M       packages/experimental/package.json
M       yarn.lock

I recommend marking the PR as a feat instead of a chore to ensure the correct version bump is calculated for consumers.

I recommend marking the PR as a feat instead of a chore to ensure the correct version bump is calculated for consumers.


mergity test

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Commit Message: mergity
Additional Description: mergity test
Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]

/appove

/approve