bad discord bot permissions makes matrix bot irrevocably broken

I added the discord bot to a (discord) server and bridged a text channel, but didn't give it the proper permissions.  This caused the bridge to give the following traceback:
Traceback (most recent call last):
  File "/mnt/drive/space/mx-disc-appservice-env/lib/python3.9/site-packages/bottle.py", line 868, in _handle
    return route.call(**args)
  File "/mnt/drive/space/mx-disc-appservice-env/lib/python3.9/site-packages/bottle.py", line 1748, in wrapper
    rv = callback(*a, **ka)
  File "/home/z/matrix-discord-bridge/appservice/misc.py", line 28, in wrapper
    return fn(self, *args, **kwargs)
  File "/home/z/matrix-discord-bridge/appservice/appservice.py", line 87, in receive_event
    self.handle_event(event)
  File "/home/z/matrix-discord-bridge/appservice/appservice.py", line 66, in handle_event
    func(obj)
  File "/home/z/matrix-discord-bridge/appservice/main.py", line 109, in on_message
    webhook = self.discord.get_webhook(
  File "/home/z/matrix-discord-bridge/appservice/main.py", line 616, in get_webhook
    webhooks = self.send("GET", f"/channels/{channel_id}/webhooks")
  File "/home/z/matrix-discord-bridge/appservice/misc.py", line 49, in wrapper
    raise RequestError(
errors.RequestError: Failed to get response from 'https://discord.com/api/v8/channels/421097709643104260/webhooks?':
b'{"message": "Missing Permissions", "code": 50013}'
<IP_ADDRESS> - - [09/Jun/2021 03:18:27] "PUT /transactions/77?access_token=abcd1234 HTTP/1.1" 500 778

After this the matrix bridge would relay messages from discord to matrix, but not back the other way.  Restarting the service did not fix it.  This gave me the bright idea to rm my .db file and now it won't work at all...  It doesn't remember the association of the discord text channel with the old matrix room (expected) but when I try to re-bridge I get the following traceback
Traceback (most recent call last):
  File "/mnt/drive/space/mx-disc-appservice-env/lib/python3.9/site-packages/bottle.py", line 868, in _handle
    return route.call(**args)
  File "/mnt/drive/space/mx-disc-appservice-env/lib/python3.9/site-packages/bottle.py", line 1748, in wrapper
    rv = callback(*a, **ka)
  File "/home/z/matrix-discord-bridge/appservice/misc.py", line 28, in wrapper
    return fn(self, *args, **kwargs)
  File "/home/z/matrix-discord-bridge/appservice/appservice.py", line 87, in receive_event
    self.handle_event(event)
  File "/home/z/matrix-discord-bridge/appservice/appservice.py", line 66, in handle_event
    func(obj)
  File "/home/z/matrix-discord-bridge/appservice/main.py", line 100, in on_message
    self.handle_bridge(message)
  File "/home/z/matrix-discord-bridge/appservice/main.py", line 69, in handle_bridge
    self.create_room(channel, message.sender)
  File "/home/z/matrix-discord-bridge/appservice/main.py", line 206, in create_room
    resp = self.send("POST", "/createRoom", content)
  File "/home/z/matrix-discord-bridge/appservice/misc.py", line 49, in wrapper
    raise RequestError(
errors.RequestError: Failed to get response from 'http://<IP_ADDRESS>:8008/_matrix/client/r0/createRoom?access_token=1234abcd':
b'{"errcode":"M_ROOM_IN_USE","error":"Room alias already taken"}'
<IP_ADDRESS> - - [09/Jun/2021 03:32:57] "PUT /transactions/113?access_token=abcd1234 HTTP/1.1" 500 779

Which seems to prevent it from bridging at all.  I tried restarting synapse and the discord bridge.  I can't remove the bot from the existing bridged rooms because we have the same permissions level (admin), so I don't even know how to recover from this bug short of resetting my synapse server, which I would like to avoid.  Any help is appreciated

You didn't need to delete the db at all, since the appservice would keep retrying and eventually succeed when it got the proper permissions for webhooks.
For the room, kicking the appservice won't help this case anyways since the room has already been created. You can manually create the entry to add a relation between the discord channel and matrix room:
Assuming the discord channel id to be<PHONE_NUMBER>43104260, the appservice would've created a room with the alias #_discord_421097709643104260:domain.tld. So you just need to get the room ID of that alias from your client (In element just click on the room info and find "This room's internal ID" which looks something like !djsandjkasndj:domain.tld.
Now, run the following commands:
-> sqlite3 bridge.db
SQLite version 3.35.5 2021-04-19 18:32:05
Enter ".help" for usage hints.
sqlite> INSERT INTO bridge (room_id, channel_id) VALUES ("!djsandjkasndj:domain.tld", "421097709643104260")
   ...>
# Send Ctrl + D to indicate EOF and finish the transaction.

But you'll have another issue as the bridge won't know how many Discord users have been bridged to matrix. If only a few dummy accounts have been created then it should be relatively easy to fix too:

Find the users added/invited to the already created room and get their MXID's. Their MXIDs look like @_discord_781097709743105260:domain.tld.

Run the following commands for each MXID (The part after discord_ is the discord ID):

-> sqlite3 bridge.db
SQLite version 3.35.5 2021-04-19 18:32:05
Enter ".help" for usage hints.
sqlite> INSERT INTO users (mxid) VALUES ("@_discord_781097709743105260:domain.tld")
   ...>

There is no need to update the displaynames/avatar urls of these db users since the appservice will sync them.�

Awesome, I'll try that later today.  On a side note, is webhooks the only permission my discord bot needs?  I assumed it would need send/read messages, no?  Or is it assumed that that is handled by general server permissions/whatever role the discord bot has?

I think only "Manage webhooks" should be enough given that the bot has read access to the channel, since it's sending and deleting messages from it's own webhook, not anything else.
Other than that you need privileged intents enabled https://discordpy.readthedocs.io/en/latest/intents.html#privileged-intents, they're required for the bot to receive username/avatar update events.

Hmm, I still get the same traceback as before (last one).  To be precise, I re-deleted my .db and started main.py to make sure the .db was fresh, stopped main.py, added entries with sqlite3, then restarted main.py.

Something must've gone wrong in the first room ID step, since the appservice first checks if the given channel is already bridged, and proceeds only if it isn't bridged https://github.com/git-bruh/matrix-discord-bridge/blob/3a526f8767071e4580a28b8996b8a07604f1cda3/appservice/main.py#L57
Could you confirm the output of this command ?
SQLite version 3.35.5 2021-04-19 18:32:05
Enter ".help" for usage hints.
sqlite> SELECT * FROM bridge
   ...>
!5bg3zjFEMuDOrLo6:domain.tld|813202331872788490
!cAof7rphhaWHIAZs:domain.tld|813119972486283325

Make sure that the channel ID you entered is 18 digits long.

Here is the output:
SQLite version 3.35.5 2021-04-19 18:32:05
Enter ".help" for usage hints.
sqlite> SELECT * FROM bridge
   ...>
!jRVqCBXZjSoAoSGzNL:domain.tld|613148461042237486

(I replaced the actual domain with "domain.tld")
I double checked, and the room id is in fact:  !jRVqCBXZjSoAoSGzNL:domain.tld
discord channel id (all 18 digits):<PHONE_NUMBER>42237486
Originally, I had multiple bridges, but I was trying to just get one bridge up and running.  Do you think the problem could be that it sees my other !bridge commands from the 1:1 chat history and tries to recreate them all?  The bridge isn't fixed in the room I DID try to rebridge

Oh wow, all the messages went through at once.  Now messages come through just fine.  Thanks for all your help!!  I hope I can contribute in the future.

That's great to hear! Feel free to open issues in the future aswell.


lock TimeAgo dependency to previous version

closes #179

hotfix rolled out which cherry picked commit so this should be merged with a merge commit instead of squashing


feat: add hashicorp/packer-plugin-sdk/packer-sdc

hashicorp/packer-plugin-sdk/packer-sdc: The packer software development command is meant for plugin maintainers and Packer maintainers, it helps generate docs and code
$ aqua g -i hashicorp/packer-plugin-sdk/packer-sdc

Thank you always!

Released. https://github.com/aquaproj/aqua-registry/releases/tag/v3.72.0


Head turns invisible when Essential Mod is enabled

I noticed a bug where my head would turn invisible, and it seems to only happen when this mod and Essential are both enabled. Disabling Essential makes the head render normally.
I have no idea why this happens, as i don't even use Essential cosmetics or anything of the sort.

I apologize for any lack of information or if this has already been reported before

Yea this is an essentials issue under some circumstances as far as I know. Since it's closed source, and the bug is probably on their end, not much I can do about it.

Hi, one of the Essential devs here. We have looked at this internally and came to the conclusion that this is best fixed on FPM's end, so I'm here to explain what, how and why we do for this (and probably actually also #315 if I'm not mistaken) to happen and what can be done about it.
I happen to be the person that implemented the relevant feature in Essential, and I usually give much thought to third-party mod compatibility in anything I implement, so if any of my decisions in how exactly I have implemented something are unclear, feel free to ask for clarification, there's a high chance I've considered alternatives and can give an explanation for why I chose the particular approach.
The code relevant for these two bugs is a mixin in Essential that aims to fix a vanilla deficiency: Not all variables in ModelPart are reset before each frame, only those which vanilla changes itself will also be reset by vanilla. This is of importance to Essential because it implements emotes which may very well change some of those variables and so it also needs to make sure they go back to their original values when the emote ends / another player is rendered.
The way we solve this problem is with a relatively simple mixin into HumanoidModel at HEAD of setupAnim that stores the current values for all the variables on first invoke, and then restores those default values on every subsequent invoke. Looks approximately like this (PlayerPose is a POJO storing all the variables for all the model parts and PlayerPoseKt copies to/from that pojo from/onto the MC types):
    @Unique
    private PlayerPose resetPose;

    @Inject(method = "setupAnim", at = @At("HEAD"))
    private void resetPose(CallbackInfo ci) {
        HumanoidModel model = (HumanoidModel) (Object) this;

        if (resetPose == null) {
            resetPose = PlayerPoseKt.toPose(model);
        } else {
            PlayerPoseKt.applyTo(resetPose, model);
        }
    }

The setupAnim method is of special significance to this issue because that's where vanilla sets up all the variables it uses. As such, any mod that wishes to modify one of the variables which vanilla uses must necessarily do it at some point towards the end of that method or after that method was called but never at the start of the method nor before the method is called.
And this leads me to the main assumption I'm making (and if you wish I can further elaborate on why I think this must be the case for independent mods to be compatible) which FPM violates: The same should be true for variables that vanilla doesn't touch. Mods should not make any assumption about the value of these variables until somewhere in the middle of setupAnim and any mod may overwrite their values back to the defaults before that point (in fact, every mod must do so, otherwise if they're the only mod it's never getting reset; FPM does that right at the end of the render method; Essential does this right at the start of setupAnim, basically where vanilla does it as well).
So fixing both issues should be as simple as moving FPM's modification of the z value to the same place where vanilla modifies the other variables: In HumanoidModel.setupAnim, ideally right below the lines where it sets this.head.y.
Thereby Essential won't overwrite it because it already reset the value at the start of the method (hopefully fixing #315) and Essential's reset-values won't be incorrect (fixing this issue).
The latter could also be worked around on Essential's end by reading the reset-values earlier (but who's to say when would be the most appropriate time to do that? we might then do it too early for some other mod; I'd argue the place where it currently does so is already the most reasonable place to do so) or by hard-coding the values but that has the same issue of wiping legitimate modifications of another third-party mod and more importantly, it cannot fix the first issue.
We also can't really move our resetting code to run before FPM's setting code because that's somewhat of a moving target: If another third-party mod comes along and modifies the variables at yet another non-compliant location, we might have to move again, or worse, there might not be any location where we could reset at the right time for both FPM and the third-party mod (such considerations are what lead me to the assumption/assertion I stated above).
Hence why I think this should be fixed on FPM's end (by not violating above assumption/assertion).

Thanks for the insight. So basically it boils down to 2 mods caching the value but at different times, causing one mod to cache some temporary value as truth. I don't "really" change the z value, and instead, keep the real value around, but that doesn't help when Essential picks up the wrong one. Please give it a try with the version I just pushed, where I moved it to setupAnim for "HumanoidModels". For anything else, it will still set the hidden flag during render(no shared setupAnim location).

Hi, another Essential dev here. This fix works, fixing this issue as well as #315. Thanks.

1.18.2 too plz?

Ehhh, sometime later when 1.18 gets updated. But 1.18 is not a vital version anymore so it will get updates less often.

Noticed this happening on 1.19.2 or maybe it's not the Essentials mod? could it be Cosmetica?

The fix is currently only in the 1.19.3 and 1.19.4 version.

Is there a possibility that you can make an option to straight up turn off your player head when in first person?
I currently have to use / stick with the unpatched version of both essential and first person to get my desired result.

Is there a possibility that you can make an option to straight up turn off your player head when in first person?

Thaaats the entire point of this mod? If the head is visible while in first person, then you have some incompatible mod installed. And this issue is the reverse, that the head was staying invisible when it shouldn't(fixed in 1.19.3/1.19.4).

My apologies. It would be ' Kelvin's Better Player Animations '. Had that from the start using the First Person mod and figured the head visible was normal. Great work and sorry to bother!

Backported the fix now to 1.19.2 and 1.18.2. Closing the issue.


Save user-uploaded label calcification rates per source

At export time, when a custom rates table is uploaded, don't just use the table for that export; save the table for future usage in that source. Enhancement of #372, and likely required for #376.
The simplest thing to do is to only save one custom table: the last one used in that source. This seems like it would be sufficient for many cases.
It should be possible to give a name to the table, specifying a date or anything else one might want there. That way, it can be determined whether the table is out of date and/or suitable for that export operation. It should also be possible to re-download the saved table as CSV. If there is a table rename feature, it should come with a warning about traceability - exporting the same table at different times under different names can cause confusion.
One extra design detail here: permissions in the export form. The ability to upload and save a table should be limited to those with Edit or Admin access to the source. For anyone else (View access, or visitors to a public source), there would only be the option to use a previously uploaded table; if there is no such table, then they have to pick one of CoralNet's default tables to export instead.

Done in PR #404.


Alarmdecoder binary sensors "flap" between off and on when more than 5 zones are open

Home Assistant release with the issue:

0.79.2
Last working Home Assistant release (if known):
Unknown
Operating environment (Hass.io/Docker/Windows/etc.):

Docker
Component/platform:

binary_sensor.alarmdecoder
Description of problem:
The state of these sensors "flap" between on and off when too many zones are open. My home has 20 alarmdecoder zones defined. After 4-5 windows/doors are opened, the zone status of those sensors flap between off and on.
My sense is that the state automatically moves back to off after a short period of time unless the alarm decoder sends an "on" status. It can take alarm decoder 10-30 seconds to iterate over all my open zones which is longer than the sensor is expecting and so it's setting them back to closed. The zone is set back to open when the alarmdecoder device loops around and reports the open/on status again.
The "flapping" stops when I close all zones up to around 3 or 4.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
  device:
    type: serial
    path: '/dev/ttyUSB0'
    baudrate: 115200
  panel_display: Off
  zones:
    '01':
      name: 'Heat Detector'
      type: 'heat'
    '02':
      name: 'Front Door'
      type: 'door'
    '03':
      name: 'Big Garage Door'
      type: 'door'
    '04':
      name: 'Small Garage Door'
      type: 'door'
    '05':
      name: 'Big Garage Windows'
      type: 'window'
    '06':
      name: 'Small Garage Windows'
      type: 'window'
    '07':
      name: 'Small Garage Hallway Windows'
      type: 'window'
    '08':
      name: 'Guest Suite Windows and Door'
      type: 'opening'
    '09':
      name: 'Dining Room Door'
      type: 'door'
    '10':
      name: 'Pantry Window'
      type: 'window'
...

Traceback (if applicable):
N/A

Additional information:
Ideally a configurable "timeout" can be added to wait for a longer period of time before reverting the sensor to off. It seems to be around 10-15 seconds currently. Thereby allowing enough time for the alarmdecoder device to loop through the open zones.

You might be interested in the parameters that were added to the alarmdecoder component by @digiblur recently - relayaddr and relaychan (they are described on the component doc.
Essentially you can do some "advanced" configuration with alarmdecoder to set up virtual relays that get triggered on zone events (e.g. open/close). This provides a much more reliable mechanism to determine zone status since it's event based. I followed the instructions here (this is the only place I could find that describes it) to set it up on my Vista 20P panel and alarmdecoder, and it works great.

One day I will get around or maybe someone else will bear me to it and add MQTT publishes from the Alarmdecoder device itself. It's all in GitHub in Python after all.

Thanks for the information! It looks like with a little panel programming I can achieve what I'm looking for. I'll close this one out.


Remove invalid execution time test case

Summary
Since job costs are no longer limited by program cost, this test case is no longer needed
Details and comments
Fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.3%) to 64.27%

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
3146

Relevant Lines:
4895

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.3%) to 64.27%

Totals

Change from base Build<PHONE_NUMBER>:
0.3%

Covered Lines:
3146

Relevant Lines:
4895

💛  - Coveralls


Fixes for #5038

We were using the deltas to simulate human behavior and shouldn't be applied to altitude.

Polyline Walker has real problems mjm

Yeah, I saw @Anakin5 s comments about the polywalker. Any chance you can take a gander at that one?

Set poly to fetch the last known alt if it cannot get it through self.polyline.get_alt
Still need to add the pause/unpause to prevent it from teleporting.

Can you rollback the changes on Polyline while you come up with a fix ? For now it is not usable at all and some of us use it in our config.
Thank you

@Anakin5 Could you try this, I'm at work and catch test anything :-1:

@mjmadsen  The polyline walker is not working as expect, right side is dev branch, left side is master branch.

Ugh.

@solderzzc Was that with the recent polyline_walker I had up? I had to revert because of some conflicts.

there are some other extra fixes that you were working on here... I was referring only at the .get_alt() part...

@mjmadsen
This is not needed...

Still need to add the pause/unpause to prevent it from teleporting.

As long as we can get it working right :+1:

@mjmadsen remaining taks not taken over somewhere else from this PR are:

the  alt_delta
the random_lat_long (factor 5..)

@mjmadsen will you do them in a different PR?

Can do. What did you put in for the alt delta range? If it's small I could see it being somewhat more human like (swinging arms when walking). #5140

@mjmadsen that is purely in StepWalker... i did not change..

@th3w4y Took a look at it and it's a variance of .4m. I don't think that's unreasonable so I won't bother removing it from StepWalker

@mjmadsen I agree

@solderzzc Thanks for your screenshot...
I believe the bug was in the cache validation.. https://github.com/PokemonGoF/PokemonGo-Bot/pull/5135/commits/8f7f22c90e92ccafafa4956ba006624c3f90ab5e
I have fix in the PR https://github.com/PokemonGoF/PokemonGo-Bot/pull/5135


Report example out of date

See: https://github.com/jayzeng/virustotal_apiwrapper/blob/master/Examples/report.php#L5
This class doesn't exist.

Good catch, I will purge that file


save_pretrained has unuseful   mode.safetensors,  lead to   load error

System Info
- `Accelerate` version: 0.29.3
- Platform: Linux-3.10.0-1160.el7.x86_64-x86_64-with-glibc2.35
- `accelerate` bash location: /opt/conda/bin/accelerate
- Python version: 3.10.13
- Numpy version: 1.26.4
- PyTorch version (GPU?): 2.1.2+cu121 (True)
- PyTorch XPU available: False
- PyTorch NPU available: False
- PyTorch MLU available: False
- System RAM: 2013.27 GB
- GPU type: NVIDIA A800-SXM4-80GB
- `Accelerate` default config:
        Not found

Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[ ] One of the scripts in the examples/ folder of Accelerate or an officially supported no_trainer script in the examples folder of the transformers repo (such as run_no_trainer_glue.py)
[X] My own task or dataset (give details below)

Reproduction
def save_model(accelerator,model,completed_steps,args):
accelerator.wait_for_everyone()
state_dict=accelerator.get_state_dict(model)
# ##M1 end
logger.debug('save_model on unwrap_model')
unwrapped_model = accelerator.unwrap_model(model)
logger.debug('save_model on save_pretrained')
save_pretrained_dirpath=os.path.join(args.output_dir, f"final_step_{completed_steps}")
unwrapped_model.save_pretrained(
save_pretrained_dirpath,
is_main_process=accelerator.is_main_process,
save_function=accelerator.save,
state_dict=state_dict
)
Expected behavior

use zero3,  is  save mode like this method,and  has the  model.safetensors,  when  load ,will raise error,like thie
model = AutoModelForCausalLM.from_pretrained(
model_path,
trust_remote_code=True,
# device_map='auto'
).to('cuda:0')
error msg like thie
ize mismatch for model.layers.31.mlp.gate_proj.weight: copying a param with shape torch.Size([0]) from checkpoint, the shape in current model is torch.Size([11008, 4096]).
if remove model.safetensors,will successed

Hi @zheng5yu9, could you share a minimal reproducer ? The reproducer you shared is not very helpful. Thanks !

I got same problem.
I saved the model using the following codes:
accelerator.unwrap_model(model).save_pretrained(
    args.save_model_dir,
    is_main_process=accelerator.is_main_process,
    save_function=partial(accelerator.save_model, safe_serialization=True),
    state_dict=accelerator.get_state_dict(model),
)

When I tried model loading, I got the following error:
---------------------------------------------------------------------------
SafetensorError                           Traceback (most recent call last)
Cell In[34], [line 2](vscode-notebook-cell:?execution_count=34&line=2)
      [1](vscode-notebook-cell:?execution_count=34&line=1) from transformers import AutoModelForSequenceClassification
----> [2](vscode-notebook-cell:?execution_count=34&line=2) model = AutoModelForSequenceClassification.from_pretrained("./model/20240503-035050", attn_implementation="flash_attention_2", use_safetensors=True, low_cpu_mem_usage=True)

File /opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:563, in _BaseAutoModelClass.from_pretrained(cls, pretrained_model_name_or_path, *model_args, **kwargs)
    [561](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:561) elif type(config) in cls._model_mapping.keys():
    [562](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:562)     model_class = _get_model_class(config, cls._model_mapping)
--> [563](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:563)     return model_class.from_pretrained(
    [564](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:564)         pretrained_model_name_or_path, *model_args, config=config, **hub_kwargs, **kwargs
    [565](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:565)     )
    [566](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:566) raise ValueError(
    [567](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:567)     f"Unrecognized configuration class {config.__class__} for this kind of AutoModel: {cls.__name__}.\n"
    [568](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:568)     f"Model type should be one of {', '.join(c.__name__ for c in cls._model_mapping.keys())}."
    [569](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/models/auto/auto_factory.py:569) )

File /opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3456, in PreTrainedModel.from_pretrained(cls, pretrained_model_name_or_path, config, cache_dir, ignore_mismatched_sizes, force_download, local_files_only, token, revision, use_safetensors, *model_args, **kwargs)
   [3436](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3436)     resolved_archive_file, sharded_metadata = get_checkpoint_shard_files(
   [3437](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3437)         pretrained_model_name_or_path,
   [3438](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3438)         resolved_archive_file,
   (...)
   [3448](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3448)         _commit_hash=commit_hash,
   [3449](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3449)     )
   [3451](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3451) if (
   [3452](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3452)     is_safetensors_available()
   [3453](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3453)     and isinstance(resolved_archive_file, str)
   [3454](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3454)     and resolved_archive_file.endswith(".safetensors")
   [3455](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3455) ):
-> [3456](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3456)     with safe_open(resolved_archive_file, framework="pt") as f:
   [3457](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3457)         metadata = f.metadata()
   [3459](https://vscode-remote+ssh-002dremote-002b13-002e209-002e146-002e199.vscode-resource.vscode-cdn.net/opt/conda/lib/python3.10/site-packages/transformers/modeling_utils.py:3459)     if metadata.get("format") == "pt":

SafetensorError: Error while deserializing header: InvalidHeaderDeserialization

As @zheng5yu9  said, I could load the model by removing model.safetensors file. But I don't know it is safe way.

Hi @Kyeongpil, you don't need to specify the save function, just do that:
accelerator.unwrap_model(model).save_pretrained(
    args.save_model_dir,
    is_main_process=accelerator.is_main_process,
    state_dict=accelerator.get_state_dict(model),
)

Hi @Kyeongpil, is the issue solved ? Thanks !

@SunMarc Sorry for my late reply, and thank you for your consideration :)
As you mentioned, save_function is not necessary. However, the issue is not solved.
Whenever I trained the model using Accelerate (with FSDP), I have to remove model.safetensors to successfully load the model without the error SafetensorError: Error while deserializing header: InvalidHeaderDeserialization.

Thanks for the update ! Could you share a minimal reproducer if possible ? That's strange that you get both the entire model model.safetensors and the sharded model model-xxxx-of-xxxx.safetensors in the same folder.

@SunMarc Sure, Here is the minimal code (I omit the irrelevant code lines)
I used meta-llama/Meta-Llama-3-8B as a fine-tuning model.
def save_model(
    model: PreTrainedModel, tokenizer: PreTrainedTokenizer, accelerator: Accelerator, save_dir: str, num_steps: int
):
    torch.cuda.empty_cache()
    accelerator.wait_for_everyone()

    save_dir = os.path.join(save_dir, f"checkpoint-{num_steps}")
    accelerator.unwrap_model(model).save_pretrained(
        save_dir, is_main_process=accelerator.is_main_process, state_dict=accelerator.get_state_dict(model)
    )
    tokenizer.save_pretrained(save_dir)

def train(accelerator: Accelerator, args: Namespace):
    ...

    with accelerator.main_process_first():
        model: PreTrainedModel = AutoModelForSequenceClassification.from_pretrained(
            args.model,
            trust_remote_code=True,
            low_cpu_mem_usage=True,
            use_cache=False,
            device_map=accelerator.device,
            attn_implementation="flash_attention_2",
            num_labels=1,
            pad_token_id=tokenizer.pad_token_id,
        )
        model.gradient_checkpointing_enable()

    model = accelerator.prepare(model)

    ...

    save_model(model, tokenizer, accelerator, args.save_model_dir, num_steps)

    accelerator.end_training()

Hey, is there any updates on the issue? I have been facing the same issue

Hey, is there any updates on the issue? I have been facing the same issue


Prepare repository for control-plane-operator extraction

The control plane operator inevitably must be extracted into its own Git repository
and versioned with OCP. To achieve this, we need to prepare the current monorepo with
the right set of discrete Go modules to make sure external Go consumers (i.e. the control
plane operator) can express dependencies without taking on an unreasonable transitive
dependency graph.
Here is the proposed logical layout for the Git repositories, where each root
node is a Go module with a subtree representing its HyperShift dependencies:
openshift/hypershift
├── api
├── cmd
|   ├── github.com/openshift/hypershift/api
|   └── github.com/openshift/hypershift/support
├── hypershift-operator
|   ├── github.com/openshift/hypershift/api
|   └── github.com/openshift/hypershift/support
├── ignition-server
|   ├── github.com/openshift/hypershift/api
|   └── github.com/openshift/hypershift/support
└── support

openshift/hypershift-control-plane
├── control-plane-operator
|   ├── github.com/openshift/hypershift/api
|   └── github.com/openshift/hypershift/support
└── hosted-cluster-config-operator
    └── github.com/openshift/hypershift/api

In this model, each discrete component gets its own dependency graph.
To transition towards the end state, it should be possible to extract the Go
modules in-tree within the current openshift/hypershift Git repository. The
transitional layout would look like this:
├── api
|   └── go.mod
├── cmd
|   └── go.mod
├── hypershift-operator
|   └── go.mod
├── ignition-server
|   └── go.mod
├── control-plane-operator
|   └── go.mod
├── hosted-cluster-config-operator
|   └── go.mod
└── support
    └── go.mod

The transitional layout can be achieved incrementally by approaching each module
starting with the leafs. Here's a possible timeline:

Extract the api support, and control-plane-operator modules (https://github.com/openshift/hypershift/pull/425).
Extract the hosted-cluster-config-operator module.
Extract the ignition-server module.
Extract the cmd module.
Extract the hypershift-operator module.
Delete the /thirdparty directory (these usages should have been factored away by this point).
Delete the certs, releaseinfo, and version directories (by this point all the modules will be linking to the support module).
Delete /go.mod and /vendor as the root module no longer actually contains any Go packages.

There's another opportunity the module refactor presents: we can introduce control-plane-operator modules per OCP version which encapsulate the version-dependent Go dependencies and logic (and which depend on a shared module for common stuff). Then it seems possible to continue with the monorepo with an image containing binaries compatible with all supported OCP versions.

Another alternative would be to develop and maintain OpenAPI v3 specs for these APIs and use https://github.com/deepmap/oapi-codegen to generate the types. I've done some experiments with this by porting the contents of CRD definitions into the OAPI3 spec (which requires adding some required stuff to the components field, etc.) but this revealed the OpenAPI data embedded in CRDs can be inconsistent in ways that lead to useless output. For example, metadata fields are sometimes specified as type: object with no properties, and sometimes via OpenAPI additionalProperties specifications.
However, if it's actually possible in principle to get CRDs generated by controller-gen to emit stuff that could be reliably transformed into OpenAPI v3 spec that can be reliably transformed into Go objects, that would be very interesting. A lot of ifs...


The "Collection expressions" page lacks an example of arr is [1, 2, ..].

Describe the issue or suggestion
There is the syntax:
int[] arr = [1, 2, 3];
if (arr is [1, 2, ..])
{
    Console.WriteLine("arr starts with 1, 2");
}

But the "Collection expressions" page lacks an example of this.

Oh, that's not a collection expression, it's a pattern matching expression.


soc: nuvoton: numaker: add support for m2l31x series

This PR is to add Nuvoton NuMaker M2L31X SoC series.
This PR depends on https://github.com/zephyrproject-rtos/hal_nuvoton/pull/9

Hi @nordicjm , @fabiobaltieri,
Rebase to sync with main branch  to resolve merge conflict of CMakeLists.txt & Kconfig of drivers/flash.


Optimize #5

This PR removes svg width & height values, redundant quotes & spaces. There are other optimizations possible, but since you don't want any spoilers I'll leave it like this

Whoops! My #5 was totally out of date on here, I'm not actually using svg at all, I'll close this and update it with my current solution
This is the perfect type of PR for this repo though, thanks!


Error when running docker compose up on main branch.

Forked repo.
Ran docker compose up which seemed to work  # Note, I did not yet init the database.
Ctrl-C, gracefully shut down.
Ran docker compose up again

> docker compose up
[+] Running 2/0
 ⠿ Container dust-api    Created                                                                  0.0s
 ⠿ Container dust-front  Created                                                                  0.0s
Attaching to dust-api, dust-front
dust-front  |
dust-front  | > dev
dust-front  | > next dev
dust-front  |
dust-front  | ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000
dust-front  | event - compiled client and server successfully in 445 ms (209 modules)
dust-front  | wait  - compiling /_error (client and server)...
dust-front  | event - compiled client and server successfully in 175 ms (210 modules)
dust-front  | warn  - Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/basic-features/fast-refresh#how-it-works
dust-front  | wait  - compiling / (client and server)...
dust-front  | event - compiled client and server successfully in 507 ms (897 modules)
dust-front  | [next-auth][warn][EXPERIMENTAL_API]
dust-front  | `unstable_getServerSession` is experimental and may be removed or changed in the future, as the name suggested.
dust-front  | https://next-auth.js.org/configuration/nextjs#unstable_getServerSession}
dust-front  | https://next-auth.js.org/warnings#EXPERIMENTAL_API
dust-front  | error - SerializableError: Error serializing `.ga_tracking_id` returned from `getServerSideProps` in "/".
dust-front  | Reason: `undefined` cannot be serialized as JSON. Please use `null` or omit this value.
dust-front  |     at isSerializable (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:36:19)
dust-front  |     at /dust-front/node_modules/next/dist/lib/is-serializable-props.js:43:66
dust-front  |     at Array.every (<anonymous>)
dust-front  |     at isSerializable (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:40:39)
dust-front  |     at Object.isSerializableProps (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:63:12)
dust-front  |     at Object.renderToHTML (/dust-front/node_modules/next/dist/server/render.js:570:67)
dust-front  |     at async doRender (/dust-front/node_modules/next/dist/server/base-server.js:669:38)
dust-front  |     at async cacheEntry.responseCache.get.isManualRevalidate.isManualRevalidate (/dust-front/node_modules/next/dist/server/base-server.js:778:28)
dust-front  |     at async /dust-front/node_modules/next/dist/server/response-cache/index.js:80:36 {
dust-front  |   page: '/'
dust-front  | }
dust-api    | [i] 0 pending runs

...and i get a 404 when I try visiting http://localhost:3000/api/init per the instructions in the readme.
This is on my MBP M1. Am I doing something wrong?

Same here, with a few more logs.
Config: Mac mini M1 - Ventura 13.0
% docker compose up
[+] Running 2/0
 ⠿ Container dust-api    Created                                                                                0.0s
 ⠿ Container dust-front  Created                                                                                0.0s
Attaching to dust-api, dust-front
dust-front  |
dust-front  | > dev
dust-front  | > next dev
dust-front  |
dust-front  | ready - started server on <IP_ADDRESS>:3000, url: http://localhost:3000
dust-front  | event - compiled client and server successfully in 627 ms (209 modules)
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-api    | [i] 0 pending runs
dust-front  | wait  - compiling / (client and server)...
dust-front  | event - compiled client and server successfully in 585 ms (896 modules)
dust-front  | [next-auth][warn][EXPERIMENTAL_API]
dust-front  | `unstable_getServerSession` is experimental and may be removed or changed in the future, as the name suggested.
dust-front  | https://next-auth.js.org/configuration/nextjs#unstable_getServerSession}
dust-front  | https://next-auth.js.org/warnings#EXPERIMENTAL_API
dust-front  | error - SerializableError: Error serializing `.ga_tracking_id` returned from `getServerSideProps` in "/".
dust-front  | Reason: `undefined` cannot be serialized as JSON. Please use `null` or omit this value.
dust-front  |     at isSerializable (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:36:19)
dust-front  |     at /dust-front/node_modules/next/dist/lib/is-serializable-props.js:43:66
dust-front  |     at Array.every (<anonymous>)
dust-front  |     at isSerializable (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:40:39)
dust-front  |     at Object.isSerializableProps (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:63:12)
dust-front  |     at Object.renderToHTML (/dust-front/node_modules/next/dist/server/render.js:570:67)
dust-front  |     at async doRender (/dust-front/node_modules/next/dist/server/base-server.js:669:38)
dust-front  |     at async cacheEntry.responseCache.get.isManualRevalidate.isManualRevalidate (/dust-front/node_modules/next/dist/server/base-server.js:778:28)
dust-front  |     at async /dust-front/node_modules/next/dist/server/response-cache/index.js:80:36 {
dust-front  |   page: '/'
dust-front  | }
dust-front  | wait  - compiling /_error (client and server)...
dust-front  | event - compiled client and server successfully in 122 ms (897 modules)
dust-front  | wait  - compiling /[user] (client and server)...
dust-front  | warn  - Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/basic-features/fast-refresh#how-it-works
dust-front  | event - compiled client and server successfully in 235 ms (900 modules)
dust-front  | error - SerializableError: Error serializing `.ga_tracking_id` returned from `getServerSideProps` in "/".
dust-front  | Reason: `undefined` cannot be serialized as JSON. Please use `null` or omit this value.
dust-front  |     at isSerializable (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:36:19)
dust-front  |     at /dust-front/node_modules/next/dist/lib/is-serializable-props.js:43:66
dust-front  |     at Array.every (<anonymous>)
dust-front  |     at isSerializable (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:40:39)
dust-front  |     at Object.isSerializableProps (/dust-front/node_modules/next/dist/lib/is-serializable-props.js:63:12)
dust-front  |     at Object.renderToHTML (/dust-front/node_modules/next/dist/server/render.js:570:67)
dust-front  |     at async doRender (/dust-front/node_modules/next/dist/server/base-server.js:669:38)
dust-front  |     at async cacheEntry.responseCache.get.isManualRevalidate.isManualRevalidate (/dust-front/node_modules/next/dist/server/base-server.js:778:28)
dust-front  |     at async /dust-front/node_modules/next/dist/server/response-cache/index.js:80:36 {
dust-front  |   page: '/'
dust-front  | }
dust-front  | wait  - compiling /[user]/apps (client and server)...
dust-front  | event - compiled client and server successfully in 424 ms (1259 modules)
dust-front  | wait  - compiling /api/apps/[user] (client and server)...
dust-front  | event - compiled successfully in 32 ms (106 modules)
dust-front  | error - Error: Dialect needs to be explicitly supplied as of v4.0.0
dust-front  |     at new Sequelize (/dust-front/node_modules/sequelize/lib/sequelize.js:135:13)
dust-front  |     at eval (webpack-internal:///(api)/./lib/models.js:14:19)
dust-front  | error - FetchError: invalid json response body at http://localhost:3000/api/apps/favicon.ico reason: Unexpected token < in JSON at position 0
dust-front  |     at /dust-front/node_modules/next/dist/compiled/node-fetch/index.js:1:51220
dust-front  |     at processTicksAndRejections (node:internal/process/task_queues:96:5)
dust-front  |     at async Promise.all (index 0)
dust-front  |     at async getServerSideProps (webpack-internal:///./pages/[user]/apps/index.jsx:322:20)
dust-front  |     at async Object.renderToHTML (/dust-front/node_modules/next/dist/server/render.js:508:20)
dust-front  |     at async doRender (/dust-front/node_modules/next/dist/server/base-server.js:669:38)
dust-front  |     at async cacheEntry.responseCache.get.isManualRevalidate.isManualRevalidate (/dust-front/node_modules/next/dist/server/base-server.js:778:28)
dust-front  |     at async /dust-front/node_modules/next/dist/server/response-cache/index.js:80:36 {
dust-front  |   type: 'invalid-json',
dust-front  |   page: '/[user]/apps'
dust-front  | }
dust-front  | error - Error: Dialect needs to be explicitly supplied as of v4.0.0
dust-front  |     at new Sequelize (/dust-front/node_modules/sequelize/lib/sequelize.js:135:13)
dust-front  |     at eval (webpack-internal:///(api)/./lib/models.js:14:19)
dust-front  | error - FetchError: invalid json response body at http://localhost:3000/api/apps/favicon.ico reason: Unexpected token < in JSON at position 0
dust-front  |     at /dust-front/node_modules/next/dist/compiled/node-fetch/index.js:1:51220
dust-front  |     at processTicksAndRejections (node:internal/process/task_queues:96:5)
dust-front  |     at async Promise.all (index 0)
dust-front  |     at async getServerSideProps (webpack-internal:///./pages/[user]/apps/index.jsx:322:20)
dust-front  |     at async Object.renderToHTML (/dust-front/node_modules/next/dist/server/render.js:508:20)
dust-front  |     at async doRender (/dust-front/node_modules/next/dist/server/base-server.js:669:38)
dust-front  |     at async cacheEntry.responseCache.get.isManualRevalidate.isManualRevalidate (/dust-front/node_modules/next/dist/server/base-server.js:778:28)
dust-front  |     at async /dust-front/node_modules/next/dist/server/response-cache/index.js:80:36 {
dust-front  |   type: 'invalid-json',
dust-front  |   page: '/[user]/apps'
dust-front  | }

Also get 404 on http://localhost:3000/api/init

Hi! Yes the docker files are not up to date unfortunately. Will try to fix them asap :+1:

DB init front side is still not as easy to do as I would like to avoid code duplication (while juggling with discrepancy of imports between node and nextjs)

This is now all fixed!


Revert "[23.05] gitlab: 16.1.4 -> 16.3.1"

Reverts NixOS/nixpkgs#253405

Sep 06 15:23:31 gitlab gitaly[1459]: unclean Gitaly shutdown: unsupported Git version: "2.40.1"

this somehow was not caught by the tests

This revert hasn't been pushed to the nixos-23.05 channel.  I just updated my database before rolling back the GitLab version and am now getting SQL errors because the schema doesn't match the version.
Is there a way to temporarily override the NixOS module to use the new version in your pull request, not just override the pkg?  ...or set nix-channel to use the master branch where git is updated to a version supported by Gitaly?

I was able to fix this by setting programs.git.package to the latest version of Git.

I was able to temporarily resolve this with a nixpkgs overlay that sets Git to version 2.41.0.


Fix #14 double escaping

first commit is failing test that demonstrate issue
last 2 commits are prettier formatting ☺

closes #14

This looks great! I will merge now and let you know when it's published :)
Thank you 🎉

Release in version https://github.com/SaraVieira/react-social-sharing/releases/tag/v1.3.3
Thank you again!

Thanks for merging and releasing new version 👍


chore: add eslint-plugin-eslint-comments

Summary
Forces us to be more narrow when disabling rules, which is nice

Test plan
Green CI

Codecov Report

Merging #9229 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #9229      +/-   ##
==========================================
- Coverage   65.08%   65.06%   -0.02%
==========================================
  Files         278      278
  Lines       11865    11865
  Branches     2925     2925
==========================================
- Hits         7722     7720       -2
- Misses       3516     3517       +1
- Partials      627      628       +1

Impacted Files
Coverage Δ

packages/jest-haste-map/src/constants.ts
100% <ø> (ø)
:arrow_up:

e2e/coverage-remapping/covered.ts
100% <ø> (ø)
:arrow_up:

e2e/coverage-report/notRequiredInTestSuite.js
0% <ø> (ø)
:arrow_up:

packages/test-utils/src/ConditionalTest.ts
0% <ø> (ø)
:arrow_up:

e2e/coverage-transform-instrumented/covered.js
100% <ø> (ø)
:arrow_up:

packages/expect/src/utils.ts
94.93% <0%> (-1.27%)
:arrow_down:

Continue to review full report at Codecov.

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


Setting cmake_build_dir_location doesn't seem to work

Sorry if I'm missing something obvious but I can't make the plugin to work with an existing build directory. I build all my projects in a subdirectory of ~/build, so I've tried doing
let g:cmake_build_dir_location="/home/myusername/build/myprojectname/asan"
let g:cmake_default_config=""
CMakeBuild

but the output is
Running command: cmake --build home/myusername/build/myprojectname/asan/Debug
Error: could not load cache

i.e. somehow the initial slash got eaten and "Debug" is still appended, which is unwanted.
Moreover, changing g:cmake_build_dir_location after the first CMakeBuild doesn't seem to change anything, i.e. setting it to bloordyblop and redoing CMakeBuild still shows the same output as before.
I'd like to at least try to debug this myself, but so far I didn't even figure out how to enable debug logging in the plugin, it would be great if this could be mentioned in the README.
Other info

OS: Linux (Debian Bookworm)
Vim/Neovim version: Vim 9.0
Vim-CMake version (:echo cmake#GetInfo().version): 0.15.2
CMake version (cmake --version): 3.25.1

Hi, thanks for reporting this.

Thanks a lot for your detailed reply!

At the moment, Vim-CMake does not support specifying g:cmake_build_dir_location as an absolute path — it must be relative to the project's source directory.

I've totally missed this, sorry. Maybe it could be useful to check that the value of this variable doesn't start with / and give an error if it does?

I'll have to think whether allowing absolute paths makes sense and does not break the rest of the plugin, but this would anyway be a feature request. Feel free to open one and I can then evaluate the situation from there.

Well, I guess I could always use relative paths (../../../build/...), so it's not a show stopper, just less convenient.

By the way, if I may ask, what is the reason for storing build directories in a centralized location, as opposed to within the project's directory?

[!warning]
Long digression, but you did ask.

The most honest answer is probably because I'm used to doing it like this, but there are better reasons to do it like this too:

Having all build artifacts under ~/build makes it easy to exclude them from the backups of home directory with just a single exclusion rule. And considering the size of the build directories (many of them are in the gigabyte range), it's pretty important to exclude them from backups.
This directory can be mounted on a faster disk, which is an important factor for speeding builds up. E.g. when SSDs used to be slow, you could keep the sources on a slower HDD but mount this directory on SSD (and I did this and it helped). Nowadays I don't do this any more, but I guess you could use RAM disk for this directory too.
It makes things tidier: with the build directories under the source one, you need to exclude them in each project .gitignore, which is perhaps not too onerous but why bother with it when you may just avoid the issue entirely?

In fact, I have to say that I have no idea why do people think that putting build directories under the source one is good. It's certainly easier for the tools (which is why all IDEs I know of do it like this), but doesn't seem to have any advantages for actual humans.

Moreover, changing g:cmake_build_dir_location after the first CMakeBuild doesn't seem to change anything, i.e. setting it to bloordyblop and redoing CMakeBuild still shows the same output as before.

The value of g:cmake_build_dir_location is only used:
* Upon initialization of the plugin (once)

* When creating a new configuration (with `CMakeGenerate`)

* When switching to another existing configuration (with `CMakeSwitch`)

Ah, I see. I (naively) expected this plugin to work just like the builtin :make and hadn't realized it used more stateful workflow.

Given your requirement of building all projects in a subdirectory of ~/build, and given that at the moment you have to pass a relative path to g:cmake_build_dir_location, I would recommend this workflow for you:
* Assuming your project is at the path `~/projects/myprojectname`, set `g:cmake_build_dir_location` to `../../build/myprojectname`

* When starting Vim in your project's directory, switch to your desired (existing) build configuration, e.g. `:CMakeSwitch asan`

* Build with `:CMakeBuild` whenever needed

* When restarting Vim, the plugin should remember the last build configuration and you can just `:CMakeBuild` there, unless you want to build a different configuration of course

Let me know if this works as expected.

Yes, thank you, I could build by doing this. It's a bit less convenient than just specifying the path to the build directory, but still nice, thanks. Ideally I'd like to be able to use this just as :make, i.e. run the command and get the errors into the quick fix buffer (which is really all I'm after), but I understand now that this might be not what this plugin is aiming to provide.

You can enable debug logging setting the values for g:cmake_log_file and g:cmake_log_level. This is mentioned in the docs.

Oops, sorry again for missing this and thanks for the pointer!
However I must still be doing something wrong here because when I do
$ vi -c 'let g:cmake_log_file="cmake.log" | let g:cmake_log_level="TRACE" | let g:cmake_build_dir_location="../../../build/myproject"'

I don't have cmake.log anywhere (I also tried with an absolute path and "DEBUG" instead of "TRACE"). What am I missing?
Thanks again!

Maybe it could be useful to check that the value of this variable doesn't start with / and give an error if it does?

As I said, I would also consider allowing absolute paths. But the check you suggest is a good plan B, if allowing absolute paths turns out to be too intricate.

Yes, thank you, I could build by doing this. It's a bit less convenient than just specifying the path to the build directory, but still nice, thanks. Ideally I'd like to be able to use this just as :make, i.e. run the command and get the errors into the quick fix buffer (which is really all I'm after), but I understand now that this might be not what this plugin is aiming to provide.

The steps I suggested (running :CMakeSwtich to select the build configuration) are just one way of specifying a build directory. An alternative workflow which might be more suited to your use case is the following.

Assume that your build directory is /home/myusername/build/myproject/asan
In Vim-CMake terms, this means that the build directory is located at /home/myuser/build/myproject, and the name of the build directory/configuration is asan
Set g:cmake_build_dir_location to ../../../build/myproject
Set g:cmake_default_config to asan. This value will only be used by Vim-CMake the very first time you use the plugin in a certain project. The next time you use it in the same project, Vim-CMake will remember the last used build directory/configuration — unless you set g:cmake_restore_state to 0
Run :CMakeBuild
Open the Quickfix window and browse the list of errors

This way you specify the path to the build directory statically, and you don't have to run any commands prior to :CMakeBuild. The plugin does indeed keep some state, but this is supposed to be an extra feature, it shouldn't be a hindrance. If there's still something missing that would make your workflow smoother, let me know.

Regarding logging, the problem is that the -c command line flag makes Vim execute a command after sourcing all configuration files, and thus after Vim-CMake has initialized its logger. You should be able to solve that using the --cmd command line flag instead. From man vim:
--cmd {command}
        Like using "-c", but the command is executed just before processing any
        vimrc file.  You can use up to 10 of these commands, independently from
        "-c" commands.

Thanks for the long answer regarding why you place build directories in a centralized location. The arguments about backups and disk speed make sense, at least in some use cases. Regarding the exclusion from Git trees, yes you do avoid configuring your .gitignore 1, however you do have to configure your IDEs to point them at the location of your build directories, so I don't personally see this as a strong argument. Nevertheless, a plugin should try to avoid imposing certain patterns on users, and that's why, as I've mentioned already, I would consider allowing absolute paths for g:cmake_build_dir_location.
1: I've actually configured a global list of ignored directories (in ~/.config/git/ignore) and I try to make sure that this list covers all common build directory names. But this is definitely not covering everyone's use cases.

Thanks again for your reply!
I'm not sure if this should be left open or closed. IMHO it would be quite convenient if I could just set the full path to the build directory without restarting Vim but, again, I realize that mine is not the workflow this plugin is really intended for (I work a lot on the libraries, and I often want to build different applications from a single Vim instance where I edit the library sources, i.e. the whole notion of a project doesn't really make much sense in this case).
Perhaps some :CMakeExecute <build-dir>, with build-dir defaulting to g:cmake_build_dir_location (and not taking config into account) could be added to accommodate this?

If I understand correctly, what you're after is a mechanism to reinitialize Vim-CMake without restarting Vim, correct? At the moment, Vim-CMake does get reinitialized when the current directory changes, so that you can build different projects from a single Vim instance. But this only works if you do change the current directory. This is the relevant piece of code that reinitializes the plugin on a directory change:
https://github.com/cdelledonne/vim-cmake/blob/709851504096320c10d90d2e7c057ff6efc9a4fc/autoload/cmake.vim#L30-L34
But I gather that you don't really change the current directory when building a different project/library, right? What is exactly your workflow then? You start Vim in some project's directory, then possibly build other projects/libraries without changing the current directory, then perhaps at some point build the main project itself? Or something different?
If this is indeed your workflow, there may be different ways to accommodate your needs:

Vim-CMake implements some new command, as you suggested above. What should the command do exactly?
Vim-CMake exposes an API for the user to force a re-initialization of the plugin, so that whenever you want to build a different project, you set your g:cmake_* variables accordingly and then reinitialize the plugin. The current project will not change (because that is inferred from the current directory), but at least the location of the build directory will be updated.
You actually change the current directory (e.g. with :cd) when building a different project.

I guess option 3. would not be your preference, right? Would option 2. work instead? I'd be a little reluctant to add new commands/functionalities for just a very specific use case, if the problem can be solved by just exposing some existing functionality. And I'd still like to stick to the notion of projects, even if you're building different projects from the same Vim instance.
Let me know what you think.

I could change the directory, but this would be another annoyance. Right now I have to:

Set cmake_build_dir_location.
Set cmake_default_config.
Remember to pass -- after :CMakeBuild when I want to build just a single target.

Having yet another step doing cd (and back) would make this even less convenient, and ideally I'd really like to just run a single command instead of all these steps. But it's "just" a question of convenience.
I.e. I'd indeed prefer the step (1) from above. Such command would just run cmake with the provided arguments and feed the results to the quickfix window. It would be basically nothing more than s:terminal.Run(command, 'BUILD', run_options) but using the provided command directly, without doing any processing.

As I said, I'm a little hesitant to add an extra command that almost does the same as an existing command, for what seems like a niche use case. I'd suggest you consider option 2. from my previous comment, and perhaps define your custom command that sets the g:cmake_* variables, reinitializes Vim-CMake, and then calls :CMakeBuild.

Remember to pass -- after :CMakeBuild when I want to build just a single target.

Why is that? Can't you just do :CMakeBuild <target>?

Remember to pass -- after :CMakeBuild when I want to build just a single target.

Why is that? Can't you just do :CMakeBuild <target>?

At least with ninja this doesn't work.

Sorry for the huge delay, I've not been able to spend time on Vim-CMake at all lately.
I'm not sure you're still using this plugin at the moment. If you are:

Can you tell me why :CMakeBuild <target> does not work with Ninja? I've tried it myself, and I can't reproduce what you say.
Can you let me know if you'd still be interested in Vim-CMake exposing an API for the user to force a re-initialization of the plugin? And in making g:cmake_build_dir_location understand absolute paths?

If you're not using this plugin at all, then I'll just close this issue for now, and re-open when/if someone else asks for something similar.
Thanks in advance!

Sorry for the huge delay, I've not been able to spend time on Vim-CMake at all lately.
I'm not sure you're still using this plugin at the moment. In case you are:

Can you tell me why :CMakeBuild <target> does not work with Ninja? I've tried it myself, and I can't reproduce what you say.
Can you let me know if you'd still be interested in Vim-CMake exposing an API for the user to force a re-initialization of the plugin? And in making g:cmake_build_dir_location understand absolute paths?

If you're not using this plugin at all, then I'll just close this issue for now, and re-open when/if someone else asks for something similar.
Thanks in advance!

Sorry for the huge delay, I've not been able to spend time on Vim-CMake at all lately.

As a fellow open source projects maintainer, I understand this perfectly well!

I'm not sure you're still using this plugin at the moment. In case you are:

To be honest, no, I don't, it was just too cumbersome for me, so I reverted back to just running cmake from terminal. This is definitely not great in case you get many errors, as navigating to them is much more convenient with the quick fix window in Vim, but, well, it motivates me to make fewer errors I guess :-)

1. Can you tell me why `:CMakeBuild <target>` does not work with Ninja? I've tried it myself, and I can't reproduce what you say.

It behaves very strangely to me. It seems to do the right thing, i.e. it says
Running command: cmake --build $dir -- $target

with the correct values for both but it doesn't seem to actually be doing this as I get errors from other, unrelated files. Also :cnext just results in E42: No Errors after a command like this, while it works perfectly fine for :CMakeBuild without arguments.

2. Can you let me know if you'd still be interested in Vim-CMake exposing an API for the user to force a re-initialization of the plugin? And in making `g:cmake_build_dir_location` understand absolute paths?

Yes, I'd still like to have a way to just run cmake --build $dir -- $target command as above even if I have to just type it myself — but with the quickfix window working. I don't know if it's worth your time to do it, of course, but it definitely would be very convenient for me.
Thanks again for looking at this!

Thanks for your quick reply.

It behaves very strangely to me. It seems to do the right thing, i.e. it says
Running command: cmake --build $dir -- $target

This is actually not what I would expect. The correct message should be
Running command: cmake --build $dir --target $target

Could you perhaps enable debug logging by setting the two variable g:cmake_log_file and g:cmake_log_level and then share the log file here? Logging is not very extensive, but it could give me a lead on what's going on.
Thanks!

Thanks for your quick reply.

It behaves very strangely to me. It seems to do the right thing, i.e. it says
Running command: cmake --build $dir -- $target

This is actually not what I would expect. The correct message should be
Running command: cmake --build $dir --target $target

Could you perhaps enable debug logging by setting the two variables g:cmake_log_file and g:cmake_log_level and then share the log file here? Logging is not very extensive, but it could give me a lead on what's going on.
Thanks!


Refactor pseudo functions

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[x] Refactor
[ ] UT
[ ] Doc
[ ] Tool

[FE PR Coverage Check]
:heart_eyes: pass : 65 / 75 (86.67%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/PolymorphicFunctionAnalyzer.java
65
75
86.67%
[102, 103, 111, 112, 114, 163, 164, 166, 288, 307]

run starrocks_admit_test


AbstractEventsourcedProcessorSpec failed

https://travis-ci.org/RBMHTechnology/eventuate/builds/114006751#L975 /cc @cstub. Seems to be a race as it doesn't occur in every test run.

@cstub are the Java tests running concurrently to the Scala tests? This might explain the assertion failure.

Unfortunately I was not able to reproduce this behaviour.
What I did come across was that in the current setup the JUnit-Tests are never executed - this seems to be related to an issue with sbt and the junit test-interface (https://github.com/sbt/junit-interface/issues/35).
Adding the option 'crossPaths := false' in the testSettings resolves the issue.
The initial test-failure however could not be reproduced, even after enabling the junit tests again.

Will close this ticket for the moment. Let's re-open it should we see the failure again.

Seen again at https://travis-ci.org/RBMHTechnology/eventuate/builds/164556604#L921


order by date, seem not applied, the dates appear in random order

maybe different dates are used?

Seems the sorting is by metadata date (updated) and the display is the dataset date


[Forwardport] Imported clusters can't recover when cluster-agent is down

Forwardport https://github.com/rancher/rancher/issues/23331

Tested with master-head build from Nov 11(7a6c2e55561f)
Steps:

Created an imported RKE cluster in Rancher
Deleted the cluster-agent deployment to simulate cluster-agent failure
Accessing cluster's projects from UI was functional. Cluster was in active state. Creating new projects/workloads was also functional.


BUilding MQ image getting error:failed to set bridge addr: "cni0"

While building an image getting below exception.
Build go programs
IMAGE_REVISION=3fb2d3fe61a886aecc590219ede4719a202a7888 IMAGE_SOURCE=https://github.com/ibm-messaging/mq-container.git sudo --preserve-env mq-advanced-server-rhel/godk:9.1.2-x86_64-rhel" ""
ERRO[0000] Error adding network: failed to set bridge addr: "cni0" already has an IP address different from <IP_ADDRESS>/16
ERRO[0000] Error while adding pod to CNI network "podman": failed to set bridge addr: "cni0" already has an IP address different from <IP_ADDRESS>/16
error configuring network namespace for container 772964a166388c87b39f3cac287e58e96d063120c737a214bf322dd3de23d734: failed to set bridge addr: "cni0" already has an m <IP_ADDRESS>/16
make: *** [build-go-programs] Error 127

Which version of podman are you using?  We've not come across this error.  It's possible that the problem lies with the --network option in the mq-advanced-server-rhel/go-buildah.sh script

HI team,
Can you help me change the location to OCI compliant archive file to /tmp/mq-buildah. to something else.

I would strongly recommend that you don't build directly off the "master" branch, as documented in the README.  This code is in development, and may not always be completely stable.
If you really need to use the current in-development code, then you can change the location of the OCI archive in the mq-buildah script.  Note that as this is in-development, this may change at any time.  The use of the mq-buildah script is currently just for this point-in-time, until Red Hat release a newer version of Podman, after which this may change again.  In the 9.1.2 branch, the buildah native scripts are still used.
I think there are now three separate issues covered by this GitHub issue.  Could I ask you to please open a new issue if there is still something you'd like us to address?  Please include details such as which host OS you are using, which version of MQ, and which build command.


Added Fibonacci

First 10 fibonacci numbers in lua.

I'm afraid this doesn't meet our standards in multiple regards:

Style: The formatting (braces around if-condition) isn't StyLua compliant, the else isn't necessary (just end would've sufficed, early return), the function isn't even localized
Correctness: The algorithm isn't exported using return;
Implementation/variant: This is the "worst" possible implementation (exponential runtime);
Tests: The tests are included in the file and not the .spec folder, using print instead of assertions, the for-loop step can be omitted


ntpd from ubuntu container is blocked from the host (ubuntu) apparmor policy (surely an aufs+apparmor bug)

reopening of unfixed https://github.com/docker/docker/issues/2800
related to #2276

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

It is not because of caps but because of bugs between apparmor & aufs.
docker fork (on top of 159f5e0)
(and our custom apparmor profile is a bit more laxist on certains points than ubuntu one.

btw, lot of users are bitten by this ... https://groups.google.com/forum/#!topic/passenger-docker/B7Cq3gs1paw

https://lists.ubuntu.com/archives/apparmor/2015-May/007848.html help to workaround the bug without tearing down apparmor.

ping @ewindisch because you were working on apparmor thingies at the moment :smiley_cat:


GO:0102760 and GO:0102097

id: GO:0102760
name: 6-deoxocathasterone hydroxylase activity
namespace: molecular_function
def: "Catalysis of the reaction: 6-deoxycathasterone + O2 + a reduced electron acceptor = 6-deoxoteasterone + H2O + an oxidized electron acceptor." [EC:1.14.-.-, GOC:pz]
xref: MetaCyc:RXN-774
is_a: GO:0016705 ! oxidoreductase activity, acting on paired donors, with incorporation or reduction of molecular oxygen
(no annotations)
MetaCyc:RXN-774 says that this reaction equation differs from the official Enzyme Commission reaction equations for this EC entry  = EC:<IP_ADDRESS> (22alpha-hydroxysteroid 23-monooxygenase)
That EC equates to:
id: GO:0102097
name: (22S)-22-hydroxy-5alpha-campestan-3-one C-23 hydroxylase activity
namespace: molecular_function
def: "Catalysis of the reaction: (22S,24R)-22-hydroxy-5alpha-ergostan-3-one + O2 + reduced [NADPH--hemoprotein reductase] = 3-dehydro-6-deoxoteasterone + H+ + H2O + oxidized [NADPH--hemoprotein reductase]. Also converts 3-epi-6-deoxocathasterone to 6-deoxotyphasterol." [EC:<IP_ADDRESS>, GOC:pz]
xref: EC:<IP_ADDRESS> {source="skos:exactMatch"}
xref: MetaCyc:RXN-11101
xref: RHEA:27321 {source="skos:narrowMatch"}
xref: RHEA:27325 {source="skos:narrowMatch"}
is_a: GO:0016712 ! oxidoreductase activity, acting on paired donors, with incorporation or reduction of molecular oxygen, reduced flavin or flavoprotein as one donor, and incorporation of one atom of oxygen
property_value: term_tracker_item "https://github.com/geneontology/go-ontology/issues/28070" xsd:anyURI
So the tasks are:

[x] Merge GO:0102760 with GO:0102097 (or just delete GO:0102760?)
[x] Rename GO:0102097 to '22alpha-hydroxysteroid 23-monooxygenase activity'
[ ] Consider generalising the GO:0102097 def further? EC comment says "The enzyme has a relaxed substrate specificity, and C-23 hydroxylation can occur at different stages in the pathway."??

Did not add the EC comment

Consider generalising the GO:0102097 def further? EC comment says "The enzyme has a relaxed substrate specificity, and C-23 hydroxylation can occur at different stages in the pathway."??

since that really sounds like a protein, not a MF.

Would it be useful keeping that EC sentence as a comment, to point out that while position 23 always gets hydroxylated, the rest of the substrate is not fully specified?


Option to import fragment as AST

The latest release broke code that expected fragment to be an AST instead of a raw string. In my app, I had something similar to
import DeliveryFragment from '../graphql/deliveryFragment.graphql'

apolloClient.writeFragment({
  id: `Delivery:${id}`,
  fragment: DeliveryFragment,
  data: delivery,
})

Perhaps inline #import statements could continue to be raw strings, but importing as a module would yield an AST?

Ah, I hadn't considered that use case. I'll fix it right now. Give me a few minutes and I'll let you know when I've published the new version. Then your code should work again without changes once you upgrade.

Alright @kamal , should be fixed in<EMAIL_ADDRESS>Let me know if you have any more problems. Thanks for reporting!

It works!


Change TextDecoder from global to globalThis

Change from global.TextDecoder to globalThis.TextDecoder cause the global keyword cannot be recognized in the browser and not all libraries that rely on this are run on a Node.js library.
Also fixes #38

@volovyk-s I know you guys might be very busy but any chance you can look at this?

Thank you @glennmichael123 , fix merge in https://github.com/near/borsh-js/issues/38.

@volovyk-s just saw you guys merged it just now thank you so much! if you guys can release a new version for this that would be great but you take your time not rushing.

@glennmichael123 I will release a new version soon


Add product hunt button

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

Change to embedded button
root:  web/components/landingpage/main-cta-button.tsx


Small refactoring

Codecov Report

Merging #186 (2343a89) into main (f4353b6) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##             main     #186   +/-   ##
=======================================
  Coverage   22.67%   22.67%
=======================================
  Files         120      120
  Lines        8667     8667
=======================================
  Hits         1965     1965
  Misses       6702     6702

Impacted Files
Coverage Δ

crates/handlers/src/oauth2/token.rs
0.00% <0.00%> (ø)

crates/static-files/src/lib.rs
5.55% <ø> (ø)

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 f4353b6...2343a89. Read the comment docs.


add cuda 11.4 support

Checklist before submitting

[x] Did you read the contributor guide?
[ ] Did you update any affected documentation?
[ ] Did you write any tests to validate this change?

Description
Fixes # (issue).
Review process to land

All tests and other checks must succeed.
At least one maintainer must review and approve.
If any  maintainer requests changes, they must be addressed.

Codecov Report

Merging #131 (9265492) into main (aa79245) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
- Coverage   96.20%   96.20%   -0.00%
==========================================
  Files          23       23
  Lines        2106     2105       -1
==========================================
- Hits         2026     2025       -1
  Misses         80       80

Flag
Coverage Δ

unittests
96.20% <100.00%> (-<0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

open_ce/inputs.py
96.46% <ø> (ø)

open_ce/container_build.py
96.38% <100.00%> (-0.03%)
:arrow_down:

open_ce/utils.py
95.02% <100.00%> (ø)

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 aa79245...9265492. Read the comment docs.

Codecov Report

Merging #131 (9265492) into main (aa79245) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
- Coverage   96.20%   96.20%   -0.00%
==========================================
  Files          23       23
  Lines        2106     2105       -1
==========================================
- Hits         2026     2025       -1
  Misses         80       80

Flag
Coverage Δ

unittests
96.20% <100.00%> (-<0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

open_ce/inputs.py
96.46% <ø> (ø)

open_ce/container_build.py
96.38% <100.00%> (-0.03%)
:arrow_down:

open_ce/utils.py
95.02% <100.00%> (ø)

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 aa79245...9265492. Read the comment docs.

We will have follow up PR for version update and documentation changes that remain.


feat: add RouteReasonNoMatchingParent

What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #1511
Does this PR introduce a user-facing change?:
- Add `RouteReasonNoMatchingParent` reason for `Accepted` condition set on routes when no matching parent has been found

Approved, but I'll let Rob or Nick do the final lgtm.

/ok-to-test

Hey @pmalek, do you think you'll have time to take another look at this in the next ~day? We're just about ready to send v0.6.0 for API review and would love to include this in the release if possible.

Hey @pmalek, do you think you'll have time to take another look at this in the next ~day? We're just about ready to send v0.6.0 for API review and would love to include this in the release if possible.

@robscott Sorry for the delay. I did manage to update the PR as you described. Apparently it needed a make fmt (make generate didn't produce any differences).


Add tooltip to stream name in top bar

At present, it's not obvious that clicking on the stream name in the top bar will take the user to stream settings. We should fix this by adding a tooltip:

Go to #design settings
25,951 subscribers

Notes:

The second line is in preparation for removing the number of subscribers form the top bar.

Questions:

Is it easy to use stream privacy icons here? If not, we can use a #. (See #25257)

CZO thread

@sayamsamal This might be a good one for you to pick up.

@zulipbot claim

@retsambew Do you have any PR on the way? This is a priority issue and we would like to see some progress soon.
I also recommend you to read the Zulip code contribution guide to better understand the process.

Sorry for the delay, the work is almost done and I'll add the pr for review by tonight.


Propagate MiQ identifier on Hawkular Alerting

In the context of MiddlewareServer Alerting, the MiQ Alert and MiQ Alert Profile is propagated into Hawkular Alerting Triggers definitions.
In the context of 1:1 (ManageIQ:Hawkular provider) this works fine.
But if several MiQ instances are linked with the same Hawkular Provider, it might happens that the MiQ Alert id in MiQ-A could be the same of MiQ-B, and get an error that a trigger cannot be created on Hawkular side (as it was created by other MiQ instance).
So, I am not sure if having a relation of 1:N between MiQ and Hawkular Provider has been considered.
But in any case, for this specific use case, propagating an identifier of MiQ could prevent of this possible error.
Note: This could happen specially in test scenarios, where a Hawkular provider is shared between several MiQ developments instances.

@miq-bot add_label bug,providers/hawkular

@miq-bot assign @lucasponce

@miq-bot remove_label bug
@miq-bot add_label enhancement

@lucasponce can/should this issue be fixed?

@abonas I created to not forget about it.
It is more a corner case but I think that this could be related to other scenarios.
If the relation MiQ:Providers is N:M, saying that the same hawkular provider should be handled at same time by several instances of MiQ, yes, as some uuid from the MiQ should be propagated.
But if this is so, I wonder how other areas in the core could be impacted.

@lucasponce we need to decide if to keep this issue open here or move it to the new repo - it depends where the code for the solution would be. wdyt?

@abonas code affected is located in the middleware provider only, so yes, it could be moved.
Basically it is here:
https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/models/manageiq/providers/hawkular/middleware_manager/alert_manager.rb#L40
and
https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/models/manageiq/providers/hawkular/middleware_manager/alert_profile_manager.rb#L43
The patch could be to extend the "MiQ-#{alert_id}" to something "MiQ-{miq.id}-#{alert_id}" counting that an miq.id is something available to identify a MiQ instance.
Also it don't remember if it should affect other class, but basically the mapping between the alert_id and Hawkular trigger is done in that code.

@miq-bot assign @israel-hdez

@lucasponce what is understood as a "MiQ instance"?
I'm trying to think a good way to build that miq.id. Multiple MiQ servers can share one Postgres database and it doesn't make sense to include the server id in the alert, since both servers may want to share that alert. However, it makes sense to use the server id if each server has its own database.
Even more complex: two MiQ databases may be replicated into one master database... In this case, may be the "master server" should use the ids of the slaves to manage the alerts?
Well... I think the easiest way to go is to use the guid assigned to hawkular in ext_management_systems table. If two servers share the same database, they will see the same guid and will be able to share it. If two databases are being used, hopefully the guid won't collide and the data should be seamlessly replicated to the master database (if any) for its management.

@israel-hdez by "MiQ instance" is some identifier that can differenciate one MiQ installation (with their replicas) from other.
Your comments are right, we might have several MiQ instances sharing a database or even database replicated.
In that environment, when a MW provider is added, it should be unique.
So, the "MiQ instance" should be some id that let to avoid potential colliding if for example there are two MiQ installations pointing to the same MW provider (Hawkular backend).
This is more a corner case, as in production unlikely we are going to have two MiQ installations pointing to the same Hawkular, but it might easily happen in development scenarios (several engs using the same demo Hawkular backend).
The guid assigned sounds a good start.
Let me know if you have any doubt.
Thanks.

can we consider this issue resolved?

It's ok for me to mark it as resolved.

@lucasponce if you think it's resolved, please close it

Yes, PR is merged and additional tests added.
Sorry for my delay, I thought this should be closed automatically with the PR.
Closing.


Tests for Inventory package

added 100% test coverage for inventory internal package

Please, if there is no more comments, check if the PR could be approved ;)


Clearing old alerts in the UI

Describe the bug
I see nowhere to clear out old alerts, would be good to be able to set them as read even though they might still be ongoing. Also I think this migration alert could clear out automatically when there's nothing left to migrate, now it's showing this:

Additional context
General Information
Are you running a fork of renterd?
no
Are you on the mainnet or on the testnet?
mainnet
Renterd Config
Autopilot Config
{
"contracts": {
"set": "autopilot",
"amount": 50,
"allowance": "12000000000000000000000000000",
"period": 6048,
"renewWindow": 2016,
"download":<PHONE_NUMBER>000,
"upload":<PHONE_NUMBER>000,
"storage":<PHONE_NUMBER>0000
},
"hosts": {
"allowRedundantIPs": false,
"maxDowntimeHours": 336,
"scoreOverrides": null
},
"wallet": {
"defragThreshold": 1000
}
}
Bus Config
{
"minShards": 10,
"totalShards": 30
}
{
"hostBlockHeightLeeway": 6,
"maxContractPrice": "450000000000000000000000",
"maxDownloadPrice": "2300000000000000000000000000",
"maxRPCPrice": "2000000000000000000000",
"maxStoragePrice": "254629629630",
"maxUploadPrice": "900000000000000000000000000",
"minAccountExpiry":<PHONE_NUMBER>0000,
"minMaxCollateral": "10000000000000000000000000",
"minMaxEphemeralAccountBalance": "1000000000000000000000000",
"minPriceTableValidity":<PHONE_NUMBER>00
}
Contract Set Contracts
50

Hey, we have this on hostd - @ChrisSchinnerl @peterjan renterd does not have this functionality right? Should we add it or was the intention that the alerts would somehow automatically go away? If the latter I we should add an explanation on how/when.

renterd's alerts match the host's so you can in theory copy paste that functionality over.


Add auto-update workflow

This PR implements a user-driven update workflow for the GUIDE that notifies users of a new release on the Settings page. This should only show if a new release is actually present compared to the current version.

Clicking the info icon will display a record of the release notes.

The Update button then triggers the electron-updater package to download the latest release (with a related progress bar) and asks the user if they'd like to restart the application now (activating the downloaded release) or defer this until a manual close.
To test, I'd suggest that you create a local build and go through this workflow. The success of this process on Mac depends on proper code-signing, but I believe you should be able to complete this on a Windows PC.

I can take a crack at rebasing this after the next 2 frontend refactors are done
@garrettmflynn the next one was the separation of frontend tests and stories from other assets/pages, correct?

OK this PR is rebased; however, it always looks as if it triggered some problem in the Windows test (perhaps that same you alluded to about modals popping up and closing?)

Worked great on Windows!

Worked great on Windows!

Where did it do this? I have no idea what's going on here 😅

Where did it do this? I have no idea what's going on here 😅

I mean the full build and distributable on Windows; it showed the auto-update thing in settings and it all looked perfect; auto-updating installed the current released version in the previous installation directory

Ah awesome!


[BUG] casting PyObject * is broken in pure python mode

Describe the bug
For some cases casting PyObject * is failing during compilation with error: Cannot convert 'PyObject *' to Python object
To Reproduce
Following code is compiling with no error:
from cpython.ref cimport PyObject

foo = {"abc": 123}

cdef PyObject *bar = <PyObject *> foo

But in pure python version is failing:
import cython
from cython.cimports.cpython.ref import PyObject

foo = {"abc": 123}

bar: cython.pointer(PyObject) = cython.cast(cython.pointer(PyObject), foo)

Expected behavior
Pure python mode  should reflect cython language.
Environment (please complete the following information):

OS: Linux
Python version: 3.9.2
Cython version: master branch

This is intended. There is already a ticket where this was discussed. It only applies to module globals, which are Python objects unless explicitly declare()-d as something else.
If you try the same thing inside of a function, it will probably work. I think it's ok to use a function in the documentation.

Hmm, yes it seems working. I did mistake when I was generelizing bug but it seems that following code snippet fails:
import cython
from cython.cimports.cpython.ref import PyObject

@cython.cfunc
def foo(obj: cython.pointer(PyObject)):
    pass

def main():
    python_dict = {"abc": 123}
    foo(cython.cast(cython.pointer(PyObject), python_dict))

compiling fails with following error:
$ cython -3a test.py

Error compiling Cython file:
------------------------------------------------------------
...
def foo(obj: cython.pointer(PyObject)):
    pass

def main():
    python_dict = {"abc": 123}
    foo(cython.cast(cython.pointer(PyObject), python_dict))
             ^
------------------------------------------------------------

test.py:12:14: Cannot convert 'PyObject *' to Python object

@scoder can you confirm the case? If yes I will close this issue and create new one with new snippet.

The module globals issue is: https://github.com/cython/cython/issues/3944 (the issue that the the annotations on globals are ignored).
Your function-based version looks like a genuine bug (I think). I don't think it's necessary to create a new issue for it though

Ok closing this big. Thank you @da-woods !


device out of space error when running iso on openstack/qemu

Given a virtual machine with the following stats:
4 VCPUs
8 GB RAM
80 GB HDD
Running the latest rancheros.iso on qemu on openstack juno.
I expect that pulling two images, sameersbn/gitlab:7.8.1 and sameersbn/redis:latest , will succeed (assume the rancher-agent image already ran successfully).
Instead, the pull fails with 'no space remaining'. If I install docker on a trusty-taur vm of similar or smaller sizes, all steps above succeed with flying colors.
If you'd like more info, logs, etc... just ask. The machines are fairly beefeh:

If you run from the ISO, RancherOS looks for a partition labels with RANCHER_STATE.  You can look at the readme for the exact command to create that.  If RancherOS can't find that filesystem it will just run out of memory.  I suspect you are running out of memory.
We have a to disk installer coming soon that would hopefully make it easier to run in Openstack.
@cloudnautique what's the easiest way at the moment to create a bootable disk?

Awesome! Could I possibly fashion a metadata piece for this?
I'm sorta new to editing iso's, but I was looking at the scripts... I bet I could use the CoreOs libs for reading cloud-init's if you guys would allow it.

@dudymas If you are running qemu w/ OpenStack I would assume that it is using virtio so the device would /dev/vda that you would want to format.
We only turn on <IP_ADDRESS> for the EC2 images, I believe if we turned it on for ISO then the boot maybe hang indefinitly waiting for 169.254.  We could make it a kernel command line option, but then that wouldn't be useful to OpenStack.
We want to have a proper OpenStack image and will be working on producing one.  If you can specify a volume with your VM there is a preformated qcow2 at https://github.com/rancherio/os/blob/master/assets/empty-hd.img.gz.  So boot from ISO and use that as your primary disk.

Since this has a lot of good workarounds, AND there's going to be an installer, I'm considering this closed. Feel free to reopen if you'd rather use the issue to track the installer fellow.
Also, I'm going to be making a packer for rancher internally... but I'm pretty sure I could make it a PR if you guys like packer... thoughts?

I believe packer is going to be our official approach to building images.  It's a WIP but you can see what @cloudnautique has been working on here https://github.com/cloudnautique/rancher-packer.  We'd love contributions.  I personally don't know much about Packer so I'm not sure what work needs to be done there.

Any progress creating a usable openstack qcow2 image? While boot from iso I don't have any usable block device to install to. I am using openstack nova and whould like to test rangeros :).

I've been rolling my own qemu's from the isos, as we also deploy with openstack. packer might let you accomplish this.
try nabbing packer from http://packer.io
then git clone https://github.com/cloudnautique/rancher-packer
cd to /vagrant
edit either json file to use fields in https://packer.io/docs/builders/qemu.html
I might have time to put something up on github for ya. just no promises on short notice.

Thanks for pointing to your solution. I will read the docs and will see to understand. But I just wonder if the wheel is already invented why there is no general openstack image with a variable user_data input made yet.
I have meanwhile played with rangeros on my own kvm server and must say it is way easier then coreos to manage. Great job!

Well, we can certainly just make a PR to the packer scripts.
I agree we should add an image that takes user_data too. All you have to do is install cloudinit on the os via script... maybe I could just grab a build of https://github.com/coreos/coreos-cloudinit and have the rancher system docker run cloudinit in a rancher flavor (i.e. build it without the coreos flags).
put that on a phusion or alpine container, and it'd still be rather slim... could even tell it to clean up afterwards.
I'm going to rename this issue to be more specific and reopen to see what the rancher folks can say.


Integrate async i/o tests and validation into CI/CD pipeline

Currently, async I/O functionality is only tested in recording. We need to enable them for live tests, both the ones run in the azure-quantum-clients pipeline, but also the ones run in the iqsharp Docker image.
We should also add a validation step to our CI/CD pipeline that tests for any changes to the code that need to be propagated to the async package.

Closing since we deprecated aio package integration.