[BUG] Harvester UI cloudconfig packages option being overwritten on VM creation

Describe the bug

When configuring a VM with cloud config, the package field is being overwritten, preventing additional packages from being provisioned.
To Reproduce
Steps to reproduce the behavior:

Create a VM that uses cloud config. I'm using the Ubuntu focal image

Under "Advanced Options", add a package to the cloud config user data (being sure to select the Ubuntu OS type):
...
packages:
  - qemu-guest-agent
  - docker.io
...

Create the VM

Expected behavior
The newly created VM's Cloud Config tab should reflect the options I gave it, but the package has been removed:

When the VM is created, the added package should be installed:
ubuntu@test:~$ dpkg -l docker.io
dpkg-query: no packages found matching docker.io

Is there some weird templating going on that overrides certain options in a way that is opaque to the user?
Also notice, in the first screenshot I emptied the ssh_authorized_keys setting, but when the VM was created that option was repopulated. I suspect this behavior is related.
Support bundle

Environment:

Harvester ISO version: v1.0.0
Underlying Infrastructure: Baremetal with Dell PowerEdge R710

Additional context
I ran into this issue while attempting to create a template with Docker pre-configured.

Note: this seems to even happen if I uncheck the guest additions installation.

Hi,  @lanfon72    I accidentally lost some code to fix the problem when I rebase the code （https://github.com/harvester/harvester/issues/1856）,  which caused the problem to reappear，
please help to revalidate the problem,  thanks a lot.

@WuJun2016 so it's the duplication of #1871 ?

yep

Verified this bug has been fixed.
https://user-images.githubusercontent.com/5169694/158143094-7fc2ca97-7a38-4ba5-b950-9a56ac02fc59.mp4
Test Information

Environment: qemu/KVM single node
Harvester Version: master-75cc3ced-head
ui-source Option: Auto

Verify Steps:

Same as https://github.com/harvester/harvester/issues/1871#issuecomment-1040402823


Fixing #12 and #13

Adding support for $count system qurey option, $count and $value path.
For $count option sdl-odata user needs to provide count value along with query result.
Hence QueryResult object.
For $count and $value, added PrimitiveRenderer.
Unit-tests included.

Looking very good, excellent contribution. Merging will become part of 2.1.x release line.


Distribute via Homebrew

https://nshipster.com/homebrew/

Done via https://github.com/Blackjacx/Assist/pull/39


No support for IDN ?

I would like to get the UTF-8 version of the URL, but I m not sure if Faup is supposed to support IDN:
 wget météo.fr
--2020-03-04 11:00:19--  http://xn--mto-bmab.fr/
Resolving météo.fr (xn--mto-bmab.fr)... <IP_ADDRESS>
Connecting to météo.fr (xn--mto-bmab.fr)|<IP_ADDRESS>|:80... connected.

From python
>>> f = Faup()
>>> f.decode('www.xn--mto-bmab.fr')
>>> f.get()
{'tld': b'fr', 'fragment': None, 'port': None, 'domain_without_tld': b'xn--mto-bmab', 'scheme': None, 'query_string': None, 'subdomain': b'www', 'url': b'www.xn--mto-bmab.fr', 'resource_path': None, 'domain': b'xn--mto-bmab.fr', 'host': b'www.xn--mto-bmab.fr'}

Shouldn t it be météo.fr ?

Well, I have not put thoughts on it, and it is true we could translate in that situation. It should at least be an option in the engine.
In the meantime we should be able to do something with the lua plugins. Let me see the best way I can do this.
Thanks! This is exactly how I can make the project better with this kind of bug report!


feat(saml): Add basic SAML IdP initiated flow

What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
What is the current behavior?
Please link any relevant issues here.
What is the new behavior?
Feel free to include screenshots if it includes visual changes.
Additional context
Add any other context or screenshots.

Ah wrong branch!


Ability to remove or hide completed items

As a...

user of this checklist

I want...

the ability to remove or hide completed items

So that...

The list gets less daunting as things are checked off.

Possible iterations

have the ability to fold or collapse sections (maybe using <details> and <summary> tags
give a button to hide/unhide all items that have been selected/completed

Don't forget to checkout AntiGatekeep Checklist for Content Creation and follow the bot on Twitter to see the hard work you put in.

this could help http://movb.de/jekyll-details-support.html

We now have a reusable liquid details tag.
{% details go here %}
  summary goes here
{% enddetails %}


AddItem can fail the id assertion under certain conditions (Apple Silicon?)

Describe the bug
A clear and concise description of what the bug is.
If the window title is of a certain length, followed by an input widget (for the sake of this example InputText) w/ a certain length of label and hint, followed by a button w/ a label of a certain length, it can fail the assertion at line 9931 of Imgui.cpp.
To Reproduce
Steps to reproduce the behavior, or example code that triggers the bug.
This was tough to narrow down a repro for. It seems the characters used as well as lengths changes the overall result.
Will fail w/
Assertion failed: (id != window->ID && "Cannot have an empty ID at the root of a window. If you need an empty label, use ## and read the FAQ about how the ID Stack works!"), function ItemAdd, file imgui.cpp, line 9183.
imgui
            .window("aaaaaaa: aaa-aaaaaaaa-0.0.0")
            .build(|| {
                let mut sc = String::new();
                imgui.input_text("aaaaaa aaaaaaaa##aaaaaa", &mut sc)
                    .hint("Type '*' to list all resources")
                    .enter_returns_true(true)
                    .build();
                imgui.button("aaaaaa##aaaaaaaa");
});

Will work (only difference is the hint is commented out)
imgui
            .window("aaaaaaa: aaa-aaaaaaaa-0.0.0")
            .build(|| {
                let mut sc = String::new();
                imgui.input_text("aaaaaa aaaaaaaa##aaaaaa", &mut sc)
                    // .hint("Type '*' to list all resources")
                    .enter_returns_true(true)
                    .build();
                imgui.button("aaaaaa##aaaaaaaa");
});

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Please describe your environment

imgui-rs version [e.g. 0.4.0]: 0.11.0
Operating system version: Mac OS 14.2.1
Apple M1 Max
winit, wgpu, native

Other information
Add related issues, suggestions about how to fix, any other context here.
This doesn't seem to repro on Ubuntu 22.04 on x86-64 which is why I think it might be hardware related. It seems related to the scratch_txt buffer.

I believe this is due to #762 which has been fixed in cef617ba029bd5922043bc7bb3a4039cfa92357e but it is not included in 0.11.0, so until they make a new release you can try and check out manually cef617ba029bd5922043bc7bb3a4039cfa92357e or later.

@salvatorebenedetto  thanks, your explanation clears that up. Hoping to see 0.12.0 soon.

Yup, going to close as solved in v0.12.0!


NumberPrompt returns NaN if a user responses with 0 or "zero"

When a user responds with 0 to a number prompt, prompt.recognized.succeeded is set to true, but prompt.recognized.value is NaN.

This appears to be a problem in the recognizer, the raw value returned by Recognizers.recognizeNumber is:
[ { start: 0,
    end: 0,
    resolution: { value: undefined },
    text: '0',
    typeName: 'number' } ]

@JuanAr Hey Juan, any update on this?

This issue does not reproduce in the C# implementation.

I'm seeing exactly the same as Ben on the 1.0.1 version of the Node package.

Incidentally both implementations, Node and C#, behave well and consistently with very large number strings. Its just zero in node that seems broken.
And note its is both '0' and the word 'zero' that produce the undefined value in the resolution.

This issue was already addressed in Microsoft/Recognizers-Text#508 (merged). The next release of recognizers-text-number will include this fix.

Latest version of https://www.npmjs.com/package/@microsoft/recognizers-text-number and https://www.npmjs.com/package/@microsoft/recognizers-text-suite includes a fix for this issue.

work around merged and is in 4.0.5 builds.  verified fixed


Users: Edit not working && button not showing correctly

Hey guys,
after the v2 update the edit button in the users page is not showing correctly also the edit isn´t working, I cannot change users.

Every other edit button is displaying fine so far.

Confirmed and labelling as a bug.

Need to fix the css for the UsersTable to account for all languages.
Also need to fix the save for editing user password. It seems like changing the Username / Role works.

Yes I can confirm that changing the username and/or role is working fine. Also deleting a user is working fine.

Fixed in v2.1.0.


Improve async source maps.

For me, async is the really good thing about source maps but in some cases it doesn't seem to work properly in this async sample. If you put a breakpoint on the first line of Main and try to step over it, it steps over the whole function.

Thanks for the report. We will investigate.

Source map support within the browser developer tools is managed by the browser vendors, and in general, source maps are just buggy. For the most part, they do work, but there are scenarios where they don't.
Over time we will do our best to refine what we can in Bridge to improve the source map rendering in the browser developer tools.


Appstudio update rhtap-demo-component-qunx

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: rhtap-demo-component-qunx-on-pull-request-
creating pipelinerun rhtap-demo-component-qunx-on-pull-request- in namespace rhtap-demo-dev-snpi-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request


IntelliSense popup object inspector should display type signature information at the very top

From @ziomio on September 21, 2018 14:1
If I hover over the polygon object name in the last line of this source code:
let polygon = {
  y: "hello",
  z: "goodbye"
};
polygon.y += 5;

IntelliSense will display this popup:

It displays [x: string]: any; inside curly braces, but inside curly braces (in my opinion) must be only object properties. If I look quickly over that popup I can assume that object polygon has x,y,z properties, when in fact x property is absent. Therefore I propose to display that [x: string]: any; information at the most top line of that popup window.
Copied from original issue: Microsoft/vscode#59105

@ziomio [x: string]: any is actually a typescript index signature. Here it indicates that polygon is open and other properties may be added to it later later
Moving upstream because I think we can probably display this to js users more clearly, possibly by omitting the index signature in implicit cases like this. Other ideas?

@mjbvz, the problem is - I don't use TypeScript. It's a regular JS file. I know nothing about TypeScript, CoffeeScript, PanamaScript, etc. I write Vanilla JS. And currently VSCode adds additional field "x" inside my object.

Seems to have been fixed already


Update CONTRIBUTING.md

Checklist:

[ ] Tests for the changes have been added (for bug fixes / features / refactoring)

Codecov Report

Merging #139 (9d7c3a0) into main (81b29de) will not change coverage.
The diff coverage is 0.00%.

:exclamation: Current head 9d7c3a0 differs from pull request most recent head 145b14a. Consider uploading reports for the commit 145b14a to get more accurate results

@@           Coverage Diff           @@
##             main     #139   +/-   ##
=======================================
  Coverage   12.12%   12.12%
=======================================
  Files           2        2
  Lines         198      198
=======================================
  Hits           24       24
  Misses        173      173
  Partials        1        1

Impacted Files
Coverage Δ

internal/server/handler.go
13.11% <0.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 afa098a...145b14a. Read the comment docs.


No sound with HFP with USB BCM20702A1 adapter

I'm using a BCM20702A1 USB BT interface attempting to get HFP working on some Bose QC-35 headphones.  A2DP is working, but aplay with SCO just produces silence of the appropriate length.  The bluealsa log doesn't indicate any errors.  arecord never receives any data and hangs.
I've tested with another BT adapter, BCM4345C5, which is connected over a UART (with wifi on sdio) and that does work in HFP mode, both playback and recording.  Audio quality is vastly improved over a Macbook Air mid-2012 that doesn't seem to support wide band voice in HFP.
It seems like this is very similar to #258, but that was fixed with a commit to configure broadcom adapters to use the hci interface for audio instead of an I2S interface.  It does appear that the code in fix is active:
bluealsa: D: sco.c:166: Checking Broadcom internal SCO routing
bluealsa: D: sco.c:172: Current SCO interface setup: 1 2 0 1 1
bluealsa: D: sco.c:200: Created SCO dispatcher [ba-sco-dispatch]: hci0

Once SCO playback is started, I get these messages from the kernel:
Bluetooth: hci0: Device does not support ALT setting 6
Bluetooth: hci0: urb 00000000a9df4129 submission failed (90)
Bluetooth: hci0: urb 00000000a9df4129 submission failed (90)
Bluetooth: hci0: sending frame failed (-90)

The last two messages then repeat constantly.

It might be possible that this USB BT adapter just doesn't support mSBC.  Apparently ALT mode 6 is supposed to be used for mSBC over USB.
I disabled mSBC support in bluealsa, and then this time I remember to run the recompiled src/bluealsa instead of the system installed bluealsa.  With only 8kHz CVSD sound available, it worked.  Audio quality is poor of course.
It would be nice if there was a way to discover if the BT adapter can do WBS or not.  I also see a hack to get a realtek chipset to use alt1 for mSBC.  Perhaps that can work.
Doesn't really seem like a bluealsa bug, unless those -90 errors are making there way back to bluealsa and it is ignoring them.

Hacking the btusb driver to use alt1 instead of alt6 was able to produce audio!
But it sounds bad.  Too loud and with a hiss in the background.  It sounds better with the correctly functioning bt adapter.  So I suspect there is still some problem.

Bluetooth: hci0: Device does not support ALT setting 6

Yes, that requirement for USB was introduced in Linux 5.8 - see https://github.com/Arkq/bluez-alsa/issues/343
The Bluetooth spec for HFP does require Alt6 for mSBC : it is the only way to get correct SCO timing on isochronous links with USB. Previously the btusb module was completely unaware of mSBC, so USB adapters gave very poor mSBC audio quality as SCO packets were fragmented or dropped. Not all USB adapters have Alt6 implemented. I too have a BCM20702A1 adapter and can confirm that it does not have Alt6.
Unfortunately, bluealsa would need to be modified to use mSBC with kernels >= 5.8; at present it uses the wrong socket MTU
(24 bytes). It should be 63 bytes. It is not a trivial change because btusb does not provide a "capabilities" API so I don't know how bluealsa can determine whether mSBC support is available or not. Trying to deduce from the reported kernel version/revision is just not reliable.

Is it not possible to use another alt setting?  There is now a patch from Realtek that uses alt 1 for one of their devices in the kernel.
For socket MTU, there is a pending patch from chromeos that provides a ioctl to get the MTU from SCO socket.  Would that solve the problem?

In the Bluetooth Core Specification, Volume 4, section 2.1.1, Table 2.1:  USB Primary firmware interface and endpoint settings, the "Recommended" Host Controller endpoint setting for mSBC voice is Alternate 6. So hardware manufacturers that follow the recommendations will use that. Its possible that a specific Realtek adapter ignores that recommendation, but it would then require a vendor-specific "quirk" in the driver for correct communication between the driver and the firmware. I think that in general, a USB BT adapter will require the driver to use Alternate Setting 6 for correct timing of mSBC SCO packets across the HCI. Adapters that do not implement Alt6 are not (in general) capable of supporting mSBC.
The chromeos patch looks promising. The Linux btusb module currently reports either the controller buffer size or a fixed "quirk" value of 64 for the socket MTU. Neither is usefui to an application. An application needs to know the USB mtu (48 for CVSD, 60 for mSBC) and it would appear on a quick reading of the patch you link above that it will (finally!) implement that.
I'm not sure that the application will yet be correctly informed when mSBC is not available, but at least when it is available then the correct MTU of 60 will be reported. In addition, the correct MTU of 48 for CVSD should also be reported and that would simplify the coding for bluealsa (and pulseaudio).
So possibly proper Linux support for USB mSBC is coming soon (hurrah), But at present (IMHO) the best advice for bluealsa is to use only CVSD on USB adapters. UART adapters should work quite well with mSBC (but bluealsa still lacks packet-loss-concealment, so requires an error-free bluetooth baseband link for glitch-free audio).

it would then require a vendor-specific "quirk" in the driver for correct communication between the driver and the firmware.

What would be the quirk flag BTUSB_USE_ALT1_FOR_WBS that is set for Realtek adapters.
But my real question was why settings other than alt 6 can't work.  Isn't it possible to use multiple smaller packets to achieve the necessary data rate?

It would be nice if there was a way with the ALSA device specification to select NBS and CVSD even if WBS is supported, in cases where it doesn't work.  Yes one can recompile with mSBC disabled, but a runtime select per device would be nice.  Especially for people who just install a distro package.

There is runtime selection, but without any convenient tool. You can use D-Bus call directly. Do as follows:
gdbus call --system -d org.bluealsa \
  -o /org/bluealsa/hci0/dev_1C_48_F9_9D_81_5C/hfpag/source \
  -m org.bluealsa.PCM1.SelectCodec CVSD '{}'

Correct object path you can find by issuing this:
gdbus call --system -d org.bluealsa -o /org/bluealsa -m org.bluealsa.Manager1.GetPCMs

The list of available codecs query with:
gdbus call --system -d org.bluealsa \
  -o /org/bluealsa/hci0/dev_1C_48_F9_9D_81_5C/hfpag/source \
  -m org.bluealsa.PCM1.GetCodecs

But my real question was why settings other than alt 6 can't work. Isn't it possible to use multiple smaller packets to achieve the necessary data rate?

well, they can work, as evidenced by Realtek, but it requires cooperation from the firmware which is invariably a proprietary binary blob.
USB isochronous links are "clocked" at 1 millisecond. How much data can be packed into a single transfer depends on the allocated bandwidth for the endpoint, which in turn is determined by the "Alternate" setting. The examples in the Bluetooth Core spec section referenced in previous comment explain the consequences for SCO quite well. If you read the spec and do the math, you find that Alt-1 gives 24 bytes per HCI packet, Alt-6 gives 60 bytes.
Now it just happens that an mSBC frame is 60 bytes, so Alt-6 is the most efficient choice and is recommended by the Bluetooth SIG.
Now imagine you choose Alt-1. You have to fragment 60 bytes into chunks of 24 bytes. If  the controller has a large enough buffer, it can read 5 USB frames (120 bytes of payload) and assemble them into 2 mSBC frames. If the buffer is not large enough (a typical value for USB adapters that do not have Alt-6 is just 64 bytes) then it will fail. Maybe Realtek use large buffers, or maybe they implement a circular buffer. I don't know. But I do know from experience that using a socket MTU of 24 for mSBC with USB adapters and Alternate 1 does give extremely poor results; and using a larger MTU can cause the driver and/or firmware to lock up completely.

So the issue is that the firmware, only implementing up to alt 5 with 49 byte packets, probably does not have a buffer large enough to assemble a full 60 byte mSBC frame nor the logic to assemble multiple iso slots into a single frame even if it did have the space.
The datasheet for the CYW20702 does have a section on WBS, but only over the PCM interface.

■ On-chip SmartAudio® technology: The CYW20702 can perform Subband-Codec (SBC) encoding and decoding of linear 16 bits at 16 kHz (256 kbps rate) transferred over the PCM bus.

I wonder if it would be possible to use non-transparent SCO mode to send PCM, as in CVSD, but get the chip to encode to mSBC?  Or maybe that only works over the PCM interface.  It would probably require some secret vendor specific command to enable.

It might be vendor specific, but BlueALSA already uses vendor specific HCI command to "fix" configuration for Boradcom chips. The same setup might work for Cypress, after Cypress acquired Broadcom (patch is not in the master branch, though). So, switching to PCM interface is not a problem. But then, where should I write PCM data? Where is this PCM interface exposed in Linux?

The PCM interface is a separate hardware interface (different pins on the chip package) and not part of the USB interface. So for external  plug-in USB adapters it is not accessible. With on-board designs it may be wired to some GPIO pins, in which case you would need an ALSA driver to present the chip to the kernel as a sound card. However, most PC designs, I think, do not connect these pins at all, so you would need a soldering iron to get access!

so you would need a soldering iron to get access!

Yeah, basically that was my point :)

In theory one could connect an I2S DAC or ADC directly to the PCM interface on the BT chip and transfer the audio directly without the CPU being needed.  Maybe a BT headset does this, but I've never seen it done in a device I've worked on, which have all run Linux (or VxWorks).   It takes more pins.  You need a spare I2S interface on the SoC.  Bitbanging I2S over a GPIO wouldn't be feasible in Linux, since the data and frame clock needs to be synced to the MCLK which is probably about 2-8 MHz and good luck bitbanging a 4 MHz clock in Linux.
Well, long ago one could do that in kernel space.  But the GPIO layer has gotten a lot slower since then.
But my though was not using the PCM interface, but rather the BRCM20702A's ability to do the mSBC encoding itself.  Maybe it's possible to send uncompressed 16 kHz audio over a USB non-transparent SCO pipe and have it compressed in the chip.

If you read the spec and do the math, you find that Alt-1 gives 24 bytes per HCI packet, Alt-6 gives 60 bytes.

I've now read lots of specs, but I'm not finding this math.  Alt-1 for 24 bytes appears to be derived from 9 bytes/packet * 3 packets/frame - 3 bytes HCI header.  I don't see where the 3 packet/frame comes from.  The BRCM20702A is a FS device.  Every spec I've seen seems to be clear that FS devices can request iso packets up to 1023 bytes and at most 1 packet per frame.  If it was a HS device, then it's allowed iso packets up to 1024 bytes and up to 3 packets per microframe.
Is that 24 byte MTU only applicable to HS "High Bandwidth" endpoints that allow 3 packets per microframe?  And thus does not apply to the BRCM20702A.
If that's the case, then it seems like that ChromeOS patch isn't right, as it assumes 3 packets.  It also seems like assuming the alt modes have the "recommended" sizes isn't really correct either and it should be checking the wMaxPacketSize field of the endpoint descriptor to get the real packet size and number limit.

I got it working on the BRCM20702A adapter.
btusb must be modified to place the adapter into an alt mode 1 or 2 for transparent SCO.  blue-alsa must use a socket MTU of (packetsize * 3 - 3) bytes.  In alt1 this results in 27 byte URBs that fit in exactly 3 alt-1 iso packets of 9 bytes.  In alt2 it results in 51 bytes in 3 packets of 17 bytes. Then it works.
Audio sounds the same as mSBC with a UART based BT adapter.  16 KHz mono over WBS is considerable louder than the same audio, also 16 kHz, over A2DP(SBC), but perhaps that is an issue with the QC35's DSP or volume setting effect in A2DP vs HSP.
I tried other alt mode and mtu combinations, but everything else results in silence.  I tried 15 bytes so it would take exactly  2 alt mode 1 packets and 33 bytes so it would take exactly 4, but like the holy hand grenade of antioch, four packets shalt thou not send, neither send thou two, excepting that thou then proceed to send three.  I didn't try 42 bytes, as five packets is clearly right out.
Alt mode 2 works, again with the MTU set for exactly 3 packets.
In alt mode 3, a three packet MTU would be 72 bytes.  This results in "bluealsa: E: SCO write error: Invalid argument" errors.  I tried a 47 byte mtu, for 2 packets, but that just produces silence.

@xyzzy42 I think that's an impressive piece of work. If there's any way you could persuade the btusb developers to take note and implement this upstream that would be a fantastic contribution.

I got another USB BT adapter, this one with a Realtek RTL8167B chip.  One would think, since Realtek are the ones who provided the patch to try alt mode 1, that it would work, but no.  This adapter is missing alt mode 6 too.  In alt mode 1 it appears bluealsa must be configured to use a 24 byte MTU.  Any other MTU results in no audio.  There is sound, but it's very broken.  Constantly stuttering.  I can get alt 2 to produce sound with a 48 byte MTU, like with the brcm adapter, but the audio is even more broken up than with alt 1.
There seems to be a bug with the adapter's driver that causes a kernel panic if the module is unloaded and reloaded.  So I haven't tested it as much because it's such a pain.
I think I'll make a patch to make the fallback to alt 1 not realtek specific.  It seems clear that the current code has no chance of working for adapters without alt 6.  So far, all non-realtek adapters that do not support alt 6 do work with alt 1.  Out of a sample size of one adapter.  But it makes more sense to to me to have the logic be try alt 6, then try alt 1, and if an adapter is discovered that doesn't work that way, but does work another way, then make a quirk for that adapter.

try alt 6, then try alt 1, and if an adapter is discovered that doesn't work that way, but does work another way, then make a quirk for that adapter.

I second that idea. It's just a shame that the original patch that introduced Alt-6 usage for Linux 5.8 didn't do it that way. If btusb would also report a SCO socket MTU that was useful to an application (i.e. the value(s) you have calculated) then I would be very happy :smiley:

Ordered two more BT USB adapters Friday, free Amazon delivery arrived Saturday, pretty impressive.  Almost impossible to find out what chipset an adapter uses though.  I want to find the elusive alt mode 6.
Realtek RTL8821C.  Also no alt 6 support.  Does work at alt 1 with 24 byte MTU.  Unlike RTL8167B, sound is not all broken up.
And a CSR8510 adapter too.  Same as above.
So out of two Realtek, one Broadcom, and one CSR adapter: zero support alt mode 6.  All produce audio with 24 byte MTU at alt 1.  One Realtek has bad sound, seems to be no way to fix it (short of adapter's fw).
I also see from btmon that SCO data RX occurs when using the alsa sink.  I guess HFP can only do bidirectional sound?  But what is interesting is that the packet size for RX appears to independent of the TX packet size.  I wonder where this is set?  Is it up the to bt adapter how it chooses to send the eSCO link's data over USB?  If that's the case, then maybe it choosing 24 bytes for Rx is a good indication of what size should be used for TX too.

I also see from btmon that SCO data RX occurs when using the alsa sink.
I guess HFP can only do bidirectional sound?

It all depends on the remote device logic. HFP/HSP is bidirectional, but
headset or phone is not required to send any data. You can use two
bluealsa-enabled devices to communicate to each other, and you might use
only one direction at a time (if you like). But for the real case scenario,
headset almost always sends microphone data, so if SCO link is
established, you will get RX even though you are using ALSA in a playback
mode.

But what is interesting is that the packet size for RX appears to
independent of the TX packet size. I wonder where this is set? Is it up the
to bt adapter how it chooses to send the eSCO link's data over USB? If
that's the case, then maybe it choosing 24 bytes for Rx is a good
indication of what size should be used for TX too.

Once I thought about such solution, but the problem is that RX is not
guaranteed to be there. So, such a solution would be a heuristic at best.

The patch https://lore.kernel.org/patchwork/patch/1265703/ is shown as "accepted" which I guess, means it will soon appear in the mainline kernel tree? So then it becomes a matter of applying BTUSB_USE_ALT1_FOR_WBS to the driver info for a particular device in order to get btusb to use Alt 1 for mSBC on that device instead of trying (and failing) with Alt 6. Hopefully It won't be too long before this flag is added to all appropriate devices. Then at least we should be back in the same state as before Alt 6 support was first introduced !
The patch https://lore.kernel.org/patchwork/patch/1303071/ is shown as "superseded". I don't know what that means, but I guess we will have to wait a little longer for that to be accepted. When it is, then SCO_OPTIONS (or the newer BT_SNDMTU/BT_RCVMTU) should reveal the correct MTU for the application to use.
So It seems that we are still in a waiting game for btusb to implement the functionality needed by SCO audio, but at least development is heading in the right direction now and hopefully 2021 will see the desired result.

The ALT1_FOR_WBS patch went into the kernel in v5.9-rc1, as commit 461f95f04f19, so it is already in 5.9 kernel.  I think the quirk is unneeded.  The patch is from Realtek, so by default they only want it to apply to Realtek hardware.  They would not even ask, "Is this something that applies to all USB BT adapters?"
Superseded means a new series has replaced it.  In this case, it is v3 of that series at (https://marc.info/?l=linux-bluetooth&m=159971791610689&w=2).  For some reason I can't find that series on patchwork.

I think the quirk is unneeded

			if (btusb_find_altsetting(data, 6)) {
				data->usb_alt6_packet_flow = true;
 				new_alts = 6;
			} else if (test_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags)) {
				new_alts = 1;
			} else {
 				bt_dev_err(hdev, "Device does not support ALT setting 6");
			}

My reading of the above is that without the quirk, btusb will report an error if the adapter does not support Alt6; with the quirk it will use Alt1 instead. So, I think, every adapter that is to use Alt1 for mSBC requires the quirk to be added in the driver info table.
In the revised second patch you have linked above, in addition to fixing the SCO MTU, the following hunk removes the need for the quirk to be included in the device_info table:
+		if (btusb_find_altsetting(data, 1)) {
 			set_bit(BTUSB_USE_ALT1_FOR_WBS, &data->flags);
-		else
+			hdev->sco_mtu = hci_packet_size_usb_alt[1];
+		} else
 			bt_dev_err(hdev, "Device does not support ALT setting 1");

So when/if that patch is accepted into mainline, bluealsa (and pulseaudio) will have what they need for mSBC on a USB bus.
The only outstanding issue is, how does an application know if that patch is applied to the running kernel?

The only outstanding issue is, how does an application know if that patch is applied to the running kernel?

I think that it will not necessary to detect it. We might assume that for mSBC via USB, this patch is a prior requirement (hence kernel => x.x.x). If user knows, that the driver reports invalid MTU (kernel version is below this number and patch is not backported), there might be a command line flag to use fixed bluez-alsa built-in MTU.

I wanted to check to see if I'm experiencing the same issue. The profiles I am able to use are a2dp, hfp(mic) but hfp(speaker) doesn't play the audio.
When I try to play the sound clip using the command aplay -v -D bluealsa:DEV=...,PROFILE=sco sound.wav.
This is the output from bluealsa debug
bluealsa: D: ../../src/dbus.c:59: Called: org.bluealsa.Manager1.GetPCMs() on /org/bluealsa
bluealsa: D: ../../src/dbus.c:59: Called: org.bluealsa.PCM1.Open() on /org/bluealsa/hci1/dev_.../hfpag/sink
bluealsa: D: ../../src/ba-transport.c:976: New SCO link: ...: 20
bluealsa: D: ../../src/hci.c:132: SCO link socket MTU: 20: 64
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
bluealsa: D: ../../src/ba-transport.c:801: PCM resumed: 16
bluealsa: D: ../../src/ba-transport.c:829: PCM drained: 16
bluealsa: D: ../../src/ba-transport.c:835: PCM dropped: 16
bluealsa: D: ../../src/ba-transport.c:835: PCM dropped: 16
bluealsa: D: ../../src/ba-transport.c:1018: Closing PCM: 16
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder
bluealsa: D: ../../src/sco.c:328: Releasing SCO due to PCM inactivity
bluealsa: D: ../../src/ba-transport.c:994: Closing SCO: 20
bluealsa: D: ../../src/msbc.c:72: Initializing mSBC encoder/decoder

I also get this error code in the kernel.
[116266.433721] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116266.433723] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282347] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282350] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282351] Bluetooth: hci1: SCO packet for unknown connection handle 42
[116349.282352] Bluetooth: hci1: SCO packet for unknown connection handle 42

Please let me know if you need any information to debug further.

What kernel version?  Is the bluetooth adapter USB based?
Run lsusb -v, find your bluetooth adapter, and then look at the Interface Descriptors that appear under it, they have lines like these (only some lines shown):
    Interface Descriptor:
      bInterfaceNumber        1
      bAlternateSetting       1
      bInterfaceProtocol      1 Bluetooth
      Endpoint Descriptor:
          Transfer Type            Isochronous
        wMaxPacketSize     0x0009  1x 9 bytes

What's the highest AlternateSetting and MaxPacketSize it goes up to?

Thanks for the help!
I am running kernel version 5.4.0-56-generic and yes it is USB based I tried the onboard but it didn't support the mic codec I believe.
Here's the output for the AlternateSettings/MaxPacketSize.
Device Descriptor:
  Configuration Descriptor:
    Interface Descriptor:
      bAlternateSetting       0
      Endpoint Descriptor:
        wMaxPacketSize     0x0010  1x 16 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0040  1x 64 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0040  1x 64 bytes
    Interface Descriptor:
      bAlternateSetting       0
      Endpoint Descriptor:
        wMaxPacketSize     0x0000  1x 0 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0000  1x 0 bytes
    Interface Descriptor:
      bAlternateSetting       1
      Endpoint Descriptor:
        wMaxPacketSize     0x0009  1x 9 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0009  1x 9 bytes
    Interface Descriptor:
      bAlternateSetting       2
      Endpoint Descriptor:
        wMaxPacketSize     0x0011  1x 17 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0011  1x 17 bytes
    Interface Descriptor:
      bAlternateSetting       3
      Endpoint Descriptor:
        wMaxPacketSize     0x0019  1x 25 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0019  1x 25 bytes
    Interface Descriptor:
      bAlternateSetting       4
      Endpoint Descriptor:
        wMaxPacketSize     0x0021  1x 33 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0021  1x 33 bytes
    Interface Descriptor:
      bAlternateSetting       5
      Endpoint Descriptor:
        wMaxPacketSize     0x0031  1x 49 bytes
      Endpoint Descriptor:
        wMaxPacketSize     0x0031  1x 49 bytes

It does seem like it is the same problem -- I just removed --enable-msbc and now when I record I'm able to hear using sco the playback is choppy but it works.

It's something different, as that kernel should not be trying to use alt mode 6.  Though it is probably related to how the eSCO channel is used.  Could be MTU related.  What chip does the adapter use?

It is using CSR8510.

CSR may require an 5.9 kernel, https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/bluetooth/btusb.c?h=linux-5.9.y&id=cde1a8a992875a7479c4321b2a4a190c2e92ec2a

This onse seesm important for many USB BTs:
<EMAIL_ADDRESS>

The latter is my patch to fix this, which doesn't seem to be taken up yet.
However, I think @jemershaw has a different problem.

Kernel 5.4 should use alt 1, which works.  It is kernel 5.8+ that is broken.
The kernel 5.8+ bug should spam URB submission failures.  It will use alt 0, which has a 0 byte max size, so every packet will be too big to send.
CSR8510 should work.  My "Sabrent" branded CSR8510 does.
The apparent proper MTU is 24, and that is what current blue-alsa uses.

So it's something else.  It could be related to the patch for kernel 5.9 for fake CSR8510 chips.  Tracing both the bluetooth with btmon and usb with wireshark might help.

@xyzzy42 , I saw you discussing adding proper MTU support for ALT 1 vs. ALT 6 too.
Do you have anything you can post ?
Seems to be the last missing piece for USB BT mSBC on odd adapters.

I've yet to find a BT adapter that supports ALT 6.  So what bluez-alsa does now by assuming 24 byte MTU should work most of the time.
Someone else had created a patch, referenced in this thread earlier, to add the support needed for getting both alt1 and alt6 MTU detectable by bluez-alsa.  But my understanding was that it had a flaw, where the alt mode choice was made, and the author has yet to rework it to fix that.  So I don't think that has been re-submitted for 5.11 at this point.  But unless you happen to have one of the alt 6 USB BT adapters, this isn't necessary.

But an app should not need know this and be able to trust MTU given by the kernel.
Not all BT adapters are USB too

It doesn't seem to matter for UART based BT adapters, as they don't have to packetize the data over the UART link.  I don't know about SDIO adapters, never seen one used.
Certainly the MTU should be reported correctly.  But it appears the current behavior of bluez-alsa will almost always work once the bug in kernel 5.8+ is fixed.

There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?

I've never seen documentation that explains the slightest bit about how one might get hardware mSBC on USB.  The chip makers keep their firmware docs secret.  Even when I worked on devices that had a Wifi/BT chip, we never got any documentation.

Seems like you ALT 1 patch has been accepted now, I don't see any stable keywords there so not
sure it will make it to 5.10.x ?

No, it's not queued for 5.8 - 5.10 stable.  Do you know of any bugs, besides this one I reported, about this?  I could forward to stable but it would be better if there was already a Fedora/Debian/Ubuntu/Arch etc. bug report that this fixes.

I don't know of any other report. Best to forward to stable so all get this fix.

As this patches fixes a regression, it should be marked as such and backported to stable trees.

As this patches fixes a regression, it should be marked as such and backported to stable trees.

@xyzzy42 The patch will be in 5.12 and has been backported to Linux 5.10.18 and 5.11.1
<EMAIL_ADDRESS><EMAIL_ADDRESS>
Trent Piepho (1):
Bluetooth: btusb: Always fallback to alt 1 for WBS

Just a FYI:

I'm running Ubuntu 20.04 on a Toshiba laptop, Intel bluetooth
Running hwe kernel -> 5.8.0 kernel
Bought recently headphones with HFP/A2DP sinks
HFP did not work
Arrived here following the "Device does not support ALT setting 6" message
After reading some comments, and having installed default Ubuntu kernel, I tried 5.4.0-72 package ... output very noise, mic not working, unstable behavior.
After reading final comment, installed mainline kernel, 5.10.32 -> it works like a charm

Thanks!

bluetooth-next seems to have merged a patch that swithes it to ALT 3<EMAIL_ADDRESS>This seems to break things... In principle one could now do
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a9855a2dd561..c73d372a9159 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1763,9 +1763,11 @@ static void btusb_work(struct work_struct *work)
                        /* Because mSBC frames do not need to be aligned to the
                         * SCO packet boundary. If support the Alt 3, use the
                         * Alt 3 for HCI payload >= 60 Bytes let air packet
-                        * data satisfy 60 bytes.
+                        * data satisfy 60 bytes. USB Alt 3 support also needs
+                        * HFP transparent MTU >= 72 Bytes.
                         */
-                       if (new_alts == 1 && btusb_find_altsetting(data, 3))
+                       if (new_alts == 1 && btusb_find_altsetting(data, 3) &&
+                           hdev->sco_mtu >= 72)
                                new_alts = 3;
                }

to at least make sure the MTU is not smaller than the packet size, but I suspect ALT3 should be behind a quirk, as it seems at least Intel 8087:07dc which has large enough mtu produces garbled audio output (but hard to be sure since the device has problems with pairing w/ current kernels/firmware)...

Patch<EMAIL_ADDRESS>

I've got access to a wideband BT+USB HCI sniffer for a bit and revisited this.  The RTL8167B is the one adapter I have that didn't work.
It is being set to alt mode 3, 25 byte max packet size.  Bluealsa is using: D: hci.c:141: USB adjusted SCO MTU: 28: 24.
Each audio packet is sent on 2 USB frames.  The first frame contains:
Connection Handle 02 00

Length 18
Data (22 bytes)
The 2nd frame is:
Data (2 bytes)

Probably not ideal here to be splitting the 24 bytes across two frames.  The data is valid mSBC, which can be extracted from the USB HCI capture and sounds fine.  As does the incoming audio also present in the USB capture.  I didn't tell bluealsa to record, but the audio comes in anyway.
The bluetooth side is not correct.  In the central/master to peripheral/slave slot, there is just a POLL packet.  No data.  In the following slot (peripheral -> center), there is a 2-EV3 packet with 60 bytes of data payload (65 bytes total size with header + CRC).  These packets contain a valid incoming mSBC audio stream.
So for whatever reason the BT adapter has decided it's just not going to send the audio out on the air at all.  Maybe it doesn't like how it's split across two USB frames.  Or maybe there is some command to tell it to get audio from USB rather than an I2S PCM interface.

D: hci.c:141: USB adjusted SCO MTU: 28: 24

Bluealsa currently uses a fixed packet size of 24 bytes for all mSBC over USB - perhaps that is causing the issue with your Alt-3 device. I suspect it needs to set the packet size to 60 bytes. I've recently raised a PR that tries to address this, see PR #550. I am unable to test this with Alt-3, so if you are able to try it and report the result that would be fantastic!

The USB interface alternate setting selection for SCO is made by the kernel btusb module, and there is no API that allows userspace to influence this.
If the driver is selelecting the "wrong" Alternate Setting (ie selecting Alt-3, when this device needs Alt-1) then that is an issue for the kernel btusb developers; I think there is nothing BlueALSA can do about it.
However, if the RTL8167B is capable of handling SCO streams with Alt-3, then btusb is correct, and BlueALSA needs to modify its write() chunk size in order to achieve the required data rate. It is this case that PR #550 is trying to address.
Since you have confirmed that the Windows driver selects Alt-1, it seems most likely that the problem here lies with btusb.
Here's the kernel code snippet from drivers/bluetooth/btusb.c that sets the Alt-3 flag for your device:
	if (IS_ENABLED(CONFIG_BT_HCIBTUSB_RTL) &&
	    (id->driver_info & BTUSB_REALTEK)) {
		hdev->setup = btrtl_setup_realtek;
		hdev->shutdown = btrtl_shutdown_realtek;
		hdev->cmd_timeout = btusb_rtl_cmd_timeout;

		/* Realtek devices need to set remote wakeup on auto-suspend */
		set_bit(BTUSB_WAKEUP_AUTOSUSPEND, &data->flags);
		set_bit(BTUSB_USE_ALT3_FOR_WBS, &data->flags);
	}

... and here's the snippet that selects Alt-3 based on that flag:
	if (btusb_find_altsetting(data, 3) &&
		hdev->sco_mtu >= 72 &&
		test_bit(BTUSB_USE_ALT3_FOR_WBS, &data->flags))
	 	new_alts = 3;

So the kernel selects Alt-3 if, and only if, all the following 3 conditions are true:

the kernel is compiled with CONFIG_BT_HCIBTUSB_RTL
the adapter identifies itself as a Realtek bluetooth USB device
the adapter SCO buffer size is greater than or equal to 72

I tried alt 1 way back here https://github.com/Arkq/bluez-alsa/issues/400#issuecomment-738651403 and it produced broken audio.  It's strange the Realtek are the ones who changed the driver to use alt3 instead of alt1, and yet their windows driver uses alt1.

OK, so if Alt-1 does not work with the Realtek Linux driver, then I think comparisons with the Windows driver are not valid. Perhaps Realtek supply different firmwares for Windows and Linux?
It seems we need to use Alt-3, and therefore BlueALSA needs to be modified. If you could obtain the payload size of the incoming SCO HCI packets (either by montoring the HCI data or by adding a debug statement to BluelALSA src/sco.c reporting the size read by the decoder thread), then that is the size the BlueALSA needs to write. PR #550 tries to do this, but needs testing with a greater range of adapters to verify that the logic is correct in all cases. My understanding is that Alt-3 is capable of holding 72 bytes, but SCO only uses 60 bytes, thereby wasting some USB bandwidth. However, I have found no documentation that verifies this, nor do I have access to any device that uses Alt-3 to test it.

... on the subject of firmware, I can't see a file in /lib/firmware/rtl_bt/ that matches rtl8167b. In fact, I can't see any reference to "8167" in the btrtl driver code. Please can you confirm which firmware (if any) is loaded by the Linux driver?

FWIW, ALT3 mSBC works fine on RTL 8671B/BU (0bda:8771), and appears to work better on ALT3 than ALT1. It would be the job of the kernel driver to set the BTUSB_USE_ALT3_FOR_WBS quirk properly for each device.

I got the FW from a driver at mpow_MPBH456AB_driver+for+Linux.tgz, which looks like it is no longer available.  There is RTL8761B firmware in linux-firmware now, there wasn't before, but it's different than the version I have. The version I tested identified as 0x0999646b, while linux-firmware has 0x09a98a6b, apparently newer.
I get a lot of hci0: command 0x0405 tx timeout errors with the new firmware I didn't get before.  Using Alt3 + MTU 24 is no better.  Plus a bonus kernel crash when removing the device!

hci0: command 0x0405 tx timeout

command 0x0405 is HCI_OP_CREATE_CONN and is sent to establish an ACL connection - this I think is a different issue to SCO MTU errors and USB isochronous endpoint settings.
@xyzzy42 I believe that with Alt-3, bluealsa needs to write SCO in chunks of 60 bytes, or possibly 72 bytes (it should be the same as the read() size of incoming SCO). If you could test that it be very informative.

ALT3 mSBC works fine on RTL 8671B/BU (0bda:8771)

@pv is that with bluealsa writing chunks of 24 bytes? If so that is surprising to me - what is the read() size for incoming SCO?

It's pipewire. Write/read size is 72, anything else produces no output.
On April 1, 2022 7:15:13 PM UTC, borine @.***> wrote:

hci0: command 0x0405 tx timeout

command 0x0405 is HCI_OP_CREATE_CONN and is sent to establish an ACL connection - this I think is a different issue to SCO MTU errors and USB isochronous endpoint settings.

@.*** I believe that with Alt-3, bluealsa needs to write SCO in chunks of 60 bytes, or possibly 72 bytes (it should be the same as the read() size of incoming SCO). If you could test that it be very informative.

ALT3 mSBC works fine on RTL 8671B/BU (0bda:8771)

@.*** is that with bluealsa writing chunks of 24 bytes? If so that is surprising to me - what is the read() size for incoming SCO?

Not having much luck with the newer? firmware.  Constant timeouts, crashes, etc.  It's hung the USB port it was on, nothing is detected on that port anymore, even random other devices.  Probably recoverable by unbinding and binding the affected xhci device from the driver.
Tried MTU of 60, with old firmware, no luck:
kernel: Bluetooth: hci0: urb<PHONE_NUMBER>0954a3 submission failed (90)
kernel: Bluetooth: hci0: sending frame failed (-90)
kernel: Bluetooth: hci0: urb<PHONE_NUMBER>0954a3 submission failed (90)
kernel: Bluetooth: hci0: sending frame failed (-90)

With a MTU of 72, it works.  There is always a glitch when the stream starts, which is combined with a -90 error (EMSGSIZE).
I haven't traced this yet.  It's not clear to me how a MTU of 72 is supposed to work.  The eSCO BT stream should be one 60 bytes of payload 2-EV3 packet every 7.5 ms.  The 24 bytes per 3 ms of Alt 1 matches this rate exactly, with 5 USB HCI packets per 15 ms split into exactly 2 BT 2-EV3 packets per 15 ms.  72 bytes per 3 ms is obviously too fast.  Does it just leave the 3 or 4 iso spots unused in usb frames after the first three?

@pv Many thanks for that info. So now we know 72 bytes is correct for Alt-3. PR #550 will therefore work correctly with Alt-3.
@xyzzy42 Please can you try PR #550 - that will use 72 bytes; I would like to know if the EMSGSIZE error still occurs then.
I hope that next week I'll have time to read through the btusb code again to understand how it converts 72 byte socket messages to USB Alt-3 packets with correct timing.

Here is a dump of the USB and BT traffic combined for the first 75ms.  Trying to export the data from the Ellisys capture program in a parseable format has been a nightmare.
Only the user payload data is shown in USB HCI packets as the header was removed.  But in the BT packets it's not removed, so the first three bytes are header and the last two are CRC, the rest match the HCI payloads.
Timestamp of an HCI packet is of the start of the last of the three individual USB ISO packets it was transmitted on, one per millisecond.  BT timestamp is the start of the packet.  A 2-EV3 is just one slot, unlike a 2-DH3 which is three slots.    The USB cadence appears to be {7, 8, 7, 8, 15} milliseconds between packets of 72 bytes.   The average rate of the five packets is 360 bytes in 45 ms.  The BT cadence is {7.5, 7.5, 7.5, 7.5, 7.5, 7.5} with 60 byte packets.  So also 360 bytes in 45 ms.
It's not clear why this should be better than Alt 1, since it's still splitting HCI packets.  It just wastes iso slots by not using every usb frame to transmit data.
I think the glitch might be because the initial three USB packets have sent 27 ms of audio, yet only 22 ms have elapsed.  There might not be enough audio ready in time to send the fourth packet when it's supposed to go out.


Pass route params to custom REST API

Continuing the #113
Please, let me know, how to pass the route URI params to custom REST API?
Ex. folder/:folderId/messages
I can see it in <List {...props} />, but how to pass to httpClient?
httpClient receives string recourse folder/:folderId/messages, not a real folder/23/messages

This is the job of the restClient, please see the REST clients documentation.

This issue is about my own CUSTOM REST API.
I'm trying action type GET_LIST on route folder/:folderId/messages. This is the list, not single record.
The only params for GET_LIST are pagination sort range filter.
How to CATCH :folderId parameter?
I've tried to apply dummy middleware and log incoming params
sagaMiddleware.run(crudSaga((p1,p2,p3,p4) => { console.log('REST CLI ',p1,p2,p3,p4) }));
but got got only
p1=GET_LIST
p2=controller/:controllerId/agent
p3=params { pagination, sort, range, filter }
Where does :folderId resides in?

I don't know what you're trying to achieve, what is the :folderId supposed to contain? Can you tell me more about your REST API ?

App flow

View folders list folder route + API call.
 <CrudRoute path="folder" ... /> - OK, works fine.

Select folder from folder/:folderId/messages route + API call to display list of messages in the selected :folderId folder.
 <CrudRoute path="folder/:folderId/messages" ... /> - not working.
Sends to my custom REST API resource = folder/:folderId/messages, not the parameter with exact :folderId numeric value.

... other logic

This is not supported. See the <ReferenceManyField> for a way to display a list of messages in the folder edition view.

Could this issue become a "feature request" or "enhancement request"?
It just so easy to push via props the current routeParams.

What you should do is define a messages resource, and tweak your REST client to transform calls to GET /messages?filter={'folderId':123} to GET /folder/123/messages.


[next] allow OrbitControls to be standalone

I was thinking why isn't something like this possible?
<script>
  import { OrbitControls } from '@threlte/extras'
  import { useThrelte } from '@threlte/core'

  const { camera } = useThrelte()
</script>

<OrbitControls camera={camera.current}>

or automatically grab the camera from useThrelte(). (See below)
Right now OrbitControls is coded such that the parent must be a Camera instance but it should not be too difficult to allow an optional camera prop. pseudocode for this feature might look like the following
<!-- OrbitControls.svelte -->
<script lang="ts">
  import type { PerspectiveCamera, OrthographicCamera } from 'three'

  type Props = {
    camera: PerspectiveCamera | OrthographicCamera
  }
  let { camera } = $props()

  const parent = useParent()

  // this won't work since parent is a store but you get the idea
  const _camera = $derived(camera ?? parent)

  // attach orbit controls to _camera

</script>

since camera would be reactive, this means that the controls would need to update to follow the updated camera. i think this should be possible with the following.
<script>

  // same

  $effect(() => {
    controls.object = _camera
  })
</script>

i also wonder if we can default to the scene's default camera. More often than not i find myself creating a camera that is essentially the same as the default camera in order to use <OrbitControls>.
<T.PerspectiveCamera makeDefault position.z={5}>
  <OrbitControls />
</T.PerspectiveCamera>

The camera above is the same as the default camera from useCamera(). Why not just default to the current camera?
<script>
  // same

  import { useCamera } from '@threlte/core'
  import { fromStore } from 'svelte'

  const defaultCamera = fromStore(useCamera())

  const _camera = $derived(camera ?? defaultCamera.current)

  // attach controls to _camera
</script>

this way you can add <OrbitControls> to any scene without having to create a camera.
<OrbitControls />

hmm so after trying it out we have to do something like this if we want to see changes that OrbitControls makes:
<T.PerspectiveCamera makeDefault/>
<OrbitControls />

passing camera as a prop is still possible but you'd be updating a camera that the renderer is not using. so the above works or you can do the following
<script>
  const { camera } = useCamera()
  camera.current.position.set(5, 5, 5)
</script>

<OrbitControls />

either way will work but there's two important things to note:

<OrbitControls> can now be placed anywhere in the component since it no longer needs to be a child of a camera.
in the second code snippet we can avoid creating an extra camera just to use <OrbitControls>

so i'm not sure if we should allow a camera prop. there might be a use case for moving around a camera that isn't the camera used for rendering but I can't think of any. Maybe the user is using a custom render task that uses the nondefault camera for rendering. it's a stretch but there might be something the folloing that someone would want to do:
<script>
  const { autoRender, renderer, scene } = useThrelte()
  autoRender.set(false)

  const myCamera = new PerspectiveCamera()

  useTask(() => {
    renderer.render(scene, myCamera)
  }, { autoInvalidate: false })
</script>
<OrbitControls camera={myCamera} />


[Feature] Avoid conflicting functions with common trait impls on UDT types

Component
sol-types, sol! macro, syn-solidity
Describe the feature you would like
On UDT types, currently there is a impl that converts to and from the underlying.
                /// Convert from the underlying value type.
                #[inline]
                pub const fn from(value: #underlying_rust) -> Self {
                    Self(value)
                }

                /// Return the underlying value.
                #[inline]
                pub const fn into(self) -> #underlying_rust {
                    self.0
                }

However these functions conflict with regular into and from trait impl's. Currently this will just render them useless (the impl on the struct will always override the trait impls). I recommend changing the naming to, from_underlying and into_underlying
Additional context
No response

actually a even better solution would just be implimenting the from and into traits for this type


enable Webgl2 optimisation in pbr under feature

Objective

3d examples fail to run in webgl2 because of unsupported texture formats or texture too large

Solution

switch to supported formats if a feature is enabled. I choose a feature instead of a build target to not conflict with a potential webgpu support

Very inspired by https://github.com/superdump/bevy/commit/6813b2edc5eb5833b11bb7b4f01a3c662d1953e2, and need #3290 to work.
I named the feature webgl2, but it's only needed if one want to use PBR in webgl2. Examples using only 2D already work.

Personally I'd prefer if this was chosen by default for wasm targets, since webgpu is still in beta and IMO it's more important for the common case to "just work". We could revisit this later when webgpu support is rolled out to stable browsers.

There is already a mostly working webgpu support: https://discord.com/channels/691052431525675048/750833140746158140/915727141130338385

WGPU's webgpu backend being mostly complete is irrelevant IMO since webgpu isn't available on any stable browsers. Right now, people will still be only using webgl2 for any releases since that's the only backend that's actually supported by browsers.
A potential option here could be to check whether wgpu itself is running on webgpu or webgl2 dynamically though.

A potential option here could be to check whether wgpu itself is running on webgpu or webgl2 dynamically though.

Now it is not possible AFAIR - wgpu uses webgl feature to select between webgpu and webgl2.
So I would prefer to rename this feature from webgl2 to webgl to be compatible with wgpu. And maybe let's simply add it to bevy's default features?

And maybe let's simply add it to bevy's default features to make it default on wasm32?

I can either add it as a default feature, which means that everyone will have by default only one point light, and the no array textures, or add it as a feature already selected for wasm target, wich means it won't be possible to disable it on wasm. As far as I know there are no way to specify default feature set by target, https://github.com/rust-lang/cargo/issues/1197#issuecomment-268203727 would be needed for that.

actually bevy_render2 was already enabling wgpu/webgl based on target, so I did the same for this feature, and moved control for bevy_render2 and bevy_pbr2 to a single point in bevy_internal

on macOS this works on chrome and firefox but it crashes safari... wgpu examples are working with safari, so maybe an issue on Bevy side
Firefox is logging this warning:
WebGL warning: getBufferSubData: Reading from a buffer with usage other than *_READ causes pipeline stalls. Copy through a STREAM_READ buffer.

and it seems that safari is crashing when calling getBufferSubData
Could we have a buffer somewhere that should be marked as read and isn't?

with the wgpu update, 3D examples fails with a new error on Safari:
panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_render_pipeline
      note: label = `pbr_opaque_mesh_pipeline`
    Internal error in VERTEX | FRAGMENT | VERTEX_FRAGMENT shader: Name conflicts between uniform block field names: _group_0_binding_0

Not sure how to fix that 😞

group 0 binding 0 is the View uniform. The mesh pipeline uses the same shader handle for both vertex and fragment stages. The pbr pipeline specialises the mesh pipeline and uses a different shader for the fragment stage. I wonder if the vertex stage shader (mesh.wgsl) containing a fragment entrypoint with the same name (fragment) as the overridden fragment stage shader (pbr.wgsl) that's confusing it somehow...?

Yup, and somebody did not read the // NOTE:
https://github.com/bevyengine/bevy/blob/340957994dc2c85f7a3ebc5ea6a5ad1b161e0041/crates/bevy_pbr/src/render/depth.wgsl#L3-L8
https://github.com/bevyengine/bevy/blob/340957994dc2c85f7a3ebc5ea6a5ad1b161e0041/crates/bevy_pbr/src/render/mesh_view_bind_group.wgsl#L1-L10
but copy pasting to have the same in both didn't fix the issue...

depth is used for the shadow pass. But I also noted that and I wondered how shadows are even working. Hmm...

crashes with Safari are due to https://github.com/gfx-rs/naga/issues/1617

This all looks reasonable to me. I can confirm that this works with the naga fixes:

Firefox perf is quite bad. But chrome seems smooth (didn't do any actual frametime measurements).

bors r+


broken build due to gtest

Build seems broken with submodule rapidjson submodule gtest.  Probably need to update to a newer commit of rapidjson.

It should be working now


xmlto: fix - updated nonet patch / added test

xmlto disables by default the downloads required for xml validation by passing the --nonet switch to xml and xslt processors. The nonet patch disables this default behaviour as it regularly fails xml validations and hinders xml conversions. I noticed that apart from the line patched in the old nonet patch there are two lines with explicit and hardcoded reference to --nonet switch. This cancelled the effect of the previous patch and failed the xml validations once again. The new patch modifies those two lines as well as doing what the old patch did.
I also added a xml conversion test in order to make sure that the xmlto installations can be tested properly. I keep the source files for man pages of xmlto and then use them for xml conversion testing purposes.

Has the new patch been submitted upstream?

I don't think this patch originates at upstream at all. This issue has been
there since four or five years ago and has been persistently kept the way
it is. It seems Fedora's policy is to keep it the way it is, for security
reasons. But I just haven't been able to find out who I have to refer to in
order to submit the patch. I don't understand very well how Fedora project
works. The issue is that this formula does not work in its current form and
the current patch is useless given that "nonet" is hardcoded further down
in the code. What I can do is to try to find out how I can submit a patch
to turn the hardcoded "nonet" into a conditional one. I will try to find
out more about Fedora and the way this specific package is managed.
Mahmood Shafeie Zargar
Sent with Airmail

In that case we can consider just removing the patch?

I am not sure I understand why the patch should be suppressed…
Here is the situation in detail:
xmlto almost invariably fails when it is asked to transform something, as it first goes online to get the DTDs required to check the validity of the XML files. The default “nonet” means this process will certainly fail. That is why this patch was made first place, and if you look around the net you will see the patch appears everywhere in Q&As.
Now, the old patch worked until recently, when someone added a hardcoded “nonet” switch somewhere in a call to an xslt processor, which disregards the the overall setting for nonet (that the old patch patched). Since this modification, xmlto has started daily once again when it gets to any transformation that does not disable xml validation explicitly. My new patch modifies the overall setting (a global variable in the makefile), but also goes and patches the violating hardcoded “nonet”.
If we remove the patch all the software using xmlto to transform their documentation at compile time will have to be compiled with a switch that disables XML validation. This will require many patches to many other formulas, given that many makefiles do not provide an option for disabling XML validation. This won’t probably affect compilations from source package in most cases, because many source packages already contain the compiled version of their documentation. But it will affect many of the —HEAD installations, given that the source code repositories often do not include the compiled version of the docs.
So, my suggestion is to keep the new patch until the hardcoded “nonet" is removed upstream, at which time we can revert back to the old patch. But in any case we will need a patch if we want to prevent other installers from failing.
The issue with Fedora is that they are building this software for a very different market (mostly servers I guess), and they don’t seem to want the application to go online without explicit permission. This is not the case for Homebrew, which is mostly geared towards desktop, workstation and home use...
On February 11, 2016 at 2:28:05 PM, Mike McQuaid<EMAIL_ADDRESS>wrote:
In that case we can consider just removing the patch?
—
Reply to this email directly or view it on GitHub.

On the other hand, if the main objective is to keep in sync with upstream regardless of these consequences, yes we may have to remove the patch and let all other installations fail. It is not clear to me what the other distros (apart from Fedora) do with this issue, but there seems to be plenty of code on the internet that assumes xmlto will work without disabling validations.

I'd rather we keep in sync with upstream rather than carry a patch indefinitely that's not going upstream.

Fine, if you confirm I remove the patch and adapt the tests so that they run without the patch.

@retrography Sounds good :+1:

I hit this today. Quite lame to have the user dig around in xmlto to fix this. Perhaps upstream can support a whitelist or some other relatively secure option for fetching DTDs?

Fine, if you confirm I remove the patch and adapt the tests so that they run without the patch.

@retrography Any news on that?
@Empact You'd have to ask upstream.

Closing this out since it doesn't look like upstream is accepting it.
If upstream will take the patch, feel free to re-submit on the new homebrew/core repo.


ci: Bump timeout on ci-runtime privileged worksflow

Bump timeout from 20 to 30 minutes due to repeated workflow cancellations due to timeout on otherwise successful workflow runs.

/test

ci-runtime privileged test passed in 19m 6s :-)


Generic helper for consistent post-reconcile spec and status updates

Summary
Unify post-reconcile spec and status updating logic in a type safe way. The APIBinding and APIExport controllers are updated as examples.

/test all

/retest

Sgtm.
Only bike-shedding: postreconcile => commit.

/lgtm
/approve


pr.get_sequence may not be working?

I'm following example commands from the documentation to get sequences from a fasta file (assembled genome) according to the intervals in a PyRanges object. Specifically I'm using the syntax:
seq = pr.get_sequence(gr, "temp.fasta")
Manual inspection, the first time around, of the first few intervals from the first chromosome indicated it was getting the correct sequences. However, if I look at any additional chromosome, it's clearly getting the incorrect sequence. I've manually inspected the FASTA file at a few interval coordinates and have also used bedtools getfasta command, which reports a different sequence than the PyRanges get_sequence function, and the bedtools sequence appears correct from manual inspection.
Other than a fasta file, are there any other specifications to use this function? Or is there perhaps something wrong with the function itself?

Hi,
get_sequence uses pyfaidx under the hood. What happens is that the fasta file is indexed if an index (.fai) is not found, then the index is used to fetch the requested sequence. One way in which things could go wrong is if you changed temp.fasta between uses of get_sequence, so that the .fai index is out of date. Try deleting the index and run again get_sequence
If this doesn't solve the issue, please provide data and example code to replicate it

I deleted the index file and reran my notebook, and it appears a new index file was created in the same directory as the reference genome (NMEL.fasta). The first three sequences/entries for the first chromosome (NMEL_chr_1) seem to be the same as reported by bedtools, run by doing the following:
REF=Nmel.fasta
BED=kmers_test.txt # exported from PyRanges object
bedtools getfasta -fi ${REF} -bed ${BED} -fo ./bedtools_tmp.fa
However, when I start looking at other chromosomes, bedtools getfasta disagrees with PyRanges in terms of the sequence corresponding to that genomic interval, and manually inspecting the reference genome with VIM text editor suggests bedtools is right. The incorrect sequences PyRanges is grabbing appear to come from the provided reference genome, but are from other locations and on difference chromosomes.
Are there other ways to provide data to reproduce this? The most compressed version of the reference genome is 80MB but file sizes here are capped at 25MB. In your hands, with different data, do the sequences you pull out with PyRanges agree with bedtools fasta when you use a BED file and FASTA file that both contain multiple chromosomes?
Brian

In our hands, pyranges extracting sequences from annotations is correct. Our lab uses this function very often. Let's get to the bottom of this.
Please paste a link to the reference genome (hopefully you're working with public data?) and a few lines from the BED file, sufficient to reproduce the error. Also show the pyranges code you use to load the bed file and get sequences.

@brian-arnold can you provide data to replicate the error? Otherwise we'll have to close the issue
thanks!


More detail for Geomorphic Feature classification

Is your feature request related to a problem? Please describe.
The current options for categorizing geomorphic trace features are not very descriptive
Describe the solution you'd like
Here are some proposed dropdown menu items:
Trace Type
-Geomorphic Trace
Associated Geomorphic Feature
-Terrace
-Terrace riser
-Moraine
-Dune
-Bedrock ridge
-Debris flow
-Landslide
Geomorphic Trace Type
-Crest
-Base
-Ridge
-gulley
-striation
-shoreline
-stream
-toe
-scarp
Landscape Type
-Glacial
-Fluvial
-Marine
-Lacustrine
-Arid
Feature Origin
-erosional
-depositional

I update the koboforms for trace features and added "other" to the categories.

Added with commit 846ab50ca46ccc8e4dfd960758a50b3b27683901


paper

Hello, where can I download your paper?

Hello! Paper can be download at https://arxiv.org/abs/2305.00673.

Hello, where can I download your paper?

Hi! Paper can be download at https://arxiv.org/abs/2305.00673.


migrate debian:buster -> debian:Bullseye (released 14 August 2021)

https://www.debian.org/News/2021/20210814

@alek-w we currently provide an Ubuntu base docker image, not a Debian one so I'm not sure this is relevant to the project

@gdams Could ypu tell pls
who is responsible for debain containers there ?
this guys  says that they are not


add graceful shutdown

add GRACEFUL_SHUTDOWN to stop containers
add GRACEFUL_SHUTDOWN test

Interesting! Would love to know a bit more about what prompted this change @calvin-pietersen!

@lox Yes, we have a scenario where one of our dependant containers needs to output an artefact. Which can only be done by gracefully shutting down the container :(

@toolmantim can we merge?

Sorry for the delay @jathu! That's been merged, and a release will be out soon.


[Featture-Request] Ability to swap HashMap

hi, I think it would be great if there is a way to swap hashmap with lets say rustc_hash::FxHashMap for better performance, but I dont know how difficult it would be to impl for currnet code structure, but rustc_hash::FxHashMap should be a drop and replace for std::collections::HashMap.  would this be considered a feature going forward?
thanks

and wonderful #666 ;)

This seems like an interesting idea similar to how prost supports bytes. That said, I am not sure if it is a good idea to add this if the change is quite intrusive like the bytes one. I want to avoid the precedent of adding a bunch of stuff. That said, you can always derive stuff manually using prost and can likely use your own hashmap.

got it :)

can likely use your own hashmap.

can you please explain this :)  how would I go about using my own hashmap. thanks

I have had similar performance concerns and got this answer on SO: https://stackoverflow.com/a/76414640/3008606
Main points stated in that thread:

optimization depends on the individual HashMap field -- some may be empty, some are known in advance to have single entries, others have multiple entries. Some have hardcoded contents, others are determined dynamically.
optimization for sending data is likely different than for retrieving data.
creating a RandomState is relatively cheap, though for a large number of throwaway HashMaps may still be relevant
the same is true for computing a single hash code
memory allocation is presumably orders of magnitude worse. A different allocator might be used. Using an allocation-free HashMap alternative is not possible without introducing the same type problems as for the hashing algorithm.

Optimizing each field individually would require to introduce per-field type parameters for either the hasher or the whole HashMap, and these parameters would cascade through enclosing structs. This is not useful. Optimizing all fields with the same time could at best aim at a common-denominator solution.
The "Java way" would be to add a common Map trait for the hash maps, and use Box for all fields. This introduces other overheads for the dynamic dispatch, and possibly further memory allocation.
However, the last point also raises the question, what methods would be in that trait. What exactly is needed from maps during Protobuf de-/serialization? My point here is that hashing often isn't needed. The feature that comes closest and might be considered a requirement is duplicate key detection. For anything else, a list-of-key-value-pairs would be enough in the generated types, and true hash maps can be created by the calling code when needed. In many cases, the calling code will translate from its own types to/from the protobuf types anyway, since the protobuf types are targeted at compatibility with external programs, not what is needed inside the calling code.
A list-of-key-value-pairs would still not be able to optimize each field individually, but a common-denominator solution would be much cheaper than for HashMaps. Examples would be allocation-free for empty key/value sets, allocate for non-empty. Or even allocation-free for empty or single-entry KV sets.


import super_gradients  yolo_nas = super_gradients.training.models.get("yolo_nas_l", pretrained_weights="coco").cuda() yolo_nas.predict("https://deci-pretrained-models.s3.amazonaws.com/sample_images/beatles-abbeyroad.jpg").show()

Would be great if you can elaborate (see our issue templates).
Otherwise we sould have to close this issue down, as it is not clear enough.

@VladimirLky any update ? If not we will close this issue due to lack of information


Relax batch table scan & batch index scan compatibility check

Feature Request
Currently we will fallback all requests that contains Enum / Set column in the table/index scan to non-batch executors. However, as long as we don't need to decode these columns, it is fine to use batch table/index scan executor.

Just set the types to pass the should batch test. Is there any thing else to do?

@jswh Looks like no.


Removing someone else's .editorconfig and ignoring it.

Someone else included their editor config file by accident. Removing it and ignoring it.
Let's also try not to get into the spaces vs tabs argument again. I respect both options. 👍

Doesn't this project use 2-space indents in its source files? I don't mind whether the project uses spaces or tabs, but ideally it only uses one or the other, and it makes sense for it to have an .editorconfig file present so people's editors that support it can auto-configure to match whatever style the project's maintainers want. (.editorconfig files don't carry user-specific data in them like many IDE project files do; they're built to be committed.)

I don't think this file should be removed as my editor uses it to ensure consistency in this project. If anything I think it should be expanded to ensure a final newline and to enforce proper newlines. root should also be added to ensure that some other user level configuration doesn't influence the configuration.
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true

I agree with last two comments, that file helps to develop this library with consistent format.
I think we can close the PR.
Thanks anyway @dabockster for thinking about improving the repo maintenance :)


Add failSuite() helper to abort the entire test suite

Fixes #36. Previously, it was possible to abort an individual test case based on a dynamic condition but it was not possible to abort the entire test suite. Now, users can call failSuite("abort test suite!") to prevent subsequent test cases from starting.

PS. I took the liberty to update the PR description with more details. For future PRs, it's good to follow the "previously, ... Now, ... new behavior" structure to help readers understand what changed and why.

@olafurpg omg, thanks for editing this PR. Next time will do it by myself. 👍


Layout does not refresh it self in Play Mode

Need to move mouse over the specific area in a layout. That is so annoying thing. Because in the middle of development and debugging need to find a component with the SafeAreaLayout component and move mouse over. Is it possible to force it to work automatically OnAwake or OnStart events (at least as an option)?
https://user-images.githubusercontent.com/9135028/205421207-8f03335d-40cc-4b37-9bdf-eddb35025d80.mp4
P.S. the package is very cool! Thanks for the work <3

UPDATE: possibly OnEnable event would be better to listen for making the "refresh" of SafeArea

Hi @IvanMurzak, thanks for the report.
I've never had this problem, so weird =S
Does the problem occur only in the Unity Editor or the Safe Area gets ignored in builds as well?
In my experience, whenever object gets reactivated and OnEnable called, the Unity GUI will rebuild the layouts and the Safe Area gets applied. Maybe it's not doing so in your setup only...
Could you try adding a call to LayoutRebuilder.MarkLayoutForRebuild(SelfRectTransform) in the end of OnEnable and tell me if it fixes the behavior?
protected virtual void OnEnable()
{
    _canvas = GetComponentInParent<Canvas>();
    RefreshChildrenAnchors();
    LayoutRebuilder.MarkLayoutForRebuild(SelfRectTransform);  // <-- this line
}

Say, do you reparent the object after creating it outside of the Canvas?
I've just noticed that the script is not refreshing its Canvas and rebuilding the layout if it gets reparented.
Maybe you could try adding a OnTransformParentChanged method to the SafeAreaLayoutGroup script, if this is the case:
void OnTransformParentChanged()
{
    _canvas = GetComponentInParent<Canvas>();
    // RefreshChildrenAnchors();  // no need to refresh children here
    LayoutRebuilder.MarkLayoutForRebuild(SelfRectTransform);
}

Even if it does not work for you, I'll add it to the script later to handle these reparenting cases.

It doesn't refresh in builds also. That all what I can say for now. Will test your suggestions. Do you want me to add the code into your class (SafeArea...)?

My UI never change parents. It just disabled/enabled.

@gilzoide  I reproduced the error with manual actions. Just need to disable gameObject, scale it to zero, enable it and scale back to 1.
https://user-images.githubusercontent.com/9135028/205446291-00196d47-2aa2-4374-aac7-47334f5052d7.mp4

Thanks for the insights!
Maybe the problem is with the usage of nested Canvases.
Try something for me, please: instead of using the parent Canvas directly, get the root Canvas in OnEnable:
protected virtual void OnEnable()
{
    _canvas = GetComponentInParent<Canvas>().rootCanvas;
    RefreshChildrenAnchors();             // ^ here, get the rootCanvas
}

Do you want me to add the code into your class (SafeArea...)?

Yes. If you installed the plugin via UPM, you can find the script at the folder Library/PackageCache/com.gilzoide.safe-area-layout@<some number here>/Runtime/SafeAreaLayoutGroup.cs. You can edit it there directly and Unity will use the updated code.

Just need to disable gameObject, scale it to zero, enable it and scale back to 1.

Hmm, it is possible that scaling won't trigger layout rebuilds. I'll test and fix this case later.
Thank you again for the additional information on this issue!

Hey @IvanMurzak.
So, I was testing here with your "manual actions" and wasn't able to reproduce the issue.
I used a Screen Space - Camera Canvas with a subcanvas, then tested scaling and nothing went wrong.
This video shows some of my tests, but I tried quite some more than that. I also tested on both Unity 2021.3.13 and 2019.4.40, no luck reproducing.
https://user-images.githubusercontent.com/4603360/207723984-50705da5-495e-443d-b068-f70a7d80ba32.mp4
Your case is certainly very strange =/
I'm using only uGUI Text and Images in my sample scene, you seem to use "UIView" and "UICanvas" scripts. Are they part of some third-party asset?

So, something else I just realized is that hovering the Editor button calls LayoutRebuilder.ForceRebuildLayoutImmediate while the runtime uses LayoutRebuilder.MarkLayoutForRebuild. I have to say, I see no reason why marking layout for rebuild instead of forcing the rebuild would not work, appart from weird editor-only cases, but maybe it's the key to your problem.

Hey @IvanMurzak , I've made some changes to the package that might fix your problem.
Please try out the version at tag 1.0.2 and tell me if it works. You can use the url https://github.com/gilzoide/unity-safe-area-layout.git#1.0.2 at your manifest.json file if you use UPM.
Now every internal call to RefreshChildrenAnchors marks the layout for rebuild, which I hope will work for you.


Regex fix

Changes:
During pre-release testing, it was found that badly-formatted job names were not throwing errors as expected. This was due to re.match not containing ^ and $ to specify the full length of the job name.

Move job name sanitising function into Prometheus class, and add ^$ to regex
Produce .err files
Call the sanitising function in main

Test set up:
sudo docker build -t komodo_cron_metrics:regex_fix .
sudo docker image ls | grep "komodo_cron_metrics"
komodo_cron_metrics                          regex_fix       a2be5e07c228   6 minutes ago    1.03GB
Test the error state:
"test-10" should be detected as invalid, because of the hyphen
Only a .err file should be produced
This WON'T be picked up by Prometheus - monitored jobs will not show up in Grafana, prompting investigation
corbin@starling:~/wc/test_komodo_cron$ sudo docker run --rm -v /home/corbin/wc/test_komodo_cron:/prom_metrics a2be5e07c228 "test-10"
corbin@starling:~/wc/test_komodo_cron$ ls -l
total 4
-rw-r--r-- 1 root root 142 May 31 12:09 '2024-05-31 11:09:42.532808.err'
corbin@starling:~/wc/test_komodo_cron$ head 2024-05-31\ 11:09:42.532808.err
The Prometheus job name test-10 does not match the Prometheus data model requirements - it needs to match the regex ^[a-zA-Z_:][a-zA-Z0-9_:]*$
Test passed: The .err file was produced, and no .prom file was made
Test the correct format state:
"test10" should pass as a valid string
Only a .prom file is produced
The .prom file should contain a metric in the format: jobname_completed epochtime
corbin@starling:~/wc/test_komodo_cron$ sudo docker run --rm -v /home/corbin/wc/test_komodo_cron:/prom_metrics a2be5e07c228 "test10"
corbin@starling:~/wc/test_komodo_cron$ ls -l
total 8
-rw-r--r-- 1 root root 142 May 31 12:09 '2024-05-31 11:09:42.532808.err'
-rw-r--r-- 1 root root  28 May 31 12:11  test10.prom
corbin@starling:~/wc/test_komodo_cron$ head test10.prom
test10_completed<PHONE_NUMBER>
Test passed: The .prom metric was created successfully. There's no .err file

This change is

Hello @corbin-chris! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file bin/prometheus.py:

Line 36:80: E501 line too long (80 > 79 characters)


Rustfmt check on travis

Coverage remained the same at 71.145% when pulling 6cba98bf6c196f75cd5ef825be67dd674098b6c0 on rustfmt into 934f55520bdf66c93a13aeeaf0ad53eaf23cf42f on develop.

Coverage decreased (-0.07%) to 71.071% when pulling 7165aabe4941138b61f8562edb359e6fad1e2ffe on rustfmt into 934f55520bdf66c93a13aeeaf0ad53eaf23cf42f on develop.

Coverage decreased (-0.07%) to 71.078% when pulling e3880240e181ecbd263c5583b597c7eade34ef4f on rustfmt into 934f55520bdf66c93a13aeeaf0ad53eaf23cf42f on develop.


[FLINK1443] Add support for replicating input formats.

InputFormats can be wrapped by a ReplicatingInputFormat which takes care that the full input of the wrapped input format is read in each parallel instance of a data source.
This can be used to run distributed joins without data shuffling.

Very nice, +1 to merge

Merged as a19b4a02bfa5237e0dcd2b264da36229546f23c0


docs: add a demo video to the readme

Closes #729

:tada: This PR is included in version 2.18.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


nixos-unstable hasn't updated for 2 weeks

The nixos-unstable channel has not updated for 2 weeks and according to https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents there are still plenty of test failures in current versions of master to prevent updates in the very near future.

The current failures seem strongly correlated with:

being "installer" tests (/rebooting internally)
timed out waiting for the VM to connect (300 sec timeout)
packet-epyc-1

They occur on release-18.09 as well, subjectively it looks like the same frequency of failures.
I also notice that error is occurring much, much more frequently after the new VM backdoor was added. I am not sure whether there is any correlation though, but maybe someone could proofread those changes.
I am unable to reproduce the failure locally unless I reduce the timeout to 5 seconds (from 300!)
The dmesg spam appears to suggest that the VMs tend to spend nowhere near as long (usually 30 seconds, still a factor of 10 off) starting up.
I personally don't feel that it's really a load/timeout issue, but the only idea I have for testing it out is to actually increase the timeout in nixos/lib/test-driver/Machine.pm to something obscene.

packet-epyc-1
I its frequency is likely to be because it just gets the jobs much more often

I also notice that error is occurring much, much more frequently after the new VM backdoor was added.
@domenkozar @dezgeg Can you maybe help me convince myself this is just me being superstitious? :-) It's a little difficult to go through the older failures and see if this is really true, and I don't quite understand the actual changes in the test instrumentation.

I am not sure it this related to the delayed channel update but it seems hydra had a huge backlog of build jobs. It seem like it is still building a nixpkgs:trunk version from 4 days ago (https://hydra.nixos.org/jobset/nixpkgs/trunk/evals?page=2).

The main blocker ATM seems chromium.  It's even possible that those builds exhaust some resources and consequently fail some nixos tests.  I assume just running a few chromium builds at once on a machine is quite a stress-test.

Ah, I understand now. It's the actual chromium build cycling, not the test.

Yes, I meant chromium builds, not chromium tests.

This is probably caused by https://github.com/NixOS/nix/issues/2493.

The debugging backdoor just adds a new virtualized serial port. It shouldn't affect the existing ports in any way. Of course if there is some race condition it could affect timings.
One thing that seems suspicious is that the dmesg timestamp sometimes jumps backwards, e.g in https://hydra.nixos.org/build/83162004 has:
machine# [    6.886877] mousedev: PS/2 mouse device common for all mice
machine# [   18.125198] powernow_k8: Power state transitions not supported
machine# [    8.761331] systemd[1]: Found device Virtio network device.
machine# [    8.769515] systemd[1]: Found device /dev/ttyS0.
machine# [   18.151414] EDAC MC: Ver: 3.0.0
machine# [   18.164716] MCE: In-kernel MCE decoding enabled.
machine# [   18.283728] [drm] Found bochs VGA, ID 0xb0c0.
machine# [   18.284843] [drm] Framebuffer size 16384 kB @ 0xfd000000, mmio @ 0xfebd0000.
machine# [    8.916688] systemd[1]: Found device /dev/hvc0.
machine# [    8.922226] systemd[1]: Found device /dev/hvc1.
machine# [   18.304981] [TTM] Zone  kernel: Available graphics memory: 508402 kiB
machine# [   18.306432] [TTM] Initializing pool allocator
machine# [   18.316878] [TTM] Initializing DMA pool allocator
machine# [   23.066463] ppdev: user-space parallel port driver
machine# [   28.684386] fbcon: bochsdrmfb (fb0) is primary device
machine# [   28.755161] Console: switching to colour frame buffer device 128x48
machine# [   28.823769] bochs-drm 0000:00:02.0: fb0: bochsdrmfb frame buffer device
machine# [   28.826605] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0
machine# [   28.884951] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input4
machine# [   10.361634] systemd[1]: Started Firewall.
machine# [   10.363826] systemd[1]: Reached target Network (Pre).
machine# [   10.824250] systemd[1]: Started udev Wait for Complete Device Initialization.
machine# [   10.827169] systemd[1]: Reached target System Initialization.
machine# [   10.835099] systemd[1]: Listening on D-Bus System Message Bus Socket.
machine# [   10.854768] systemd[1]: Listening on Nix Daemon Socket.
machine# [   10.885524] systemd[1]: Reached target Sockets.
machine# [   10.908122] n67lgc40cas892bsdb0llz0gkvwa5ljm-unit-script-network-addresses-eth1-start[585]: adding address <IP_ADDRESS>/24... done
machine# [   10.919171] systemd[1]: Reached target Basic System.
machine# [   10.932285] systemd[1]: Starting Address configuration of eth1...
machine# [   10.937313] nscd[612]: 612 monitoring file `/etc/passwd` (1)
machine# [   10.944325] a1zbfqipa1sl4bnnayla17z5p48kxiza-audit-disable[587]: No rules
machine# [   10.950546] systemd[1]: Started NixOS Manual.
machine# [   34.394196] 8021q: 802.1Q VLAN Support v1.8
machine# [   34.395465] 8021q: adding VLAN 0 to HW filter on device eth1
machine# [   10.967222] nscd[612]: 612 monitoring directory `/etc` (2)
machine# [   10.979572] fmik28sp6likfml7gjcqxqaqrhk7s8qk-unit-script-network-link-eth1-start[592]: Configuring link...
machine# [   10.983993] fmik28sp6likfml7gjcqxqaqrhk7s8qk-unit-script-network-link-eth1-start[592]: bringing up interface... done
machine# [   11.508796] systemd[1]: Starting Kernel Auditing...

I don't know if that's expected behaviour but maybe we dropping this might affect things:
    boot.initrd.postDeviceCommands =
      ''
        # Using acpi_pm as a clock source causes the guest clock to
        # slow down under high host load.  This is usually a bad
        # thing, but for VM tests it should provide a bit more
        # determinism (e.g. if the VM runs at lower speed, then
        # timeouts in the VM should also be delayed).
        echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
      '';

After help from multiple people I now see just hibernation test failing reproducibly in both branches.

The error message is from systemd, and in https://hydra.nixos.org/api/scmdiff?rev2=d1de23b8302d02d4699e884533906a3992f370b6&uri=https%3A%2F%2Fgithub.com%2FNixOS%2Fnixpkgs.git&rev1=89fb76c51ced36d1bc5821e51e7327b7150f25a2&branch=&type=git there is only one relevant change: d1de23b8302d02d4699e884533906a3992f370b6

Probably caused by https://github.com/NixOS/systemd/commit/6789dca0a26df0c44ff8020f0a4206bf21e52a7a#diff-897a4693906dd8751a19d0c70f1f4207

Channel up to date :tada:

The last 8 builds on nixos:release-18.09:tested failed again with "error: timed out waiting for the VM to connect".
Mostly installer tasks and "nixos.tests.gnome3.x86_64-linux".
Latest: https://hydra.nixos.org/build/85309024#tabs-constituents
Last successful nixos-unstable update was 15 days ago.
Could it have the same reason?

There previously was a bug with curl that made the ipv6 test failed for more than a week (until 2018-11-30).
Last job is today : https://hydra.nixos.org/build/85309672
The jobs with errors are seemingly random and the error is nearly every time "error: timed out waiting for the VM to connect"

Lately I relatively often see transient nixos test errors from packet-epyc-1; I suspect it may get overloaded occasionally.
I can only guess why that happens.  One possibility: some derivations don't use make -l$NIX_BUILD_CORES or similar – I find that very annoying locally, as I have a cheap 16-threaded desktop and 16*16 is way too much (--cores + --max-jobs).

@vcunat an overload may not only be caused by improper make -j/-l flags but also by test routines. Numerical computing packages such as arpack, openblas, scalapack, etc. run multi-threaded tests, which use all cores in the system by default.
The only safe, long-term solution to the overload problem is to constrain builds with cgroups?


Add Option type

To map to HUGR option (sum of None, Some[T])
Ideally should be an interface we can in future replace with a guppy algebraic data type.
Functions:

new None
new Some(T)
unwrap()
is_none()
is_some()

Put it into it's own module
none() and some(value) for construction


https://github.com/GTA-V-Crack-Download-Free-for-PC/

https://github.com/GTA-V-Crack-Download-Free-for-PC/

Close with reason: Spam;


New step definition to open an instrument from Add / Edit Records

There is already another step definition for this.


The documentation is bad.

You're suppose to call elementDatasetPolyfill() - but that function is non exsistent in the polyfill minified download?

You need an amd load such as dojo.js or require.js. The loader defines functions for interacting with it - require and define.
Alternatively element-dataset is available as a commonjs module.

A usage example in the README would be great for this one. I was stumped for a while just importing it (as one would babel-polyfilly). But now it's working like a charm, thanks!


Execute multiple scripts after renewal

It tried to add multiple scripts to execute after renewal:
"InstallationPluginOptions": [
  {
    "Script": "C:\\Scripte\\Web\\restart_apache.bat",
    "Plugin": "3bb22c70-358d-4251-86bd-11858363d913"
  },
  {
    "Script": "C:\\Scripte\\RDP\\setRDP.cmd",
    "ScriptParameters": "{CertThumbprint}",
    "Plugin": "3bb22c70-358d-4251-86bd-11858363d913"
  }
]

But it only executes the last script two times:
 [INFO] Installation step 1/2: Script...
 [INFO] Script C:\Scripte\RDP\setRDP.cmd starting with parameters A6563D613696DC533C6FFDEE157347B8332A5581
 [INFO] Installation step 2/2: Script...
 [INFO] Script C:\Scripte\RDP\setRDP.cmd starting with parameters A6563D613696DC533C6FFDEE157347B8332A5581

Would it be possible to enable the execution of multiple scripts after renewal?

I like the creative use of the file format! The dependency injection container was preventing this from working properly, but I've just created a little patch that will fix that in the next release.

Thanks. Great work!


Issue #140: Made Header Responsive

This will close issue #140
@max-programming Please have a look at it. Thank You!

Thank you very much!
@all-contributors please add @NishidhJain for design, code

Can you fix the conflicts so I can merge?

Sure, I am working on it @max-programming

Hey @max-programming, I have resolved the conflicts and its ready to merge. Please have a look at it.
Also please have a look at this PR https://github.com/max-programming/hacktoberfest-projects/pull/136
One more request, can you please consider this contribution under hacktoberfest and add the label for the same.
Thank You!!

@NishidhJain I'll be reviewing the other PR later. And also don't worry once the PR gets merged, it will be counted in Hacktoberfest

@all-contributors please add @NishidhJain for design, code

@max-programming @NishidhJain GitHub logo is broken, i mean it is shown in black color instead of white... I suspect this PR commited that change


Permissions are not set correctly after torrent moved

Permissions on files in a folder (if the root of the torrent is a folder) do not appear to inherit permissions, may need to walk the entire folder and change permissions.

Now I walk the entire folder structure to correct bugs..


why the kernel version still 3.10?

I install  instantbox  in CentOS7 and launch a CentOS8  instance  in  isntantbox environment. But I find the kernel version was still
3.10  when I connect the  CentOS8 instance via webshell. I remember  the kernel version is 4.x in CentOS8. Is is a bug?
[root@instantbox_managed_omidwjl1xz9qg2v4 home]# cat /etc/redhat-release
CentOS Linux release 8.2.2004 (Core)

[root@instantbox_managed_omidwjl1xz9qg2v4 home]#
[root@instantbox_managed_omidwjl1xz9qg2v4 home]# uname  -r
3.10.0-957.27.2.el7.x86_64

docker uses host kernel. please try updating your host kernel and reboot.