Update: NMEA sample with GNSS device API

Goals
To showcase the new NMEA LDS constructor in U11 that connect to a real device easily without pushing NMEA data manually.
Changes and Updates

talked to MFi device manufacturers to whitelist the samples app for next release, so that Apple can approve Samples app to connect to external accessories.
update source code to support both mock data and U11 constructor, and to update UI and logics
update README

Demo
Please see the internally shared video - don't post here to avoid leaking my accurate location info 😅
How to Test
Please note: this PR has lower priority than the release related ones. Please review them first.

If you don't have a GNSS surveyor, simply test the mock data functionalities, and look for any logic bugs in the code.
If you have a GNSS surveyor that is one of these 3 brands: Bad Elf, EOS, SXBlue, then try to connect the device and switch back and forth to see if the sample works as expected

Todolist

[ ] after the changes are approved, have Divesh take a look
[ ] verify the sample with 3 GNSS devices that are currently possessed by different teams

[x] Ting: BadElf
Nick: EOS Nick has sent back the GNSS accessory. 😢 cocoa/issues/10553#issuecomment-2824557
[ ] Apps?: SXBlue

[ ] before merging PR, will add an iOS specific design doc to internal repo
[ ] before merging PR, follow up with manufacturer representative to see if we get our bundle id whitelisted

Extra Information
The BadElf CTO Brett offers to help to review the verbiage for adding GNSS receiver support to an app. So after the code is good and people are happy with the README, we can send him a link to this PR to get some insights!

Code isn't ready for another review yet; will hardcode the protocol strings in the sample if no objection, and simplify the logic for the BT picker & error handling.

Hi Divesh, @dg0yal please take a look at the README and share your thoughts!
I'll also send a copy of the README to Brett from BadElf to get some feedback.

I'll merge this PR now as Brett has limited availability to review the PR. But he said he'll jot down a few suggestions when available, and we may make an update then.


Hide properties from Project browse object

fixes #389

Can you fix the spacing to be two spaces? Change LGTM otherwise. What does the properties pane look like for the project now? Can you paste a screenshot?


Ammo tests

Implements tests for Ammo.js
Moved from #5106, use IDL from playcanvas/ammo.js, put as draft waiting for current IDL used by editor or update to latest kripken/ammo.js.
I confirm I have read the contributing guidelines and signed the Contributor License Agreement.

I wanted to check in on this PR - it's been open for a while! Can I ask where test\ammo.mjs came from? Did you make that yourself by hand? Also, is there any reason not to run tests using the 'real' ammo.js? I'm concerned a stubbed ammo will get out of sync with the actual version of ammo we take from kripken's repo.

I made it myself yes. The initial idea was to replace only few functions however if you declare it once it fires from everywhere so I had to add all functions, which is also a good indicator of which are supported and which are not, especially since the version of Ammo being used is not up to date with kripken's repo (or wasn't last time I checked)
I also have absolutely no background knowledge or skills about tests and it was suggested by @LeXXik in #5106 to do so, and because they seem more aware than me in the matter I went ahead and made that. Honestly I wouldn't mind using Ammo directly either however since it requires the version to be synced it would be a risk as well and mislead users if a contributor add something working only with the latest Ammo version while this version is not the available one in projects from the editor.

@willeastcott what is the status of this ticket? I want to write some features to collision component, but still can't write tests.

I gotta say, I'm still really struggling to see the justification for merging this. Should we be writing stubs for Draco, Basis and whatever other WASM libraries we add in the future? If we merge this, we're essentially committing to maintaining it.
I'm going to summon @slimbuck and @mvaligursky because I really feel like I need other opinions here.

Draco, Basis and whatever other WASM libraries we add in the future?
Yep, we should. Although, I don't think we need to stub everything. Only the methods that the engine is calling should be enough.

Should we use the wasm libraries themselves instead of stubs?

The goal of the test is to verify that the engine is calling the correct Ammo methods, correct amount of times and at the right time. It is not possible to verify it with original library (it won't tell us). Stubs serve that purpose - we don't care about Ammo internal functionality during a test, but we care we call proper methods.


Testers needed for config flow integration update

Hi everyone,
Since I launched this a year ago, I've been blown away by the enthusiasm and support I've received for this project! It's been amazing to hear all the different use cases, and the API has improved considerably over the past 12 months.
One important update is to modernize this integration away from just relying on the Home Assistant Dark Sky integration to one that can be setup from the GUI, uses coordinated updates, and supports modern Home Assistant API calls. In short, this is that update.
For anyone interested, I'm looking for some people to try out the new version and get some feedback on what works, what doesn't and where the rough edges are. From my testing, everything seems stable, but since this is a major change I want to test it out as much as possible before a wider release.
As a starting point, this version should behave exactly the same way the production one currently does. If you have an entry in your configuration.yaml. then a new weather entity and/or sensors will be created, and should be identical. Anything else is a bug. Moreover, this integration should now be able to be set up from the GUI integrations page, producing the same integrations that currently exist.
To install and test this version, you'll need to manually patch the "dev-config-flow" branch into your custom_components directory using SSH and restart Home Assistant Core:
cd "/config/custom_components/"
mv "/config/custom_components/pirateweather/manifest.json" "/config/custom_components/pirateweather/manifest.json.old"
mv "/config/custom_components/pirateweather" "/config/custom_components/pirateweather.old"
git clone --branch dev-config-flow https://github.com/alexander0042/pirate-weather-ha.git
mv "/config/custom_components/pirate-weather-ha/custom_components/pirateweather" "/config/custom_components/pirateweather"

The two outstanding known issues are cleaning up the text options for the monitored conditions, and updating the installation instructions in the README, but I'm sure more will crop up as people start using this version.
Thanks again for the help, and let me know it goes!

Hi @alexander0042. I'll be glad to help test.
I had to slightly modify your instructions based on my file structure and "think" I have the new version installed. I restarted Home Assistant and everything seems to be working as normal.
How can I verify that the new version is installed and working?

Thanks- and great question, should have included that in the initial post! Two signs that it's working:

You should see a warning in your log (after restarting HA core) that the yaml configurations have been imported and can be deleted
In the integrations page, there should be a new "Pirate Weather" box like this:

OK. So when I "Check Configuration" in Developer Tools, I the following two errors:
Platform error weather.pirateweather - Integration 'pirateweather' not found.
Platform error sensor.pirateweather - Integration 'pirateweather' not found.
And when I go to integrations, I do not see the Pirate Weather Integration/Box.
What should I do at this point?

Sorry this is trickier than it should be! This is after restarting HA Core (under "config/system")?

Yes...And I can no longer restart HA Core due to the config error.
Failed to restart Home Assistant
The system cannot restart because the configuration is not valid: Platform error weather.pirateweather - Integration 'pirateweather' not found. Platform error sensor.pirateweather - Integration 'pirateweather' not found.

OK. I did a hard CPU reboot and re-followed your instructions and all seems to be working.
So, according to logs, I can completely delete the pirateweather data from configuration.yaml now that it's been imported?

Again, sorry this was more complex than it needed to be! I'm (clearly) more comfortable with data wrangling than this sort of development. Happy this version worked!
And yes (although I'd just comment it out for now)! You can either leave the imported entities alone and they will continue to happily exist, or create a new one using the GUI at some point. One perk of this approach is you can now have as many Pirate Weather integrations as you'd like, so long as they're for different lat/longs, they'll have their own names and update coordinators.

OK...I tried to configure the Integration to add TEMPERATURE as a "Monitored condition sensor" and got the following error:
User input malformed: expected str for dictionary value @ data['forecast']
Also, I'm not seeing a Humidity sensor within the list to add.

Ok then- this is exactly the sort of testing I was hoping for! I'll see where that humidity sensor went, and take a look at the options update logic

OK....let me know when you have another update
I do rely on the temp and humidity sensors (nothing major, their just on my home page as entities)

I was able to get Humidity added to the list of available sensors as well as correct the spelling mistake.
Spelling mistake fixed in en.json - Line 40
Humidity added to Available list of monitored conditions by adding the following line to const.py in the ALL_CONDITIONS =, section
'humidity': 'humidity',
However, I wouldn't know where to begin to fix the error: User input malformed: expected str for dictionary value @ data['forecast']
I'm sure you would have figured those two fixes out fairly quickly, but wanted to see if I could do it on my own :)

Good catch on the spelling mistake and the humidity, that's exactly the fix ! And don't sell yourself short- I love the challenge of trying to fix something without knowing what's going on, so always worth trying.
The other issue is a lot trickier. It all comes down to Dark Sky having both a "weather" entity and a "sensor" entity, and the options flow trying to unload one when the other is what's in use. I think I have a fix for this, but want to look it over tomorrow morning, so I'll update when the branch is corrected. The net result will be that it'll take a delete and re-add to change from one to the other, but since most people are looking for both, that shouldn't be too much of an issue

Your workaround worked. Weather is now working again.
I did go in and tried to add the w
Temperature and Humidity sensors. I got no errors when adding, but the sensors did not get added. I tried reloading the integration as well as restarting hass with no luck.
The integration still only showing 1 Service and 1 Entity.

Awesome, that's something at least!  I'll need to clarify this in the instructions somehow, but if it's a "weather" block you can't add sensors (which is what shows up in monitored conditions), and visa versa. However, if it is configured as a sensor already, then that's an issue, since it should work

Before your changes, I used a weather block and had all pirateweather config in weather.yaml. I have since commented out my weather block since hass pulled in pirateweather as an integration. I also commented out all pirateweather sensors used previously before this new configuration.

Ok, that makes sense- because you had both a weather block and a sensor block, you should have two separate integrations show up for Pirate Weather. If not, try un-commenting and restarting, which should bring them in. You should be able to add humidity to the integration for the sensors, which will have a several entities, compared to just one for the weather integration.
I do have an idea to simplify this somewhat and let sensors to added to a weather integration or visa versa, but not sure it's worth working into this particular update

Ok, think I've got this working now! The options flow is now a lot more robust, and can handle both platforms in one place! If you have time to try this one at some point, the best procedure is:

Delete any PW integrations in the UI
UN-comment the data blocks in the configuration.yaml
Follow the renaming and download steps in the original post

Thanks again for helping here, it's invaluable to get this sort of feedback before a major change

Followed instructions and now missing the main weather.pirateweather entity
It appears the only thing I have are all the pirateweather sensors
I'm also a little confused with what your trying to accomplish here. I thought the original goal was to get the pirateweather moved over to an integration thus eliminating any yaml configs.
But, let me know if you have any suggestions or fixes to bring back the weather.pirateweather entity as I'm completely missing my weather card on home screen.

I could definitely be clearer here. The goal is to move away from the yaml; however, by leaving the lines in it helps to test if the import is working, and deleting the existing UI integrations beforehand creates a "clean slate" for this testing.
Did you notice anything in the logs when you restarted HA core? There should be something about importing the weather entity from the yaml, as well as an error of some sort if the import failed

OK. That makes perfect sense.
Let me try again....I had since reverted back to the original.

Here's what's in the Logs There's two separate messages.
This error originated from a custom integration.

Logger: custom_components.pirateweather.weather
Source: custom_components/pirateweather/weather.py:136
Integration: Pirate Weather (documentation, issues)
First occurred: 3:37:15 PM (1 occurrences)
Last logged: 3:37:15 PM

Configuration of Pirate Weather (weather entity) in YAML is deprecated Your existing configuration has been imported into the UI automatically and can be safely removed from your configuration.yaml file

This error originated from a custom integration.

Logger: custom_components.pirateweather.sensor
Source: custom_components/pirateweather/sensor.py:546
Integration: Pirate Weather (documentation, issues)
First occurred: 3:37:15 PM (1 occurrences)
Last logged: 3:37:15 PM

Configuration of Pirate Weather sensor in YAML is deprecated Your existing configuration has been imported into the UI automatically and can be safely removed from your configuration.yaml file

Ok, those are actually good things! They mean that the integration is reading both the sensor and weather blocks from the config file, so they should be importing. Downside is that they don't explain why the weather one isn't showing up in your setup.
If you create a new weather entity using the UI flow, does that one show up?

How do I create a new weather entity using UI flow? Do you mean to try and add another Pirateweather "integration"?

Exactly that! Under the add integration button select Pirate Weather, and fill in the fields from there. To create a weather entity, you just need to make sure the "weather" checkbox is selected, and you can leave the rest blank

Actually, I just looked at the integration already installed and it was missing the Weather checkbox....I checked that and got my main weather.pirateweather entity back!
Should I now try and comment out everything in yaml?

I am surprised that was not checked by default.

OK....So I commented out my weather block as well as all pirateweather sensors and restarted HASS. This resulted in the integration disappearing. I then went to integrations and manually added the pirateweather integration. I checked weather and sensors and selected the temperature & humidity sensors I needed and it all added everything as expected.
I restarted HASS and everything remained. It appears that all is working as expected.

I do have a feature request.
I would like to have the ability to not show anything after decimal point for temperature and humidity. I had to create value_templates to get my temperature and humidity to display whole numbers (rounded). I would love to have this feature within pirateweather so I can get rid of my value_templates

While I am testing this, would you like any  issue reports on this thread, or would you like an issue created referencing this issue?

Great feedback, this is exactly the sort of stuff I was looking for!

Two instances is a really good point- one of the goals for this change was to make it easier to create multiple instances, so it's definitely important! Currently, the integration checks to see if there's already a configured instance with the same location and doesn't create another entity if there already is one in place, which works well enough, but I'll add a check for daily/ hourly modes.

I think this is a documentation/ working fix. If you're just creating a weather entity, then there should only be a weather entity. If someone is looking to create sensor entities (which was something supported by the original Dark Sky), then it'll create a sensor for every requested variable at every requested time (which could be a lot). My plan is to clarify this in the setup UI flow with something along the lines of "Don't select sensor unless you want individual entities for the following options"

That's a known bug that I'm still working on. You can manually delete these orphaned entities without issue, and at least they're clearly marked, but I'm going to have to ask in the discord about this one, since I've tried every way I can think of and nothing is working to address this.

Hoping to have a new version Monday/ Tuesday next week that adds a rounding option (great suggestion from @myopenflixr!) as well as these two changes

@alexander0042 for number 2, I understand what you mean there. However, that is not what I meant by it creating a large quantity of devices. Homeassistant lists devices and entities. Devices can have entities associated with it, and what I see happening is, for every entity created when using the entities option to track different stuff, each entity will have it's own device.
Now I don't know if its a limitation in design, but what I would expect is for all entities under the same integration config / instance, those entities would be grouped under a single device. If this isn't possible due to implementation, I would suggest giving the devices names that correspond to the entity as its hard hunting for the exact device responsible for the entity.

I haven't been able to dig deep into what changed in the code yet but for some reason all of my wind Gust readings are incorrect. I have my units in the gui set to us but the wind gust never goes above 1.0. it's always below 1 which has made no sense.
If I find the change, I'll reference the line for you.

Ok, new version is out! Changes in: https://github.com/alexander0042/pirate-weather-ha/commit/9287401dd986fac45fa990c8baf0841b4fc1b10a

Added rounding (credit to @myopenflixr)
Multiple weather entities (@coaster3000)
Removed the debug warning (@coaster3000)
Fixed the wind speeds (unit conversion error) (@coaster3000)
Cleaned up some of the language in the config flow prompt

I checked how the existing integration does it, and since it creates separate devices for each time/ condition, I think it's best to leave it for compatibility. The "one device many entities" approach is definitely the way things are going, so I'm hoping that once this is released and people are migrated over, I can switch it to a single device then!
To update to this version:

Delete any existing Pirate Weather Integrations using the UI (one time step since the config properties have changed)
Uncomment any yaml entries you'd like imported again
Run the update steps:

cd "/config/custom_components/"
mv "/config/custom_components/pirateweather/manifest.json" "/config/custom_components/pirateweather/manifest.json.old"
mv "/config/custom_components/pirateweather" "/config/custom_components/pirateweather.old"
git clone --branch dev-config-flow https://github.com/alexander0042/pirate-weather-ha.git
mv "/config/custom_components/pirate-weather-ha/custom_components/pirateweather" "/config/custom_components/pirateweather"

I apologize for any grammar or odd phrasing, as I am dictating this reply on my phone since I am not at a computer at the moment
A successful update has been performed. I differ from the instructions a little bit I like to keep all back up so I just renamed my old directory to old2.
I uncommented my original yaml configuration, which contains two weather integrations, one for hourly, one for daily. I also uncommented my sensor configuration.
TLDR:

can only create through GUI one integration

does not properly import config files that include more than one integration, including sensors.

only the last configuration will import.

oddly when more than two integrations are present, two will be imported (my config includes three which includes the sensor section)

As for the results of the import.

my configuration has two weather integrations one named home and one named home hourly.
Home is listed first hourly is listed second in the config. When imported only the hourly config is imported properly, the daily one is not imported at all.

My configuration also has a section for sensors, which is imported alongside the hourly integration.

when attempting to comment out the second weather integration, and redo the import after deleting the integrations. It will result in only the sensors being imported, if the only two integrations that are not commented are the sensors and a weather integration.

deleting the integration and commenting out the whole config, then proceeding to reboot and then create the integration yourself. It will allow you to create only one integration and you could check both the sensors and weather options. If you attempt to create a second integration it will allow you to enter the configuration details but once you continue it will give you an error saying the location is already configured. (Paraphrased that, I am dictating my report a the moment since I'm not at a computer.)

Ok, this is super helpful feedback!  That would really help to debug this, since the issues you're hitting here are pretty important!

Here is the requested config with api and location info stripped.
weather:
  - platform: pirateweather
    api_key: ""
    # Additional optional values:
#    latitude:
#    longitude:
    #mode: "hourly"  (default) or "daily"
    mode: "daily"
    name: Home
  - platform: pirateweather
    api_key: ""
    # Additional optional values:
#    latitude:
#    longitude:
    #mode: "hourly"  (default) or "daily"
    mode: "hourly"
    name: Home Hourly

# you can also get a sensor data
sensor:
  - platform: pirateweather
    api_key: ""
    scan_interval: '00:15:00'
    monitored_conditions:
      - alerts
      - nearest_storm_distance
      - temperature
      - precip_probability
      - precip_type
      - humidity
      - cloud_cover
      - precip_intensity
      - wind_speed
      - wind_gust

Hey, quick update. I found a possible error in my configuration that may have been producing some inconsistencies in the sensor portion of the config. I didn't notice the error at all because it isn't something that home assistant considers an error; however, I could see it producing issues.
It was a duplicate key within the configuration.yaml for sensor:  , the first one directs homeassistant to include the sensors.yaml file while the second was the pirateweather platform.
I will get back to you on the results of this as its pretty late and I'm not up for retesting the import at the moment.

Oh, that's interesting- it's an easy mistake to make, I also had duplicate sensor blocks in mine at one point. Thanks for catching it, and let me know what happens once that's resolved

The removal ofthe duplicate key in config has no effect on the bug. The bug is still present.

I have installed the latest version of the integration.  I have an issue, I am running on a test system and only had the weather block in the configuration.yaml file when I installed.  It loaded and worked.  But, since never having this installed before, I attempted to check both Sensor and Weather and assigned a few sensors and rebooted.  Still have a good forecast but the sensors I added never appeared.

So, as a followup attempt I added the following to my sensors file and removed the sensors from the UI and rebooted expecting the yaml sensors to be imported.  Did not gain new sensors upon reboot.
Added sensor config:
- platform: pirateweather
  api_key: "9snAKslklf4cKDXfZYGDc6sC3zhAVs6rBjuBi7Qg"
  scan_interval: '00:15:00'
  monitored_conditions:
    - alerts
    - nearest_storm_distance
    - temperature
    - precip_probability
    - precip_type
    - humidity
    - cloud_cover
    - precip_intensity
    - wind_speed
    - wind_gust

Is the source of data the same as DarkSky?  I have noticed that my default location data from DarkSky and PirateWeather differ a few degrees.  And I am not sure how to kill off DarkSky, I have removed it from the weather and sensor blocks but it keeps updating.

The sensor key "    - apparent_temperature" appears to not be considered valid in my initial sensor block...
Invalid config for [sensor.pirateweather]: apparent_temperature is not a valid option for dictionary value @ data['monitored_conditions']. Got ['alerts', 'nearest_storm_distance', 'temperature', 'precip_probability', 'precip_type', 'humidity', 'cloud_cover', 'precip_intensity', 'wind_speed', 'wind_gust', 'apparent_temperature']. (See ?, line ?).

Thanks @mattlward, thanks for moving the thread over here- helps me to keep everything in one place, and since I have a 2-month old, I need all the reminders I can get!
I'll take a look at the apparently temperature sensor today and see if I can solve that one! As far as a data source goes, that's the coolest part of this integration (by far). This is a whole separate weather forecast API (which I'm way more comfortable with than this sort of coding), which creates a forecast directly from NOAA models. So it should be similar to Dark Sky, but likely won't ever be the same

Thank you again to everyone who has been testing this! To respond to questions:

@mattlward, that's a good catch. I'll clarify the documents to explain that if multiple weather entities are needed, they need to have different names, This shouldn't be too much of a limitation, since it would get way too complicated with things having the same name anyway.
@mattlward, another good catch with the apparent temperature issue! This one was just a typo, and should be fixed now!
@coaster3000, this one was interesting! The root cause stemmed from you doing something I didn't think was possible- having a sensor with no hourly or daily forecast times configured. This seems to work, but since I didn't realize it was possible, I used these as a shorthand for checking if something was a sensor or weather entity. I've added a name check to the unique ID, which lets the setup know that there's something new to add!
@myopenflixr, rounding should be improved now! I switched it to return an integer for the rounded value, as opposed to just rounding it, which should remove the decimal. Just to clarify, you were talking about the sensors here, not the weather entity?

New version will be pushed shortly! Please DELETE any existing integrations and uncomment your configuration.yaml before following the steps. Because the unique-id has changed, it needs to start this from scratch.

Just passing along another update here- I pushed a new change that cleans up some of the language, clarified some warnings, and fixes the scan interval parameter, so two more items off the list!
I'm considering if it's worth keeping the options configuration around? It would be nice to be able to change monitored conditions after the initial setup; however, since I can't seem to correct the orphan entity issue, I'm worried that it might create more confusion than it's worth compared to just deleting and recreating an integration. I sent a message to discord, so we'll see if they have any suggestions. The other idea would be to keep the options flow, but only allow the name, location, forecast mode, units, and rounding to be changed? This would avoid any entity deletion issues, while allowing a few things to be edited.

HI. Thanks for this! I am running this development version now. I really like the simple way of checking sensors to add them.
I'm new to HA and a long time Samsung SmartThings user.
I got confused in the instructions with which Integration page -the  HACS Integrations or the main Integrations. I'm still learning the nomenclature in HA, so that has a factor :)
I experimented with the 'replacement for DarkSky' idea a while, thinking it is something I NEEDED to do for HA to work well. Is that necessary if I started using HA in October 2022? I have come to the conclusion I do not.
Thanks again!!

Finally updated the dev version, I have been pretty busy lately.
The import ran exactly as expected this time around. I will fiddle around and see if there is anything left I can find.
One thing I found so far with the config flow setup is the ability to create an integration without specifying weather or sensors to be used. Understandably, this is user error; however, it may be beneficial to warn the user about this mistake during the setup process if that is possible.
It will reduce unwanted complaints / bug reports on the matter.

That's a really good point about the flow setup check boxes, and I can foresee issues stemming from that. I'll change it so at least one has to be selected, since it really wouldn't make sense otherwise

And we're live! I pushed this update out via HACS today, so I'm going to close this thread for now. If (when) other issues come up with the update, please open new issues and we can tackle them one by one.
Thank you again for everyone for helping to debug this, I really appreciate the help, and wouldn't have made it to a release without the feedback here,


chore: dag block proposal limit

On high transactions per second load on the network dag block and transactions packets start queueing up in the packet queue. This causes delays in receiving DAG block packets which makes nodes propose dag blocks with high difficulty or even stale since the low difficulty dag blocks are not received in time. This causes a chain reaction with more dag block being produced it is less likely for the network to digest it in time.
To prevent this:
Node is not to produce a dag block if the queue is over the queue limit
Node is not to produce a dag block if total non finalized transactions are over the limit

prnet cleaned-up successfully


comma separated queries not working

Describe the bug
According to https://todoist.com/help/articles/introduction-to-filters-V98wIH it is possible to use a ","  to "Separates filter queries into separate lists". This seems to be not working in Obsidian.
To Reproduce
Sample query in Todoist:
#A Kalender & (overdue|today) , ##A Areas & @arbeit & (overdue | today)
Resultset in Todoist:

Sample query in Obsidian:
name: comma separated, not working in obsidian
filter: "#A Kalender & (overdue|today) , ##A Areas & @arbeit & (overdue | today)"
group: true
sorting:
   - date
   - priority

Resultset:

Using a | (or) between the queries as a workaround.
Expected behavior
Both applications should show the same resultset.
Desktop (please complete the following information):

Plugin Version 1.11.1
Obsidian Version 1.5.3 with installer 1.4.13

Looks like another instance of #34 as far as I can tell!


redis-cell support cluster?

hi,i want to know redis celll support redis cluster? according to  https://redis.io/topics/modules-api-ref, i not found "getkeys-api" in your code.

Hi @cnsky2016, unfortunately I don't have a good answer here — I don't think there any blockers to get it going on Redis Cluster, but I'm not sure about that.

according to https://redis.io/topics/modules-api-ref, i not found "getkeys-api" in your code.

Reading through the module docs, I don't think we need getkeys-api:

"getkeys-api": The command implements the interface to return the arguments that are keys. Used when start/stop/step is not enough because of the command syntax.

As of @xiezhenye's change yesterday in #29, we now correctly pass keystart/keystop/keystep, and because the command interface is relatively simple, I think those are enough and no more advanced keys interface is required.
(That said, I haven't tested.)

Hi, I have been trying to get this module working in a cluster. Unfortunately even after @xiezhenye's changes I wasn't able to to get the module working in a cluster. Once I added a call to 'replicateVerbatim' I was able to get the module to work as expected in a cluster - although this led to problems with the StackExchange client i'm using, since the client wasn't being made aware of the key it was unable to determine which node to select

Thanks @profporridge.

although this led to problems with the StackExchange client i'm using, since the client wasn't being made aware of the key it was unable to determine which node to select

Is there something in the client that can be fixed there? I'm not sure I completely understand, but it seems like the interface might need to be tweaked so that it knows which arguments are keys when invoking custom commands.

The client needs to know what the key is so that it can determine which node to run the command on. It's entirely a client problem.

The client needs to know what the key is so that it can determine which node to run the command on. It's entirely a client problem.

Both client and server should know which arguments are keys.

After server command info fixed, redis-cell can work correctly with redis-cli and Jedis.

Excellent!


Fix visual studio applying nodereuse despite MSBUILDDISABLENODEREUSE being set

Fixes #5221
See https://github.com/microsoft/msbuild/issues/5221#issuecomment-645026616 for details

After some investigation it looks like MSBuild is launched differently for Design Time Builds compared to regular builds. These builds don't respect the environment variable MSBUILDDISABLENODEREUSE because they explicitly set nodeReuse to true.

Might someone who does almost exclusively DTBs and wants them to reuse nodes/go fast but wants full builds to not reuse nodes see this as a breaking change? If so, is that a group we want to consider?


CLN: fix all flake8 warnings in pandas/tseries

Looks good from a quick glance! (and for the diffs I could see)

Cool, I can merge after Travis passes if we're all good

If someone else can +1 this and also review #12082 I can merge both of those

I fixed it!

lgtm otherwise

@jreback I nixed the resample.py diff, will merge when the build passes

Cherry-picked in 1acdb31d9348f70f1cc77790fbc7bee568366cdd

merge away


"Sorting" link in README.md leads to 404

Describe the bug
This link in the README is not working. I'd update it with the right one myself, but I don't know what that would be. Sorry!

Hello @gassiss
I contacted the doc team because it looks more like an issue on the docs side. This link is supposed to exist

I checked with documentation team, and now it's solved, the redirection is correctly done
closing the issue


bkcrack: init at 1.5.0

Description of changes
bkcrack is useful in some Capture-the-Flag security challenges.
Might be linked with https://github.com/NixOS/nixpkgs/issues/81418.
Things done

Built on platform(s)

[X] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Does upstream specifically set the date to 1980? or is this a build issue?

Date is fixed to 1980-01-01 for reproducibility during build. Should I patch the code to remove the build date from the version string?

oh ok. However I don't really know what advice to give you, I have not come across a similar issue during my time packaging. If it were for me to decide I would keep the upstream release date as the build time, but that might not be what nixpkgs people would want. Try asking on discourse, or wait for another reviewer to show.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1470


parser bug: hurt amount parsing

https://github.com/genshinsim/gcsim/blob/6949f16af1c81acff8f466c61dc4a99778783c02/pkg/parse/parseHurt.go#L106
should be accept itemComma for second number

e68c12e


Update asciidoctor diagram from version 1.3.0.preview.1 to 1.3.0

As there is a new release of asciidoctor-diagram, let's use this version instead of the previous preview one.

:+1:

Thank you!
Sorry for the long time until this got merged.


[BUG] 1.5.1: AttachVolume.Attach failed for volume "pvc-xxx » […] volume pvc-xxx failed to attach to node node0x with attachmentID csi-xxx

Describe the bug (🐛 if you encounter this issue)

Sometimes, after cordon / drain from a cluster node, some pods remain in the pending state.
The events generally display :
LAST SEEN   TYPE      REASON               OBJECT                           MESSAGE
75s         Warning   FailedAttachVolume   pod/keycloak-test-postgresql-0   AttachVolume.Attach failed for volume "pvc-b91abf30-485d-4aeb-96e1-938a50bdb291" : rpc error: code = Internal desc = volume pvc-b91abf30-485d-4aeb-96e1-938a50bdb291 failed to attach to node node03 with attachmentID csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a: the volume is currently attached to different node node04
10m         Warning   FailedMount          pod/keycloak-test-postgresql-0   Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[dshm data kube-api-access-cjdtl]: timed out waiting for the condition

I have no way of getting this pod to work again, and the volume seems healthy on the UI.
Environment

Longhorn version: 1.5.1
Installation method: Helm
Kubernetes distro (Official Kubernetes with Kubespray and version: 1.24

Number of management node in the cluster: 3
Number of worker node in the cluster: 4

Node config

OS type and version: Debian 10
Kernel version: 4.19.0-25-amd64
CPU per node: 96
Memory per node: 256
Disk type(e.g. SSD/NVMe/HDD): SSD

My support bundle is ~600 mb, I'll prepare the upload and send it to the support.

I have read this discussion but I haven't found the answer to my problem, so I'll have to look into it further.
If it helps, I've already noticed in the past that AttachmentID ticket was set to null in some cases.
But I don't know any further…
Here's an example of the volumeattachment pvc-b91abf30-485d-4aeb-96e1-938a50bdb291  :
status:
  attachmentTicketStatuses:
    csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a:
      conditions:
      - lastProbeTime: ""
        lastTransitionTime: "2023-11-14T10:52:36Z"
        message: 'the volume is currently attached to different node node04 '
        reason: ""
        status: "False"
        type: Satisfied
      generation: 0
      id: csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a
      satisfied: false
    longhorn-ui:
      conditions:
      - lastProbeTime: ""
        lastTransitionTime: "2023-11-13T19:20:55Z"
        message: ""
        reason: ""
        status: "True"
        type: Satisfied
      generation: 0
      id: longhorn-ui
      satisfied: true

FYI we only provision Longhorn volumes by doing a kubectl apply -f pvc.yaml, nothing with the Longhorn UI directly.

Could you provide the support bundle? It would be appreciated.

Do you have an email address so that I can send you a link to share the support bundle (600 mo) ?
The workaround did not help unfortunately.
And this issue started well before 1.5.0.

Sure, please send it to<EMAIL_ADDRESS>Thanks.

Mail sent.

@mantissahz Do we have any update on this ticket?

Lots of abnormal logs in longhorn-manager-kvz8s (node: gamora-node02.mrs.antidot.net), but not related to pvc-b91abf30-485d-4aeb-96e1-938a50bdb291
2023-12-11T10:51:00.552753636Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: "
2023-12-11T10:51:00.552774886Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: goroutine 75 [GC worker (idle)]:"
2023-12-11T10:51:00.552784606Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)"
2023-12-11T10:51:00.552792087Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc000505f50 sp=0xc000505f30 pc=0x43b556"
2023-12-11T10:51:00.552797737Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-d9ee1050-b345-4a74-8a85-951d1142bb40-e-4a4338f2: \t/usr/local/go/src/runtime/mgc.go:1275 +0xf1 fp=0xc000521fe0 sp=0xc000521f50 pc=0x41d891"
2023-12-11T10:51:00.552806797Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: runtime.gcBgMarkWorker()"
2023-12-11T10:51:00.552815937Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/mgc.go:1275 +0xf1 fp=0xc000505fe0 sp=0xc000505f50 pc=0x41d891"
2023-12-11T10:51:00.552840948Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: runtime.goexit()"
2023-12-11T10:51:00.552858748Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000505fe8 sp=0xc000505fe0 pc=0x46cc21"
2023-12-11T10:51:00.552877028Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: created by runtime.gcBgMarkStartWorkers"
2023-12-11T10:51:00.552888858Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/mgc.go:1199 +0x25"
2023-12-11T10:51:00.552912509Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: "
2023-12-11T10:51:00.552936979Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: goroutine 28 [GC worker (idle)]:"
2023-12-11T10:51:00.552977310Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)"
2023-12-11T10:51:00.552994701Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/proc.go:381 +0xd6 fp=0xc0003e2f50 sp=0xc0003e2f30 pc=0x43b556"
2023-12-11T10:51:00.553011521Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: runtime.gcBgMarkWorker()"
2023-12-11T10:51:00.553025241Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/mgc.go:1275 +0xf1 fp=0xc0003e2fe0 sp=0xc0003e2f50 pc=0x41d891"
2023-12-11T10:51:00.553029681Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: runtime.goexit()"
2023-12-11T10:51:00.553067412Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0003e2fe8 sp=0xc0003e2fe0 pc=0x46cc21"
2023-12-11T10:51:00.553081882Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: created by runtime.gcBgMarkStartWorkers"
2023-12-11T10:51:00.553111323Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: \t/usr/local/go/src/runtime/mgc.go:1199 +0x25"
2023-12-11T10:51:00.553139804Z time="2023-12-11T10:51:00Z" level=warning msg="pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5: "

tgtadmn error in instance-manager-9d74fce300692af21ca95cc70c0cf3f6 (node: gamora-node02.mrs.antidot.net)
2023-12-11T10:51:06.514844594Z tgtd: target_mgmt(147) Failed to unbind by address: ALL
2023-12-11T10:51:06.515290823Z [pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5] time="2023-12-11T10:51:06Z" level=warning msg="failed to unbind initiator target id 56" error="failed to execute: tgtadm [--lld iscsi --op unbind --mode target --tid 56 -I ALL], output , stderr tgtadm: this access control rule does not exist\n: exit status 22"
2023-12-11T10:51:06.518378615Z tgtd: tgt_device_destroy(734) device 1 not found
2023-12-11T10:51:06.518935706Z [pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5] time="2023-12-11T10:51:06Z" level=error msg="Failed to init frontend" error="device pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b: failed to delete target iqn.2019-10.io.longhorn:pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b: failed to execute: tgtadm [--lld iscsi --op delete --mode logicalunit --tid 56 --lun 1], output , stderr tgtadm: can't find the logical unit\n: exit status 22"
2023-12-11T10:51:06.519284604Z [pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b-e-4204b0c5] time="2023-12-11T10:51:06Z" level=error msg="failed to init frontend: device pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b: failed to delete target iqn.2019-10.io.longhorn:pvc-3e29a240-cd2a-4d24-b4a7-e16412ba3f9b: failed to execute: tgtadm [--lld iscsi --op delete --mode logicalunit --tid 56 --lun 1], output , stderr tgtadm: can't find the logical unit\n: exit status 22"

tgtd io error in instance-manager-f563d24a9631ecb0dfbc0a26e8b5b3f6 (node: gamora-node04.mrs.antidot.net)
[pvc-157c0077-d57b-4095-ab2e-95e2b12cf5c1-e-c620f47b] time="2023-12-11T07:48:07Z" level=error msg="I/O error" error="no backend available"
2023-12-11T08:48:07.558147641+01:00 response_process: Receive error for response 3 of seq 14
2023-12-11T08:48:07.558178522+01:00 tgtd: bs_longhorn_request(111) fail to read at 52363264 for 4096
2023-12-11T08:48:07.558185332+01:00 tgtd: bs_longhorn_request(210) io error 0x2195370 28 -14 4096 52363264, Success
2023-12-11T08:48:07.559578073+01:00 [pvc-157c0077-d57b-4095-ab2e-95e2b12cf5c1-e-c620f47b] time="2023-12-11T07:48:07Z" level=error msg="I/O error" error="no backend available"
2023-12-11T08:48:07.559623254+01:00 response_process: Receive error for response 3 of seq 15
2023-12-11T08:48:07.559669584+01:00 tgtd: bs_longhorn_request(111) fail to read at 52363264 for 4096
2023-12-11T08:48:07.559676184+01:00 tgtd: bs_longhorn_request(210) io error 0x2195370 28 -14 4096 52363264, Success

timeout in longhorn-csi-plugin-nhbz7 and longhorn-csi-plugin-rdm2b(node: gamora-node04.mrs.antidot.net and gamora-node01.mrs.antidot.net)
2023-12-04T01:27:05.342190637Z time="2023-12-04T01:27:05Z" level=warning msg="Timeout wTile waiting for volume pvc-b91abf30-485d-4aeb-96e1-938a50bdb291 state volume published" component=csi-controller-server function=waitForVolumeState
2023-12-04T01:27:05.342368029Z time="2023-12-04T01:27:05Z" level=warning msg="Timeout wTile waiting for volume pvc-05c64e1c-d3a4-4dd7-a73e-a2bfdbdf7029 state volume published" component=csi-controller-server function=waitForVolumeState
2023-12-04T01:27:05.343739249Z time="2023-12-04T01:27:05Z" level=warning msg="Timeout wTile waiting for volume pvc-f7deeac1-0cdc-4d9b-991c-e82e89e13c37 state volume published" component=csi-controller-server function=waitForVolumeState
2023-12-04T01:27:05.343783199Z time="2023-12-04T01:27:05Z" level=warning msg="Timeout wTile waiting for volume pvc-a574efdb-67fc-49f5-b592-9f595d1e3b9a state volume published" component=csi-controller-server function=waitForVolumeState
2023-12-04T01:27:05.343799890Z time="2023-12-04T01:27:05Z" level=warning msg="Timeout wTile waiting for volume pvc-f7deeac1-0cdc-4d9b-991c-e82e89e13c37 state volume published" component=csi-controller-server function=waitForVolumeState
2023-12-04T01:27:05.344350258Z time="2023-12-04T01:27:05Z" level=error msg="ControllerPublishVolume: err: rpc error: code = Internal desc = volume pvc-af228e2c-31b6-4d34-9e19-93361523a138 failed to attach to node gamora-node02.mrs.antidot.net with attachmentID csi-296d01a447e660085b35bb7cf415dd42c718ef945ce227414e198c30d943d422: the volume is currently attached to different node gamora-node04.mrs.antidot.net "
2023-12-04T01:27:05.345957931Z time="2023-12-04T01:27:05Z" level=error msg="ControllerPublishVolume: err: rpc error: code = Internal desc = volume pvc-b91abf30-485d-4aeb-96e1-938a50bdb291 failed to attach to node gamora-node03.mrs.antidot.net with attachmentID csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a: the volume is currently attached to different node gamora-node04.mrs.antidot.net "

error logs in csi-attacher-6849b55d9d-9sc67 (node: gamora-node04.mrs.antidot.net)
Error processing "csi-418a114e5c70ed04ca878d8ce5303eadc351186683973c99adf2e87e477310e9": failed to attach: rpc error: code = DeadlineExceeded desc = volume pvc-a8180865-3f15-4519-8028-0f6d8ff17453 failed to attach to node gamora-node02.mrs.antidot.net with attachmentID csi-418a114e5c70ed04ca878d8ce5303eadc351186683973c99adf2e87e477310e9
2023-12-11T04:19:11.916612031+01:00 I1211 03:19:11.916496       1 csi_handler.go:251] Attaching "csi-418a114e5c70ed04ca878d8ce5303eadc351186683973c99adf2e87e477310e9"
2023-12-11T04:19:26.918242408+01:00 I1211 03:19:26.918115       1 csi_handler.go:234] Error processing "csi-57e353d5b87a90370548a2a1da1aa8edd5be3e746f455f71f2994b268fa24a37": failed to attach: rpc error: code = DeadlineExceeded desc = volume pvc-9e9eee9c-06fe-4541-b8aa-3d9accb1a097 failed to attach to node gamora-node01.mrs.antidot.net with attachmentID csi-57e353d5b87a90370548a2a1da1aa8edd5be3e746f455f71f2994b268fa24a37
2023-12-11T04:19:26.918288889+01:00 I1211 03:19:26.918194       1 csi_handler.go:251] Attaching "csi-57e353d5b87a90370548a2a1da1aa8edd5be3e746f455f71f2994b268fa24a37"
2023-12-11T04:19:41.736858141+01:00 I1211 03:19:41.736740       1 csi_handler.go:234] Error processing "csi-91c941c74fbff5f67b6f0be72ad5e96edd42d4d192302f7254f1beb4800762e5": failed to attach: rpc error: code = DeadlineExceeded desc = volume pvc-a8180865-3f15-4519-8028-0f6d8ff17453 failed to attach to node gamora-node01.mrs.antidot.net with attachmentID csi-91c941c74fbff5f67b6f0be72ad5e96edd42d4d192302f7254f1beb4800762e5
2023-12-11T04:19:41.737479171+01:00 I1211 03:19:41.737430       1 csi_handler.go:234] Error processing "csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a": failed to attach: rpc error: code = Internal desc = volume pvc-b91abf30-485d-4aeb-96e1-938a50bdb291 failed to attach to node gamora-node03.mrs.antidot.net with attachmentID csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a: the volume is currently attached to different node gamora-node04.mrs.antidot.net
2023-12-11T04:19:41.737534412+01:00 I1211 03:19:41.737480       1 csi_handler.go:251] Attaching "csi-a782ae047fc39dbf4c999f20196ca3ce16d7d9bf7cb5382a57839f1c2b9f6e8a"
2023-12-11T04:19:41.739962638+01:00 I1211 03:19:41.739920       1 csi_handler.go:234] Error processing "csi-4f461175e027366309908ac75ce578b338bbb0a636149c39a7e53d8995c12662": failed to attach: rpc error: code = Internal desc = volume pvc-a574efdb-67fc-49f5-b592-9f595d1e3b9a failed to attach to node gamora-node01.mrs.antidot.net with attachmentID csi-4f461175e027366309908ac75ce578b338bbb0a636149c39a7e53d8995c12662: the volume is currently attached to different node gamora-node02.mrs.antidot.net

@PhanLe1010,
Does it look like a tgtd issue?

The logs look as if some instance-manager pod crash to me.
Btw, for the multi-attach error at https://github.com/longhorn/longhorn/issues/7313#issuecomment-1850177401. Are you still having the issue @CaptainKrby ? If yes, can you try to edit volumeattachment pvc-b91abf30-485d-4aeb-96e1-938a50bdb291 and remove the longhorn-ui ticket from the Spec? See if it can fix the problem?

Hello @PhanLe1010 I deleted the longhorn-ui ticket from my vollumeattachment pvc-b91abf30-485d-4aeb-96e1-938a50bdb291 then restarted the pod and that solved the problem thanks.
However, how can I patch all my volumes and ensure that this does not happen again in the future?

However, how can I patch all my volumes and ensure that this does not happen again in the future?

Hi @CaptainKrby  We would like to investigate. Did you recently upgrade Longhorn? If so from which version to which version?  Did this issue appear before/after the upgrade?

Hi @PhanLe1010,  We've been dealing with this type of problem since July, i.e. since 1.5.0, then when I encountered the current problem I immediately upgraded to 1.5.1 but there's been no improvement. Each upgrade of Kubernetes is complicated because a large proportion of our volumes remain pending because the pods aren't scheduled on the right node. Before upgrading to this major release we were on 1.4.3. We've been updating Longhorn since 1.2.x or a little earlier.

I also encountered a curious situation, on attachmentTicket pvc-a574efdb-67fc-49f5-b592-9f595d1e3b9a I was forced to delete a null ticket so that the pod could reschedule:
spec:
  attachmentTickets:
    "":
      generation: 0
      id: ""
      nodeID: node02
      parameters:
        disableFrontend: "false"
        lastAttachedBy: ""
      type: longhorn-api

Thanks @CaptainKrby for the update! I will try to reproduce this issue in lab. What is the yaml of one of your typical workload?

Hello @PhanLe1010 best wishes for 2024,
We have found that a helm kafka deployment bitnami/kafka:3.4.0-debian-11-r28 often encountered the problem.
Our conf is very very basic, in persistence we declare :
persistence:
enabled: true
size: 2Gi
storageClass: longhorn
Then it ends up working for a while, and one day after a node reboot or a helm upgrade you come back to the initial problem. Hard to reproduce from the given workaround —> https://github.com/longhorn/longhorn/issues/7313#issuecomment-1863606967
If you need any further details don’t hesistate.

@PhanLe1010 do you need more examples of this or did you get a chance to recreate this? I've been having a similar problem for a while now, I can try to provide more data if that would be helpful.

The same goes for me, after a reboot campaign, a lot of pods got stuck. I took the opportunity to regenerate a bundle if that helps.

Hi @EStork09 @CaptainKrby
More data to reproduce would be great. Like:

Deploy Longhorn version xxx
Deploy workload, chart yyy . I know @CaptainKrby provided bitnami/kafka but is there any more lightweight and simpler workload?
Do some operation repeatedly
Hit the multi-attach error

Hit this issue after etcd snapshot restore and reboot all k8s nodes.
Maybe this workaroud(https://github.com/longhorn/longhorn/issues/6287#issue-1797959617) is also work(haven't try): The workaround is restart longhorn-manager pod that failed to attach/detach a volume.
Another workaroud for apply to all volumes is force detach affected volumes and delete related volumeattachment:
#!/bin/bash

volume_attachments=$(kubectl get volumeattachment | grep longhorn | grep false)

while read -r line; do
  volume_attachment_name=$(echo "$line" | awk '{print $1}')
  longhorn_volume_name=$(echo "$line" | awk '{print $3}')
  host=$(echo "$line" | awk '{print $4}')

  volume_info=$(kubectl get volume -n longhorn-system "$longhorn_volume_name" -o json)
  current_node_id=$(echo "$volume_info" | jq -r '.status.currentNodeID')

  if [ "$host" != "$current_node_id" ]; then
    echo "attach: $volume_attachment_name, volume: $longhorn_volume_name, expected_host: $host, cur: $current_node_id"
    curl -X POST "http://<Longhorn Frontend>/v1/volumes/$longhorn_volume_name?action=detach" -H "Content-Type: application/json" -d '{"forceDetach": true, "attachmentID": "longhorn-ui", "hostId": ""}' > /dev/null
    kubectl patch volumeattachment $volume_attachment_name -p '{"metadata":{"finalizers":null}}'
    kubectl delete volumeattachment $volume_attachment_name --wait=false
  fi
done <<< "$volume_attachments"

We will investigate this ticket in https://github.com/longhorn/longhorn/issues/8339


Cannot read properties of undefined (reading ‘default’)

Reproduction
It is impossible to reproduce the issue because the error occurs for 2-3% of users, and I can’t simulate this
Approximately 1-2% of users on my website encounter the error Cannot read properties of undefined (reading 'default') or undefined is not an object (evaluating 'r.default') in nuxt-layout.js.
Additionally, there is an error Couldn't resolve component "default" at "/shop/:slug(.)" in vue-router.mjs.
The problem is that this error occurs for a small percentage of users, and I can’t capture this error to fix it. Has anyone worked with a similar error?

My structure is:
App.vue

default.vue layout

Same error in the middleware section, wondering if it's related to the vercel build output. @VDidyk is your nuxt application hosted on Vercel?

Same error in the middleware section, wondering if it's related to the vercel build output. @VDidyk is your nuxt application hosted on Vercel?

No, it’s not Vercel. I have no idea what could be wrong. Moreover, I see in the logs when the $fetch request is sending, it shows  and Failed to fetch. Also, this affects 2-3% of users.

Do these errors come around the time of a redeploy? Could it be a chunk loading error?

Do these errors come around the time of a redeploy? Could it be a chunk loading error?

I added an error logging message ‘Error in chunk’ if a chunk error occurs. As I can see, 100% of those errors include this message. However, this error also occurs even 2-3 days after the deployment, so I don’t understand why that happens

Encountered the same issue.
It appears after deployment to production, regardless of the deployment platform. After deploying the new version, I occasionally experience this issue. Sentry has also collected issues of this error from other users occasionally.

Hi @VDidyk :)
If you're encountering a chunk error, the link below might be helpful. It’s possible that when you deploy, the old JavaScript chunk files are being referenced.
23612

Hello!
Thank you for your reply!
I’ve already created a plugin to reload the page when a chunk error occurs:
export default defineNuxtPlugin((nuxtApp) => {
nuxtApp.hook('app:chunkError', (error) => {
console.log('Error in chunk:', error)
window.location.reload()
});
});
But the question is why it occurs if app was not rebuilt during several days, and if it creates such errors as I described in the description of issue
However, my question is why this error is happening, even though the app has not been rebuilt for several days. Additionally, if chunk error creates such errors as I described in the description of issue?

I guess it depends on what your system configuration is like, what is the cache ?
In my case, I had an example where I had an edge server in between and the cache settings were returning old resources.

@VDidyk I guess it depends on what your system configuration is like, what is the cache ? In my case, I had an example where I had an edge server in between and the cache settings were returning old resources.

I am using NGINX and PM2, with no proxy servers and no additional caching.

It’s definitely not a chunk error. I noticed that, before this error occurs, the client likely has a slow internet connection or something similar, because I observed that the JS file load time was around 3-4 seconds, sometimes even longer.

Getting the same error after updating nuxt version from 3.13.0 to 3.13.2 and we use CDN here to keep old files existing, so I don't think this is the reason.

Getting the same error after updating nuxt version from 3.13.0 to 3.13.2 and we use CDN here to keep old files existing, so I don't think this is the reason.

Are you getting errors "Failed to fetch"? It happens with random $fetch request

@VDidyk , sorry, I didn't give enough context. I'm getting this:  undefined is not an object (evaluating 'o.default')
File error: node_modules/nuxt/dist/app/components/nuxt-layout.js - line 17:69 (same as issue description)

Browsers
Mobile Safari 17.6 -> 40%
Chrome Mobile iOS 130.0.6723 -> 32%
Mobile Safari 18.0.1 -> 9%
Mobile Safari 16.6 -> 2%
Other -> 15%
Device
Iphone -> 95%
Mac -> 5%

@VDidyk , sorry, I didn't give enough context. I'm getting this: undefined is not an object (evaluating 'o.default')
File error: node_modules/nuxt/dist/app/components/nuxt-layout.js - line 17:69 (same as issue description)

Browsers
Mobile Safari 17.6 -> 40% Chrome Mobile iOS 130.0.6723 -> 32% Mobile Safari 18.0.1 -> 9% Mobile Safari 16.6 -> 2% Other -> 15%
Device
Iphone -> 95% Mac -> 5%

I see. It was extra question :)

Hi,
I had also the same issue,
after reloading a route in the nuxt app, I got this error.
After deleting the local browser cache, it vanished.
Maybe some duplications with the generate cache breaker names of the chunks?
Until now, I have not been able to reproduce this.
Greetings

Hi, I had also the same issue, after reloading a route in the nuxt app, I got this error. After deleting the local browser cache, it vanished. Maybe some duplications with the generate cache breaker names of the chunks? Until now, I have not been able to reproduce this.
Greetings

What version of Nuxt do you have?

Unfortunately, my package.json says "nuxt": "^3.13.2" so it is one of the versions onwards
Could not find the version in the build output files in the docker container. If you have a hint for me, how to find the version in the build output files. I can check again.
Greetings

Have the same issue, with same nuxt version (3.13.2)
In my case, the behavior was quite strange. The application was last updated 2 days ago, and there were no errors afterward.
Today, at 11:18, there was a backend update (during which it returned a 500 error for all requests for a couple of minutes). After that, errors of three types started appearing in Sentry:
undefined is not an object (evaluating 'r.default')
Importing a module script failed.
Couldn't resolve component "default" at "/"
What is even stranger is that, according to Sentry, these errors are only occurring on iPhones and Macs.
Additionally, memory started leaking in the application, and CPU usage increased.
Later, after some time (about an hour), the number of such errors significantly decreased, but they are still present.

Hello,
I have the same issue.
Using NUXT v3.14.159.

Hello, I have the same issue. Using NUXT v3.14.159.

I was hoping the issue would disappear in version 3.14 :(

Hi, I had also the same issue, after reloading a route in the nuxt app, I got this error. After deleting the local browser cache, it vanished. Maybe some duplications with the generate cache breaker names of the chunks? Until now, I have not been able to reproduce this.
Greetings

I have a similar suspicion, because when the incorrect URL is first accessed it returns a 404, but subsequent visits return the code. This definitely indicates that some file name hash calculations are being duplicated, and there's caching in the CDN - it probably only updates after several hours.

Same error here, anyone managed to fix it?

No luck using the chunk error hook neither, however I may have a piece of information that may help: one of our developers is located in Asia while most of the dev team is in Europe. Developers in Europe encountered the same error this morning, but our developer in Asia had no error.
We tried:
:x: redeploying the app from Vercel (forcing cache deletion)
:x: adding a new empty commit to the main branch, making Vercel deploy the application through the Vercel Github Integration
✅  adding a new commit to the main branch, with a code change containing a simple comment on the page with the 404 script not found error
Conclusion:

The fact that our guy in Asia had a working application vs. our dev in Europe had a buggy application points to a CDN issue
The fact that our application still encounters an error after deploying the same code base points to a caching mechanism
My guess is Vercel might keep some old versions of a page based on some changes hash in their regional CDNs.

Does that help anyone?

➡ My guess is Vercel might keep some old versions of a page based on some changes hash in their regional CDNs.

This was my guess as well. In our case, we use docker with nginx and no ssr. We deploy a few times a day and when a user changes routes during a deployment, my guess is that some old chunks still live in the browser which causes the error. I have no idea how to fix this elegantly though.

I found out that all errors appear only on Apple devices and in the Safari browser.

Is it possible to ping the creators to bring attention to this bug?

➡ My guess is Vercel might keep some old versions of a page based on some changes hash in their regional CDNs.

This was my guess as well. In our case, we use docker with nginx and no ssr. We deploy a few times a day and when a user changes routes during a deployment, my guess is that some old chunks still live in the browser which causes the error. I have no idea how to fix this elegantly though.

I have JS and CSS files being responded to with the header Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate. So, I’m not sure if the problem is with the chunks

We have also set Cache-Control to no-store, no-cache, must-revalidate, proxy-revalidate and like @VDidyk we are experiencing the same issue.
Our applications are in high traffic production environments and we are receiving numerous reports of this issue via Sentry. It is becoming a critical issue that requires immediate attention.
In some replays of the reports users are completely stuck due to this issue, 80% on mobile Safari browser.

I found out that all errors appear only on Apple devices and in the Safari browser.
Is it possible to ping the creators to bring attention to this bug?

Same issue for me, and it doesn't seems to be related to new deployment as the issue occurs all the time.
It's only affecting Safari, so it's probably NOT a deployment issue:

On the replay, the page display seems fine, before the error page.

It's only affecting Safari

For us:

485 Events in the last 24 days.
Most of them are on Safari mobile
~30 Safari
4 Chrome Mobile
1 Firefox Mobile (v132)
1 Firefox (v115)

I'm experiencing this same error. For me it's happening in my Cloudflare Pages preview environment.
I made some small refactors locally, deployed, site build succeeds. But when accessing the site I'm seeing the Nuxt 500 page in all browsers, all devices.
Looking at the Real-time Logs in CF, initial page hit includes
  "logs": [
    {
      "message": [
        "[nuxt] [request error] [unhandled] [500]",
        "Cannot read properties of undefined (reading 'extend')\n"
      ],
      "level": "error",
      "timestamp":<PHONE_NUMBER>540
    },
    {
      "message": [
        "[nuxt] [request error] [unhandled] [500]",
        "Cannot read properties of undefined (reading 'extend')\n"
      ],
      "level": "error",
      "timestamp":<PHONE_NUMBER>540
    }
  ],

Locally, I then tried pnpm run build then pnpm dlx wrangler pages dev dist to preview the build locally.
Hit with the same error. Debugger logs shows it originates in nitro.mjs but there's nothing really helpful as to what could be causing this error.

I also tried updating npm deps but that didn't didn't help.
I tried the suggestion of making a change on the page in question. It worked once locally after a local re-build and local preview. But I'm now consistently stuck with the 500 even with new changes.
I also checked out our main branch of our site in question, which hasn't been updated in almost 2 months. Made a small commit in a new branch to generate a preview build on a PR. Same issue occurs.
Really at a loss of how to even troubleshoot this.

@danielroe Sorry to bother you, but this issue continues to impact some users in production environments. What can we do to speed up this issue and try to figure out the root cause of the issue?
Unfortunately, we have seen this error from version 3.11.2 to the latest available version of Nuxt 3. According to our Sentry logs, a limited sample of users are stuck on the error page.
This seems like a pretty difficult problem to replicate and debug, do You have any suggestions for us?

What can we do to speed up this issue and try to figure out the root cause of the issue?

So far, we haven't seen a minimal reproduction shared in this thread. It would be hard for us to help as there seem to be a lot of factors involved. If it's hard to reproduce, I would suggest you try to do some investigation on your side and narrow down the factors and share with us as much information as possible for us to locate the potential causes. Thanks!

FWIW – I was able to circumvent the issue without ultimately figuring out what was causing it on my end due to time constraints.
Initially I removed a specific dependency from being used in a composable. That made the 500 go away on every route and page load. Then in specific user flows the 500 would re-appear. So for those specific routes that were still having 500s on a whim I tested the following in my nuxt.config.ts.
export default defineNuxtConfig({
  ...
  routeRules: {
    "my-parent-route/**": { ssr: false },
  },
});

It was enough to get those routes working again once deployed to Cloudflare pages
IDK if it's a package incompatibility issue with the Cloudflare pages ENVs or something else. Because as mentioned before, I checked out my main branch that hadn't been updated in 2 months and even that build was failing. So for something to all of the sudden stop working in a prod ENV is concerning.
Ultimately, I think the most frustrating aspect of this is how tough it is to debug something failing in a production build env. Felt like everything I was trying was a shot in the dark.
Does anyone have an pointers for how to making prod debugging / tracing issue like this any easier?

We experience the same issue in a production system and I can't reproduce it or figure out why/where it happens. It seems to happen in very unrelated parts of the app, not connected to a specifc functionality.
In our case:

90% Safari Mobile iOS
5% Safari MacOs
5% Chrome Mobile iOS

so it seems to only happen to apple users, although our sample is rather small (48 events)
In our case:

Hosted on Cloudflare pages
Not using any SSR (disabling ssr via routeRules)

I'm sorry I also cant provide a reproduction. But it seems Safari/iOS and Cloudflare Pages are mentioned a couple of times. If that helps to further narrow it down

We experience the same issue in a production system and I can't reproduce it or figure out why/where it happens. It seems to happen in very unrelated parts of the app, not connected to a specifc functionality.
In our case:

90% Safari Mobile iOS
5% Safari MacOs
5% Chrome Mobile iOS

so it seems to only happen to apple users, although our sample is rather small (48 events)
In our case:

Hosted on Cloudflare pages
Not using any SSR (disabling ssr via routeRules)

I'm sorry I also cant provide a reproduction. But it seems Safari/iOS and Cloudflare Pages are mentioned a couple of times. If that helps to further narrow it down

We don't deploy to Cloudflare Page, but have the same issue, only with apple devices too

This is resolved in https://github.com/nuxt/nuxt/pull/29957


force include of Ruby files; addresses #12

As said in the ticket, no idea when and if Rubocop will fix its omission of actual Ruby files from testing, and you should not be assuming people are restricted to old versions of Rubocop.

@opoudjis This list isn't very comprehensive too. Rubocop defaults match more file patterns, including shell scripts written in Ruby (to be precise: files starting with hashbang, followed by path to some Ruby interpreter).
After some research, I believe we should remove Include section entirely. I have explained it in #12 in order to keep discussion in one place. Also, I made #19 pull request.

Closing in favour of #19.


enhancement according to #87 (presenterFactory)

fixed warning with selector
introduced presenterFactory
moved presenterBuilders into BasePresenterFactory

Current coverage is 64.43%

Merging #88 into dev will increase coverage by +0.10% as of 3697040

@@              dev     #88   diff @@
=====================================
  Files          57      57
  Stmts        3039    3048     +9
  Branches        0       0
  Methods         0       0
=====================================
+ Hit          1955    1964     +9
  Partial         0       0
  Missed       1084    1084

Review entire Coverage Diff as of 3697040

Powered by Codecov. Updated on successful CI builds.

@diegosanchezr Thank you for your comments! That all makes sense.


[Mod Request] KSPX

@ClairaLyrae would need to approve this, but KSPX is a very popular mod maintained by @StupidChris
Kerbal Stuff page: https://kerbalstuff.com/mod/191/KSPX
Github page: https://github.com/StupidChris/KSPX
Kerbal Forum page: http://forum.kerbalspaceprogram.com/threads/107047
Should anything be disagreeable for any involved party, can a note please be made of it? Given the popularity, a request like this is likely to occur again.

Added in #800 with license field set to restricted so we comply with the no-redistribution policy. If permission is obtained to redistribute we can change the metadata.


api to dynamic change log level for debug convience

PUT /v1/debug
DELETE /v1/debug

ping @pwzgorilla


How to disable the carla.World.on_tick(callback) method.

I added a world.on_tick(callback_function) to the world. The function implements some routines relating to the player agent of the world. However, when I do world.restart(), the player agent and the sensors attached are destroyed. However, the simulator still tries to process the callback_function every tick.
I was wondering if there was a way to disable a world.on_tick(callback_function) routine to solve this problem.
For now, I implemented a return procedure at the start of the callback_function if the player is not alive. But it would be much better if the disable routine was provided.

Nope, currently there is no way of clearing "on_tick" callbacks. I'll add it now that I'm working in that part of the code.


chore: explicit message validation #NTRN-257

Task: https://hadronlabs.atlassian.net/browse/NTRN-257
List of changes:

Added message validation in each MsgServer handler.
Implemented unit tests.

Test run: https://github.com/neutron-org/neutron-tests/actions/runs/8823699280

LGTM, but please resolve conflicts

Done

Test run: https://github.com/neutron-org/neutron-tests/actions/runs/8940453918


PHP shebang not working

It appears the Runme kernel applies shell/bash normalization to the PHP code, which strips the leading $ for variables.
<?php
// PHP Script Example: Greeting with Date and Time

// Define a variable for the greeting
$greeting = "Hello, World!";

// Get the current date and time
$currentDateTime = date('Y-m-d H:i:s');

// Concatenate the greeting with the current date and time
$fullGreeting = $greeting . " It's now " . $currentDateTime;

// Output the full greeting
echo $fullGreeting;
?>

Reported by @edeediong.

Will fix this as part of releasing v2.

Fixed. Will go out with the next release.


Use tclConfig.h instead of tclConfig.sh.

MacPorts generates tclConfig.sh instead of tclConfig.h.  This prevents tcl from being properly rebuilt after running base/configure, e.g., with a new --prefix as reported in PR #79.
The attached diffs were created by adding m4_define(SC_USE_CONFIG_HEADERS) at the top of vendor/tcl8.5.19/unix/configure.in then running autoreconf in vendor/tcl8.5.19/unix to rebuild vendor/tcl8.5.19/unix/configure and vendor/tcl8.5.19/unix/tclConfig.h.in.  That's it.

Same comment as on https://github.com/macports/macports-base/pull/79#issuecomment-381360656 applies here as well. We cannot patch code in vendor/.

Or rather, we can't just patch code in vendor/. We need to keep our changes distinct from the standard upstream distribution.

Okay, I would be fine with that approach of just saving a copy of patches in vendor/tcl-patches that possibly need to be re-applied on each update if not fixed upstream yet.

Applying local patches to upstream sources is one thing.  In the case of modifying unix/configure.in though, it requires the additional step of running autoreconf, which is less than ideal.
Another approach (which could be submitted upstream) is to have unix/configure accept a MacPorts environment variable.  But that is probably further from ideal.
Perhaps simply documenting the problem is the least painful solution?  I.e., note somewhere that after git pull requires make clean before configure.
Rainer's suggestion of using git worktree is a nice alternative.

So, back to your proposed patch. As you describe it, this creates a tclConfig.h in addition to tclConfig.sh, but only for the purpose to force a rebuild after running configure. I do not understand the implications of this. There must be a reason why it is normally disabled.
I think the patch would better be reviewed by upstream. The problem of re-running configure must exist outside of MacPorts base as well. Maybe upstream agrees it would make sense to always generate this header?

tclConfig.h and tclConfig.sh are mutually exclusive.  tclConfig.h is actually the "official" way to build tcl for macOS evidently.  And whoever implemented tclConfig.sh as an optimization probably didn't appreciate the implications when tcl is distributed as a third-party package.  I suppose this might be sufficient grounds to recommend that tclConfig.sh be removed as the default.
Unfortunately, tcl's macosx/Makefile is missing some targets needed by MacPorts.  So updating tcl's macosx build to support MacPorts might be another option that could be accepted upstream. Then in MacPorts base/configure.ac change MP_CONFIG_SUBDIR as follows:
MP_CONFIG_SUBDIR([vendor/tcl/macosx], [--prefix=${macports_libexec_dir} --enable-threads])
VENDOR_TCL_SUBDIR=tcl/macosx

On Apr 14, 2018, at 8:03 PM, Rainer Müller<EMAIL_ADDRESS>wrote:

So, back to your proposed patch. As you describe it, this creates a tclConfig.h in addition to tclConfig.sh, but only for the purpose to force a rebuild after running configure. I do not understand the implications of this. There must be a reason why it is normally disabled.

The tclConfig.sh method invokes the compiler with an argument list of macros:  -DARG1=VAL1 -DARG2=VAL2 …
The tclConfig.h methods defines the macros in standard header file format (i.e., #define ARG1 VAL1)  and the compiler is invoked with -DHAVE_TCL_CONFIG_H, so that tclConfig.h gets included in tclPort.h via:
#ifdef HAVE_TCL_CONFIG_H
include "tclConfig.h"
#endif
Let’s  assume for the moment that the command-line macros invoked by tclConfig.sh are in one-to-one correspondence with the macros defined in tclConfig.h (yet to be verified).  My claim is that  if the macros change, the tclConfig.sh method, which does not update tclConfig.h, has no way of telling make(1) which object files are out of date.
With the tclConfig.h method, In theory, updating tclConfig.h should trigger a rebuild of all sources that include it directly or indirectly.  In particular, tclPkgConfig.c includes tclInt.h which includes tclPort.h, so all is well.  And just running touch vendor/tcl8.5.19/unix/tclConfig.h should force a rebuild . Except that, unfortunately, it doesn’t.
Okay, that’s a problem that should probably be fixed.  But for the purposes of MacPorts, it brings us back to Enrico’s PR #79 which may be the best solution after all.  In particular, the macro CFG_INSTALL_LIBDIR appears to be the only one provided by MacPorts/base/configure, and it's  used exclusively for building tclPkgConfig.c, so adding a single dependency, albeit a Makefile, seems reasonable.
Adding to MacPorts/base/configure  the command make -C vendor clean works too, but forces most or all of tcl to be rebuilt.  On the other hand, when configure is run, that’s generally desirable.
As time permits, I’ll look closer at tcl's autoconf configuration, but until then, I have to retract PR #80 which doesn’t work as expected.
-AM

I think the patch would better be reviewed by upstream. The problem of re-running configure must exist outside of MacPorts base as well. Maybe upstream agrees it would make sense to always generate this header?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for the detailed explanation. That would work if tclConfig.h was also listed as a dependency of every *.c in Makefiles. However, it seems like that requires a manual run of make depend to update.
I am closing #80 for now. We can always reopen it once we figured out what we want to change.


Resolve a conflict merging main into develop

Merging main into develop failed due to a merge conflict.  This (small) PR resolves that conflict.

I tested by branching off this branch, then merging main into that test branch.  No conflicts.

I noticed that the job LLNL.axom failed.  Clicking into Details showed that "Build_and_test Linux_gcc11_64bit" had lost contact with the server, and was marked "failed."  I asked @keithhealy about this; he checked on it and wrote back

I tried to rerun but the request is pending:
"This agent request is not running because you have reached the maximum number of requests that can run for parallelism type 'Microsoft-Hosted Public'. Current position in queue: 27. Current parallelism: 10. Max Parallelism for parallelism type 'Microsoft-Hosted Public': 10"

When I checked back, the job was marked as "Queued."  @keithhealy , thank you for rerunning the job.
I think the lab should pay for the next tier of Azure service, as well as pay readthedocs so we don't have ads embedded on our documentation.


vueuse/head doesn't support events when creating an element

Hi everybody.
I recently worked on new features that bring script loading strategy to the Nuxt. The problem is when I add some events to the script component (provided by nuxt as sugar syntax of useMeta), it turned into attributes and prints the event function string on the element.
<script src="./mock.js?t=49" strategy="immediate" onload="function() { console.log('loaded')"></script>

hmm I think that should be implemented as a standalone <Script /> component outside vueuse/head.

Nuxt already did this. But the point is there is a problem when using events. As Vue 3 described, events attached to the component and not present in emits list, must be attached to the root element of the component. I think the script element created via vueuse/head should support events.

I got your point 👌

This is available with the useHeadRaw function.
Let me know if you have any questions