lxc-net fails if port 53 is unavailable

Required information

Distribution: Arch Linux
Distribution version: 4.14.4-1-ARCH
The output of "lxc info" or if that fails:

Kernel version: 4.14.4-1-ARCH
LXC version: community/lxc-1:2.1.1-1
LXD version: n/a
Storage backend in use: n/a

Issue description
I'm trying to set up a veth-type network using the helper script lxc-net. I've set up a custom DNS port for dnsmasq (5353), since my powerdns instance needs port 53; powerdns being strictly a DNS server, not a DHCP server or anything else that's built into dnsmasq.
However, I have found no way to configure this port in /etc/default/lxc{,-net}. A quick glimpse in /usr/lib/lxc/lxc-net showed that dnsmasq is called with the default port and the iptables rules have port 53 hardcoded in them. This makes it impossible for me to run lxc-net.
Steps to reproduce

Change dnsmasqs port to 5353
Use port 53 with another software
Try to run lxc-net.

Information to attach
# journalctl -xeu lxc-net
-- Unit lxc-net.service has begun starting up.
Dec 09 04:18:50 pichu lxc-net[3635]: dnsmasq: failed to create listening socket for <IP_ADDRESS>: Address already in use
Dec 09 04:18:50 pichu lxc-net[3635]: Failed to setup lxc-net.
Dec 09 04:18:51 pichu lxc-net[3635]: Failed to setup lxc-net.
Dec 09 04:18:51 pichu systemd[1]: lxc-net.service: Main process exited, code=exited, status=1/FAILURE
Dec 09 04:18:51 pichu systemd[1]: lxc-net.service: Failed with result 'exit-code'.
Dec 09 04:18:51 pichu systemd[1]: Failed to start LXC network bridge setup.
-- Subject: Unit lxc-net.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit lxc-net.service has failed.
--
-- The result is RESULT.

I just realized that these issues are about lxd, not lxc. Should I take this issue to lxc/lxc?

You could but we're not going to be able to do anything about it.
All Linux distributions expect the DNS server to be on port 53 and you can't provide an alternative port through DHCP or IPv6 RA.
The main issue here is that your powerdns server is binding every single interfaces on port 53. If you were to configure it to only bind the interfaces you actually need it on, it'd all work fine.


Wording for redundancy option is incorrect

When selecting either GRS or GZRS redundancy, you can select Make read access to data available in the event of regional unavailability option which the user assumes converts it to RA-GRS or RA-GZRS.
Firstly, I believe the "unavailability" wording is incorrect. With RA-GRS and RA-GZRS you can always read your data in the secondary region even if the primary region is available, not just when it's unavailable. Therefore the wording is incorrect. See https://docs.microsoft.com/en-au/azure/storage/common/storage-redundancy#read-access-to-data-in-the-secondary-region for reference.
Secondly, it would be simply easier to add RA-GRS and RA-GZRS to the list of selectable redundancy options so that it's explicitly clear, rather than the user having to assume, what the Make read access to data available in the event of regional unavailability option does.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6ee9ec76-a91f-095a-5ba3-b9c413366751
Version Independent ID: 29c17263-ed56-d42e-bc3f-091ef2b4b9ff
Content: Create a storage account - Azure Storage
Content Source: articles/storage/common/storage-account-create.md
Service: storage
Sub-service: common
GitHub Login: @tamram
Microsoft Alias: tamram

@kamfaima Thank you for your feedback! We will review further and take the next course of action.

@kamfaima Firstly, apologies for the delay in responding here, Your feedback has been shared with the content owner for further review.

@kamfaima - Thanks for your feedback. This forum is for reporting issues with the documentation. The wording described here is the wording that's shown in the portal.
Selecting this checkbox is the action that makes data available for read access in the secondary region (by configuring the account for RA-GRS or RA-GZRS). The point of read access to the secondary region is that you can design your application to read from there if the primary region becomes unavailable. The word unavailable here refers to the primary region only.
#please-close

Hi @tamram, thanks for getting back to me. I guess we'll just have to agree to disagree! Configuring a storage account for RA-GRS or RA-GZRS makes the data in the secondary region readable irrespective of whether the primary region is available or not, not just when it's available.
I still stand by my comment that the description itself is misleading and that it's a poor UX/UI that you don't explicitly say selecting the checkbox will enable RA-GRS or RA-GZRS. All the other storage options are there so why would you not just add RA-GRS and RA-GZRS rather than making it a checkbox option? Bear in mind that there is a cost implication to selecting RA-GRS/RA-GZRS so I'm sure the customer would like to know that is explicitly selected rather than just inferring by the definition of the text.
Anyway, I wish you well and thanks for getting back to me.

@kamfaima - I appreciate your point of view. However, this forum is only for the documentation, and the documentation in this case is accurate. If you have feedback on the portal UI, you can use the Support + troubleshooting button in the portal to report it.


Set flags of resumed/existing torrents

Allow users to set flags of resumed/existing torrents, such as no_verify_files, from an array in the config.toml.

And maybe only allow it to set flags of resumed/existing torrents that were finished/seeding before. Adding a default_dont_download flag to a torrent that's still downloading would be bad.


[Target][TOPI] Use LLVM for x86 CPU feature lookup

Hi folks,
This PR leverage LLVM itself for CPU features lookup, replacing hard-coded lists.
In order to keep maintainability with X86 families & features we can rely on LLVM.

Changes:

Introduce a single target_has_feature(XXX) replacing all target_has_XXX()
PY+FFI: expose new llvm_x86_get_archlist, llvm_x86_get_features & llvm_x86_has_feature
PY:  expose new target_has_feature wrapper to _ffi.llvm_x86_has_feature

There is a test unit for a comprehensive check with the old behaviour.
For better reliability, this way of feature checking can be implemented for other arches.
Thanks,
~Cristian.
Cc: @elvin-n , @vvchernov , @echuraev , @vinx13 , @jcf94 , @masahi

The CI fails because the LLVM version on CI is pretty low (==10). I'm curious if there's any variant of this API on LLVM 10? If not, we should bump LLVM to 15 or 16

The CI fails because the LLVM version on CI is pretty low (==10). I'm curious if there's any variant of this API on LLVM 10? If not, we should bump LLVM to 15 or 16

Folks,
@junrushao ,
Yes, I am aware of this llvm<=10 issue, so llvm==11 would be the minimum (tested).
Looking at llvm<=10 to see other way (little +extra code costs) of tapping differently into their API.
I am strongly opting for a backward compatibility for this case.
The API fracture, at a first glance:

llvm>=11 expose/uses a c_struct + a nice func X86::getFeaturesForCPU to it.
llvm<=10 expose a tablegen (same info) so need to see where it ends to use that via some API.

Allow a little time (1-2 day) to investigate a way going down llvm<11, then I'll be back with the results.

I am strongly opting for a backward compatibility for this case.
Allow a little time (1-2 day) to investigate a way going down llvm<11, then I'll be back with the results.

Details of investigation:
Post llvm>=11:

Direct access via TargetParsers public headers.
Immediate, no need for target-machine, details are fetched via the public getters.

Implementation here is slim, infos coming from LLVM are precise and maintained.
Prior llvm<=10:

The usefull data from tablegen descriptor in class MCSubtargetInfo is private without useful accessor.
There is a unhelpful way of passing std::string("help") at the creation of MCSubtargetInfo().
Usefull queries can be done, only via full llvm taget-machine, this compatibility is implemented here.

There is a burden of LLVMint() and the target-machine creation, but final check/legalizer is precise w.r.t to the arch.

@junrushao , @kparzysz-quic, @echuraev
There are quite some changes now, please help re-reviewing them.
Thanks.

Hello @cbalint13! Thank you for big work and good improvement and unification of target check. For me it looks like that "avx512bw" is not the best name to split usual avx512 (e.g. for skylake) and avx512 with VNNI (e.g. for cascadelake), may be return "avx512", I do not see places where it uses in other context

@vvchernov ,
Good question regarding "avx512bw" !
Please help me with a double check on these statements below:

To my understanding needed in tvm .avx512.pmaddubs.w.512 ,.avx512.pmaddw.d.512 are in avx512bw subset.
See for reference: https://reviews.llvm.org/D11351 , so the avx512bw flag is what we seek within LLVM.

There are also other avx512 subsets, but none holding instructions for our topi/tir intrinsics, on their name here:
"avx512vl", "avx512dq", "avx512cd", "avx512er", "avx512pf", "avx512vbmi", "avx512ifma",
"avx5124vnniw", "avx5124fmaps", "avx512vpopcntdq", "avx512vbmi2", "gfni", "vpclmulqdq",
"avx512vnni", "avx512bitalg", "avx512bf16"

Some arches investigated here:

The "skylake", "cascadelake" have it:

print( _ffi_api.llvm_x86_get_features("skylake") )
["cmov", "mmx", "popcnt", "sse", "sse2", "sse3", "ssse3", "sse4.1", "sse4.2",
"avx", "avx2", "fma", "bmi", "bmi2", "aes", "pclmul", "adx", "clflushopt", "cx16",
"cx8", "crc32", "f16c", "fsgsbase", "fxsr", "invpcid", "lzcnt", "movbe", "prfchw",
"rdrnd", "rdseed", "sahf", "sgx", "x87", "xsave", "xsavec", "xsaveopt", "xsaves"]

print( _ffi_api.llvm_x86_get_features("cascadelake") )
["cmov", "mmx", "popcnt", "sse", "sse2", "sse3", "ssse3", "sse4.1", "sse4.2",
"avx", "avx2", "fma", "avx512f", "bmi", "bmi2", "aes", "pclmul",
 "avx512vl", "avx512bw", "avx512dq", "avx512cd", "avx512vnni",
 "adx", "clflushopt", "clwb", "cx16", "cx8", "crc32", "f16c", "fsgsbase",
"fxsr", "invpcid", "lzcnt", "movbe", "pku", "prfchw", "rdrnd", "rdseed",
"sahf", "x87", "xsave", "xsavec", "xsaveopt", "xsaves"]

The "knl" which have some avx512* but not the desired avx512bw:

print( _ffi_api.llvm_x86_get_features("knl") )
["cmov", "mmx", "popcnt", "sse", "sse2", "sse3", "ssse3", "sse4.1", "sse4.2",
"avx", "avx2", "fma", "avx512f", "bmi", "bmi2", "aes", "pclmul",
"avx512cd", "avx512er", "avx512pf", "adx", "cx16", "cx8", "crc32", "f16c",
 "fsgsbase", "fxsr", "invpcid", "lzcnt", "movbe", "prefetchwt1", "prfchw",
"rdrnd", "rdseed", "sahf", "x87", "xsave", "xsaveopt"]

The odd "alderlake" have avxvnni but not avx512bw either avx512vnni:

print( _ffi_api.llvm_x86_get_features("knl") )
["cmov", "mmx", "popcnt", "sse", "sse2", "sse3", "ssse3", "sse4.1", "sse4.2",
"fma", "bmi", "bmi2", "aes", "pclmul", "gfni", "vpclmulqdq", "adx", "cldemote",
"clflushopt", "clwb", "cx16", "cx8", "crc32", "f16c", "fsgsbase", "fxsr", "invpcid",
"widekl", "lzcnt", "movbe", "movdir64b", "movdiri", "pconfig", "pku", "prfchw",
"ptwrite", "rdpid", "rdrnd", "rdseed", "sahf", "serialize", "sgx", "sha", "shstk",
"vaes", "waitpkg", "x87", "xsave", "xsavec", "xsaveopt", "xsaves", "hreset",
"avxvnni"]

BTW, "alderlake" here, is the only "strangeness" having avxvnni but not avx512vnni.

The "sapphirerapids" have "avx512bw" "avx512vnni" , and "amx-int8" among with lot of new "interesting goodies".

print( _ffi_api.llvm_x86_get_features("sapphirerapids") )
["cmov", "mmx", "popcnt", "sse", "sse2", "sse3", "ssse3", "sse4.1", "sse4.2", "avx", "avx2", "fma",
"avx512f", "bmi", "bmi2", "aes", "pclmul", "avx512vl", "avx512bw", "avx512dq", "avx512cd",
"avx512vbmi", "avx512ifma", "avx512vpopcntdq", "avx512vbmi2", "gfni", "vpclmulqdq",
"avx512vnni", "avx512bitalg", "avx512bf16", "adx", "amx-bf16", "amx-int8", "amx-tile",
"cldemote", "clflushopt", "clwb", "cx16", "cx8", "crc32", "enqcmd", "f16c", "fsgsbase",
"fxsr", "invpcid", "lzcnt", "movbe", "movdir64b", "movdiri", "pconfig", "pku", "prfchw",
"ptwrite", "rdpid", "rdrnd", "rdseed", "sahf", "serialize", "sgx", "sha", "shstk", "tsxldtrk",
"uintr", "vaes", "waitpkg", "wbnoinvd", "x87", "xsave", "xsavec", "xsaveopt", "xsaves",
"avx512fp16", "avxvnni"]

I put Cc @Qianshui-Jiang (author of #13642) he might help with a second opinion in this too.

Hello @cbalint13! Very hard work! One note I should say TVM needs three avx512 intrinsics: vpmaddwd, vpmaddubsw and vpaddd. For the latter "+" is used but it is automatically replaced by intrinsics by llvm, and it is in avx512f set (I checked it here).

Hello @cbalint13! Very hard work! One note I should say TVM needs three avx512 intrinsics: vpmaddwd, vpmaddubsw and vpaddd. For the latter "+" is used but it is automatically replaced by intrinsics by llvm, and it is in avx512f set (I checked it here).

@vvchernov ,
See now, very good point !
Let's ask for booth, will change with these comments:
// avx512f:  llvm.x86.avx512.addpd.w.512 (LLVM auto, added)
// avx512bw: llvm.x86.avx512.pmaddubs.w.512" (TVM required)
             llvm.x86.avx512.pmaddw.d.512"
if ( target_has_feature("avx512bw")
   && target_has_feature("avx512f")):

Just as side note (curiosity) on this topic:
Maybe one day someone can add separate  _compute(), _update() for topi (more precise one) not letting LLVM itself.
I would be curious of outcome, in the first (i.) LLVM would ommit addpd.w.512  by adding something suboptimal.

i. "llvm -mcpu=x86-64 -mattr=+avx512bw"
ii. "llvm -mcpu=x86-64 -mattr=+avx512bw,+avx512f"
As i. versus ii. ,  "x86-64" is the plainest configuration for llvm, allowing only explicit flags.

Anyway, let's go now with avx512bw && avx512f.

"F" would stand for foundation, probably avx512bw implies that CPU also have avx512f (but not vice-versa)
One example of partial avx512 is the "knl" having the avx512f (foundation) part but not having the avx512bw part.

@vvchernov ,
One more informal expreriment:

I made this experiment below, and results disprove that avx512bw implies avx512f (aka "foundation part").
The x86-64-v4 popping up is kind of "arch-generic", so let's enforce avx512bw && avx512f presence.
For this ODD case, something like llvm -mcpu=x86-64-v4 -mattr=+avx512f passes the test below (checked).

$ cat ./tvm-check-avx512bw.py
#!/usr/bin/python3

import tvm
from tvm.target import codegen
from tvm.target.x86 import target_has_features

for mcpu in codegen.llvm_x86_get_archlist():
  with tvm.target.Target("llvm -mcpu=%s" % mcpu):
    if target_has_features("avx512bw"):
      has_avx512f = target_has_features("avx512f")
      print("ARCH [%s] having `avx512bw` has avx512f=[%i]" % (mcpu, has_avx512f))

$ ./tvm-check-avx512bw.py
ARCH [skylake-avx512] having `avx512bw` has avx512f=[1]
ARCH [skx] having `avx512bw` has avx512f=[1]
ARCH [cascadelake] having `avx512bw` has avx512f=[1]
ARCH [cooperlake] having `avx512bw` has avx512f=[1]
ARCH [cannonlake] having `avx512bw` has avx512f=[1]
ARCH [icelake-client] having `avx512bw` has avx512f=[1]
ARCH [rocketlake] having `avx512bw` has avx512f=[1]
ARCH [icelake-server] having `avx512bw` has avx512f=[1]
ARCH [tigerlake] having `avx512bw` has avx512f=[1]
ARCH [sapphirerapids] having `avx512bw` has avx512f=[1]
ARCH [graniterapids] having `avx512bw` has avx512f=[1]
ARCH [graniterapids-d] having `avx512bw` has avx512f=[1]
ARCH [emeraldrapids] having `avx512bw` has avx512f=[1]
ARCH [znver4] having `avx512bw` has avx512f=[1]
ARCH [x86-64-v4] having `avx512bw` has avx512f=[0] <--- ODD !!! (but pass with -mattr=+avx512f).

@cbalint13 @vvchernov  big thanks for your hard work and dicussion!  Here is few comments.
Actually before the CasecadeLake we use avx512 to handle the 8bit and 16bit integer, so pmaddubs used here is for SkyLake.
And start from CasecadeLake we have avx512vnni, so there is other more instrcutions like vpdpbusd and vpdpwssd, it fused some of pmadd instruction we used before,
Now when we move to SapphireRapids， we have amx-vnni, which use amx instrctions to handle the 8bit integer.
Yes ur right, avxvnni in AlderLake is due to the lack of its avx512 instruction set in 12th client CPU.
I support to expose interface for fetch all the features in particular arch, but still suggest to  let TVM detect the feature throught the arch name some thing like AlderLake or IceLake. cuz users may not clear of the instuction set equipment of their platform but clear of the name.

@Qianshui-Jiang ,
Thank you much for your time & clarifications !

To sum it up:

compliant across all versions,  llvm<=10 issue is solved ( Cc @junrushao ),  tested versions: llvm={10,14,16,17}
implementation here exposes single target_has_features(XXX) replacing the old target_has_XXX() functions
it also expose friendly llvm_x86_get_archlist() and  llvm_x86_get_features(arch) to obtain full arch related lists

There is a comprehensive test unit that also checks the old behaviour (also incorporating the old static lookup table).
This is the final state, passing the CI, until explicit review-requests.

I am very excited about this feature and cannot wait to try it out myself! Thank you @cbalint13 for this super well-documented and well-tested PR, and it's going to be super useful for downstream applications!


Room-level key-value tags

Still no UI for adding / removing / editing tags, but a cleaner, more general implementation

Lint fails because I have the hooks for a UI to manipulate the gather key, but no actual UI implemented yet (it's settable via API for now)


Display correctly (Un)Pin To Start in the context menu

Resolved / Related Issues
Pin to start menu is in a sub menu even when "move overflow items to sub menu" is off.
Should be out with the rest of them.
Fixes #4850
Details of Changes
This command uses ShowOnShift. This property is bugged.
The expected behavior of ShowOnShift is to show the command only if shift is pressed.
The real behavior of ShowOnShift is to show the command in More when Shift is not pressed.
ShowOnShift is only used for PinItemToStart and UnpinItemFromStart.
However, this command should not use it to always be visible (PinItemToStart and UnpinItemFromStart).
This PR disables ShowOnShift for these commands.
The bug with ShowOnShift is not fixed but it would no longer be used and would not have any impact.
We can decide to fix the bug or remove the unused functionality.
Validation
How did you test these changes?

[ ] Built and ran the app
[ ] Tested the changes for accessibility

@winston-de Your analysis is interesting. I propose to apply it.
However, the name ShowOnShift is confusing. I suggest ShowInMoreMenu. Show on shift is a bonus but not the main one.

@cinqmilleans I think a description (///<summary></summary>) for the variable would probably help clarify it's purpose better than changing the name.

@winston-de I do not agree. A name must not mislead and a description does not correct the problem, otherwise the reading of the code is misleading. There are only 6 occurrences to change.

@winston-de I do not agree. A name must not mislead and a description does not correct the problem, otherwise the reading of the code is misleading. There are only 6 occurrences to change.

I guess renaming it is probably fine.


Upgrades to grist-electron discontinued?

I note that the electron build has now fallen some way behind the current grist-core version.
Is the intention to no longer maintain current versions?
Is it possible to build more up to date versions? How does one do so?
I find grist-electron very useful as a personal tool, and to develop databases for later deployment to grist-cloud. The version discrepancy is a problem on a number of levels. I may have to go to a cloud or self-hosted basis...but that has some problems/limitations. Not least surrounding cases with issues of data protection and unsuitability for cloud based development.
Thank you for what we have. Not in any way complaining, but seeking clarification in order to determine future direction.

You are right that the build has been falling behind. We're planning to rectify that very soon though, watch this space!
The general method to build a more up to date version is to update the core submodule. There may be changes to core that require small changes to the grist-electron code also. We will have someone working on this soon.

Update: @SleepyLeslie is working on it in https://github.com/gristlabs/grist-electron/pull/30

Grist document upgrading is solid and carefully tested, I would not anticipate that kind of problem.

Thank you for the work on podman, by the way. I will be looking into that for possible hosting on NAS servers - docker is not something I'll use on them.

Understood. Hope we can sort out the sandboxing situation under podman.

grist-electron v0.2.9 with grist-core v1.1.14 has been released.

Thank you for the update. All seems to be working well from the user end.


[Question/Feature request] Migrate wallet and channels from c-lightning

I have an existing c-lightning / lightningd node with a bunch of open channels.
I am now realizing that my use-case reqiures functionlity that for now only exist as integrations for lnd and will require a lot of reimplementations and implementation of new plugins for c-lightning.
Therefore I'd like to migrate to lnd.
Given the work, time, and capital involved in getting my c-lightning node to where it is today, I'd really like to not start from zero again.
Has anyone attempted this, or have an idea about if it's even an effort worthwhile pursuing where things stand today?

I don't see how this would ever be possible. The internal database structure of the projects are just too different.
And even if you could migrate the data itself, the derivation paths for the private keys are probably different as well.

@guggero Thanks for following up (and feel free to close if the following is OT here)
If my goal is to keep existing iquidiyt paths etc, would it make sense to:

keep the existing c-lightning node (cl-0) with current channels with incoming liquidity, close pure outgoings
Set up new lnd node (lnd-1)
Open corresponding outgoing channels that were closed in 1
Open channel lnd-1 -> cl-0
Set up new lnd node lnd-2
Open channels cl-0 -> lnd-2, lnd-2 -> lnd-1

My thinking being that the resulting triangle-node system will have the same net result as a single node, the only drawback apart from complexity being needing to lock up funds between the three nodes
It feels like it should be possible to get a balanced channel between cl-0 <-> lnd-1, thereby only needing one new node instead of two

It sounds like you're mostly concerned about preserving the inbound capacity of your node, correct?
Setting up a triangle of nodes to allow shifting the balance around is one option, yes.
Another option would be:

Close all channels of cl-0 during a low-fee period (e.g. the weekend).
Create a new lnd node, send the on-chain funds from cl to lnd.
Open a few large-ish channels to well connected peers.
Acquire inbound liquidity by:

Using Loop to send off-chain funds and receive on-chain funds back.
Lease a few inbound channels through Pool, then do circular rebalancing.
A combination of both.

Of course this would all incur both on-chain and off-chain fees. But would it reduce the complexity of the resulting system by replacing one node with another instead of running three nodes.
Closing the issue as suggested, can still discuss migration strategies here though.


Fixed server-side arguments mapping

Only delegate and expression arguments was mapped but not other. Tests were failed or "not run".

Merged it. Thank you.


[BugFix] Fix bug when getting hive table statistics

What type of PR is this：

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

Which issues of this PR fixes ：

Fixes #
If table partition size greater than sample size and table has string type column, it will trigger this bug when manually refreshing external table.
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

@Mergify backport branch-2.3-tbds


fix buttons color and variant in delete worker dialog

Changes
In delete worker dialog

change cancel button color to anchor and variant to outlined
change remove button variant to outlined

Related Issues
#2682
Checklist

[x] Screenshots/Video attached (needed for UI changes)

Cancel same like close here so ll be at left and "remove(main action)ll be at left" with the error color


[minmax-mcn-farm] Add custom strategy for minmax finance

This is a custom strategry for minmax finance.
This strategy returns the total amount of user-owned MAX tokens as the voting power, including MAX in wallets, pending rewards and MAX LP held by the farm contract on iotex.

@ChaituVR Thanks for your remind. I forgot adding it into the commits after local testing. Is it ok now?


init: fix format of string on ValueError

The string should contain the incorrect path, not the object's string
representation.

Pull Request Test Coverage Report for Build 22

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
5 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.5%) to 82.272%

Files with Coverage Reduction
New Missed Lines
%

fdt/init.py
5
75.82%

Totals

Change from base Build 21:
-0.5%

Covered Lines:
840

Relevant Lines:
1021

💛  - Coveralls


App name

I suggest you change the app name to "Image Tools"
The app is more than just an image resizer.

Mb yes, but Image Resizer is better, because it underlines for the user main aim of the app👀


[ceres] cmake project which uses ceres results in build failure

Is your feature request related to a problem? Please describe.
I am using ceres[core,cxsparse,eigensparse,lapack,suitesparse,tools]:x64-linux, which should be static linked. It is said that I should use it in CMake via

    find_package(Ceres CONFIG REQUIRED)
    target_link_libraries(main PRIVATE ceres)

However, when I use in my project like
cmake_minimum_required(VERSION 3.14)

project(ceres_face_expression)

set(CMAKE_CXX_STANDARD 14)

find_package(pybind11 CONFIG REQUIRED)
#find_package(suitesparse CONFIG REQUIRED)
find_package(Ceres CONFIG REQUIRED)

pybind11_add_module(ceres_exp ceres_exp.cpp ExpCeresFitter.cpp L1SparseCostFunctor.hpp LinearL2CostFunctor.hpp)

target_link_libraries(ceres_exp PRIVATE ceres)

There is an error log in CMake:
${HOME}/Data/git-task/vcpkg/downloads/tools/cmake-3.14.0-linux/cmake-3.14.0-Linux-x86_64/bin/cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=${HOME}/.linuxbrew/bin/make -DCMAKE_C_COMPILER=${HOME}/.linuxbrew/bin/gcc-9 -DCMAKE_CXX_COMPILER=${HOME}/.linuxbrew/bin/g++-9 -Dpybind11_DIR=${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11 -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake -G "CodeBlocks - Unix Makefiles" /tmp/tmp.sNqrB0xSG9
-- Found installed version of Eigen: ${HOME}/Data/git-task/vcpkg/installed/x64-linux/share/eigen3
-- Found required Ceres dependency: Eigen version 3.3.7 in ${HOME}/Data/git-task/vcpkg/installed/x64-linux/include/eigen3
-- Found Ceres version: 1.14.0 installed in: ${HOME}/Data/git-task/vcpkg/installed/x64-linux with components: [EigenSparse, SparseLinearAlgebraLibrary, SuiteSparse, CXSparse, SchurSpecializations, OpenMP, Multithreading]
-- Configuring done
CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::suitesparseconfig" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::amd" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::btf" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::camd" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::ccolamd" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::colamd" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::cholmod" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::cxsparse" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::klu" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::ldl" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::umfpack" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::spqr" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::suitesparseconfig" but the
  target was not found.  Perhaps a find_package() call is missing for an
  IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::amd" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::btf" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::camd" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::ccolamd" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::colamd" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::cholmod" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::cxsparse" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::klu" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::ldl" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::umfpack" but the target
  was not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

CMake Error at ${HOME}/Data/git-task/vcpkg/scripts/buildsystems/vcpkg.cmake:198 (_add_library):
  Target "ceres_exp" links to target "SuiteSparse::spqr" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?
Call Stack (most recent call first):
  ${HOME}/Data/anaconda3/envs/nl3dmm/share/cmake/pybind11/pybind11Tools.cmake:131 (add_library)
  CMakeLists.txt:11 (pybind11_add_module)

-- Generating done
-- Build files have been written to: /tmp/tmp.sNqrB0xSG9/cmake-build-tryvcpkg

So I modified my CMakeLists.txt as
cmake_minimum_required(VERSION 3.14)

project(ceres_face_expression)

set(CMAKE_CXX_STANDARD 14)

find_package(pybind11 CONFIG REQUIRED)
find_package(suitesparse CONFIG REQUIRED)
find_package(Ceres CONFIG REQUIRED)

pybind11_add_module(ceres_exp ceres_exp.cpp ExpCeresFitter.cpp L1SparseCostFunctor.hpp LinearL2CostFunctor.hpp)

target_link_libraries(ceres_exp PRIVATE ceres SuiteSparse::amd SuiteSparse::btf SuiteSparse::klu SuiteSparse::ldl)

Then the output log is
-- Using VCPKG FindBLAS. Remove if CMake has been updated to account for Threads in OpenBLAS!
-- A library with LAPACK API not found. Please specify library location.
-- Found installed version of Eigen: ${HOME}/Data/git-task/vcpkg/installed/x64-linux/share/eigen3
-- Found required Ceres dependency: Eigen version 3.3.7 in ${HOME}/Data/git-task/vcpkg/installed/x64-linux/include/eigen3
-- Found Ceres version: 1.14.0 installed in: ${HOME}/Data/git-task/vcpkg/installed/x64-linux with components: [EigenSparse, SparseLinearAlgebraLibrary, SuiteSparse, CXSparse, SchurSpecializations, OpenMP, Multithreading]
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/tmp.sNqrB0xSG9/cmake-build-tryvcpkg

Please note that it didn't find LAPACK API.
Now the project compiles and builds, when when I execute it as
Python 3.5.2 (default, Nov 12 2018, 13:43:14)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ceres_exp
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /tmp/tmp.sNqrB0xSG9/cmake-build-tryvcpkg/ceres_exp.cpython-35m-x86_64-linux-gnu.so: undefined symbol: dpotrf_
>>>

So it doesn't find LAPACK API.
Proposed solution

What is the proper way to use the static linked x64-linux ceres? I want to know what should be written into CMakeLists.txt.

Is there anything going wrong with vcpkg's FindLAPACK and FindBLAS? I think x64-linux tends to static link external libraries and dynamic link c runtime, so I expect my project to use a static version of lapack and doesn't need external .so file when running, but vcpkg cannot find the lapack and openblas libraries installed by vcpkg.

Describe alternatives you've considered
I know that the same CMakeLists.txt works with linuxbrew, with CMAKE_PREFIX_PATH set to linuxbrew's installation path.
Thanks!

About the suitesparse problem, it seems that a find_dependency(Suitesparse) is missing from
CeresConfig.cmake
About the lapack error, I have to investigate more.

I've investigated error with LAPACK. It seems like, cmake can't find LAPACK library because of check_function_exists () in FindLAPACK module. I think that clapack has fortran symbols for some lapack functions (cheev_ in this case), so check_function_exists returns false and therefore lapack api couldn't be found by cmake. Unfortunately, we can't enable fortran compiler in CMakeLists, because of ninja. As workaround I can suggest to add option -DLAPACK_lapack_WORKS = ON, to the portfile. It will work at least for x64 architecture. It isn't an elegant solution, but I don't know another way, how it could be fixed. Well, this problem is actual for other libraries too, for example, G2O builds without targets, which depend on LAPACK. Also I haven't faced this problem on windows, just on linux.


Upgrade Develocity plugin to 3.17

Context
Update the version of the Develocity plugin used in the gradle build. I also fix the usage of the deprecated APIs. Additionally, I upgrade the develocity-testing-annotations to the latest released version.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test and merge


Build filament on windows 10 use vs2019,generated a lot of c99 standard error.

Hello there,but i got a problem about windows build filament, my system environment below：
windows 10 ，  vs2019 ，python 3.7 ，cmake 3.20，filament version 1.11.2,
I followed the build doc to create  TNT.sln ,this step is ok,but when i build the solution it generated a lot of errors，
I find out is becase of c99 standard is not supported very well on vs2019，for example ：const Header header {
.version = VERSION,
.parts = 1,
.aabb = unitBox,
.offsetTangents = sizeof(positions),
.offsetColor = sizeof(positions) + sizeof(tangents),
.offsetUV0 = sizeof(positions) + sizeof(tangents) + sizeof(colors),
.strideUV1 = maxint,
.vertexCount = vertexCount,
.vertexSize = sizeof(positions) + sizeof(tangents) + sizeof(colors) + sizeof(uv0),
.indexType = IndexType::UI16,
.indexCount = 3,
.indexSize = sizeof(uint16_t) * 3
};
this is not supported when assign a struct value by dot on vs2019，if i have to modify all of this code grammar myself or is there any steps did wrong；
Is there any suggestions？I look forward to receiving your reply，thank u！

by the way this is my cmake build info:
D:\dev\filament_git\filament\out>"C:\Program Files\CMake\bin\cmake.exe" ..
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19042.
-- The C compiler identification is MSVC 19.20.27508.1
-- The CXX compiler identification is MSVC 19.20.27508.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.20.27508/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.20.27508/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is MSVC
-- Found assembler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.20.27508/bin/Hostx64/x64/cl.exe
-- DFG LUT size set to 128x128
-- No build type selected, default to Debug
-- Found PythonInterp: C:/ProgramData/Miniconda3/python.exe (found suitable version "3.7.4", minimum required is "3")
-- The ASM_MASM compiler identification is MSVC
-- Found assembler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.20.27508/bin/Hostx64/x64/ml64.exe
-- Configuring done
-- Generating done
-- Build files have been written to: D:/dev/filament_git/filament/out

What's the error that you're seeing?

Hello，bejado,there is more than 1000 errors.
I'll give you an example to illustrate，for example i only build BlockCompression.cpp  part of the errors is like below:
Error	C3861	'astcParseOptionString': identifier not found	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	518
Error	C2065	'ASTC': undeclared identifier	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	520
Error	C2653	'CompressedFormat': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	524
Error	C2653	'CompressedFormat': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	529
Error	C2653	'CompressionConfig': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	516
Error	C2653	'CompressionConfig': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	520
Error	C2653	'CompressionConfig': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	525
Error	C2653	'CompressionConfig': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	530
Error	C2653	'CompressionConfig': is not a class or namespace name	imageio	D:\dev\filament_git\filament\libs\imageio\src\BlockCompression.cpp	533
Because there are too many errors(over hundreds),so i only list part of them.
These mistakes are strange，I found three returns of CompressedTexture  like below
return {
.format = config.format,
.size = size,
.data = decltype(CompressedTexture::data)(buffer)
};
Because vs2019 has a red line error message about .format，if i modify the code grammar like blow：
return {
config.format,
size,
decltype(CompressedTexture::data)(buffer)
};
It‘s succeeded.
1>------ Build started: Project: imageio, Configuration: Release x64 ------
1>BlockCompression.cpp
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
There are too many grammar like above。

We build Filament using VS2019 and we don't run into this issue.

Hello romainguy, yes， so weird,i wonder if my vs2019 version is too low，16.0 version，i will download high version vs，thank u！


added createDepositAddress

This PR adds createDepositAddress functionality to the sparkswap ccxt exchange. This PR also disables checks for apiKey and secret because we do not use these properties w/ the daemon

 add createDepositAddress to ccxt implementation


High proportion of reads with no alignment

Hi Jared,
I'm running nanopolish on a couple of old-ish (early 2018) data sets generated from amplicons and am getting a lot of reads with no alignment. I'm basecalling with Guppy, demultiplexing with qcat, aligning to a reference with bwa mem, calling a draft, indexing the demultiplexed fastq files (all reads found and indexed, no errors), aligning the indexed reads to the draft, and running variants:
nanopolish variants -p 1 -t 20 --reads /full/path/to/barcode11.fastq --bam /full/path/to/primerclipped.bam --genome /full/path/to/draft.fasta > /full/path/to/polished.vcf
[fai_load] build FASTA index.
Number of variants in span (25) would exceed max-haplotypes. Variants may be missed. Consider running with a higher value of max-haplotypes!
[post-run summary] total reads: 25385, unparseable: 0, qc fail: 567, could not calibrate: 10, no alignment: 17740, bad fast5: 0
I'm seeing the same issue on all of the barcodes on both runs (tried it with and without soft-clipping the primers as well but it gave the same output). It hasn't been happening with more recent runs so it may be something related to the older run/fast5s?
I've seen a couple of other people reporting similar issues but they seem to have been user specific, any chance you could take a look?
If so, let me know what you'd need and I will get it over to you.
Cheers,
Sam

Hi Sam,
I agree that is an unusually high proportion of unaligned reads. Could you send me a subset of fast5s (enough for ~200x coverage of the genome), the barcode11.fastq, primerclipped.bam and draft.fasta files?
Thanks,
Jared

Hi Jared,
I've sent you a link to the files, let me know if you don't receive it.
Thanks,
Sam

Hi @samstu,
I've been trying to email you but have received bounce backs from your mail server. If there's another email address you can use, can you email me? I've been unable to read the files that you uploaded.
Jared

As discussed over email, the problem was that sequencing speed was slightly lower than expected so failed nanopolish's internal QC checks. Closing this issue for now but will consider how to better handle variation in sequencing speed.


No Contact List

would be nice if there was a contact list. I can't see/search for my friends.

I would like to add as a google fi user, I have a bunch of phone numbers for SMS instead of contact names.

@mauricecox can't you add using the + button on the bottom left?
@stealthgyro YakYak does not support google fi very well, we need a dev that uses it in a regular basis ;)

Contact list would be awesome!  It would be great to be able to have a list that doesn't constantly move around.


Fix: Typos in Documentation and Code Comments

Modified Files

arbiter.rs:

Corrected "abiter" → "arbiter".

mod.rs (within dkg):

Fixed "arbtier" → "arbiter".

ops.rs:

Corrected "poool" → "pool".

mod.rs (within primitives):

Fixed "Implenting" → "Implementing".

scheme.rs:

Corrected "implments" → "implements".

Added the spellchecker after I wrote this lol 😓


Maya: enable 2D Pan/Zoom for playblasts - OP-5213

Changelog Description
Setting for enabling 2D Pan/Zoom on reviews.
Additional info
Also a bug fix where the review representation images were hardcoded to PNGs.
Testing notes:

Enable project_settings/maya/publish/ExtractPlayblast/capture_preset/Generic/pan_zoom
Setup review in Maya with a camera that uses 2d Pan/Zoom.
Publish and validate the review is using the 2d Pan/Zoom.

@BigRoy you happy with this?

I am thinking since previously the codec was hardcoded to PNG but it now uses the settings which defaults to JPEG whether we should update the default to PNG so that it matches previous behavior?

Yeah, good point and done.

I am thinking since previously the codec was hardcoded to PNG but it now uses the settings which defaults to JPEG whether we should update the default to PNG so that it matches previous behavior?

Its hardcoded to jpeg atm. What you do think? Follow playblast encoding or keep it hardcoded to jpeg.

Its hardcoded to jpeg atm. What you do think? Follow playblast encoding or keep it hardcoded to jpeg.

I'd keep it as is for now. PNGs create alpha and not sure whether we want that on the thumbnails for now.


Update package.json to include the repository

Hi there!
This change adds the repository property to your package.json file(s). Having this available provides a number of benefits to security tooling. For example, it allows for greater trust by checking for signed commits, contributors to a release and validating history with the project. It also allows for comparison between the source code and the published artifact in order to detect attacks on authors during the publication process.
We validate that we're making a PR against the correct repository by comparing the metadata for the published artifact on npmjs.com against the metadata in the package.json file in the repository.
This change is provided by a team at Microsoft -- we're happy to answer any questions you may have. (Members of this team include @s-tuli, @iarna, @v-rr, @v-jiepeng, @v-zhzhou and @v-gjy). If you would prefer that we not make these sorts of PRs to projects you maintain, please just say. If you'd like to learn more about what we're doing here, we've prepared a document talking about both this project and some of our other activities around supply chain security here: microsoft/Secure-Supply-Chain
This PR provides repository metadata for the following packages:

razzle-examples-basic
razzle-examples-basic-spa
razzle-examples-with-custom-babel-config
razzle-examples-with-custom-devserver-options
razzle-examples-with-custom-environment-variables
razzle-examples-with-custom-webpack-config
razzle-examples-with-elm
razzle-examples-with-typescript
razzle-examples-with-firebase-functions
razzle-examples-with-heroku
razzle-examples-with-hyperapp
razzle-examples-with-inferno
razzle-examples-with-jest
razzle-examples-with-jsxstyle
razzle-examples-with-koa
razzle-examples-with-loadable-components
razzle-examples-with-material-ui
razzle-examples-with-mdx
razzle-examples-with-now
razzle-examples-with-polka
razzle-examples-with-preact
razzle-examples-with-react-native-web
razzle-examples-with-reason-react
razzle-examples-with-redux
razzle-examples-with-scss
razzle-examples-with-styled-components
razzle-examples-with-vendor-bundle
razzle-examples-basic

Is there anything that is needed to land this pull request ?


Ability to reset user password

Currently in SqlPad, if you forget your password you are out of luck. Eventually an admin/cli interface should be able to reset a user's password, allowing them to create a new one.

I'd like to tackle this one, but I'm not really sure how to go about it. Ideally, the app would send a password reset email, but that sounds somewhat out of scope for SqlPad.
So maybe an admin could set a temporary password, which would not only disable the current password, but also toggle a flag that forces the user to set their own password on first login. As SqlPad is for private networks, the admin could simply tell the temporary password to the user.
Alternatively, if you'd like to go with the email option, we could add a minimal SMTP module that can be configured via the new configuration interface. This would allow SqlPad to send emails and it wouldn't touch any other part of the codebase.
Personally I'm fine with either option. What do you think?

Initially I was thinking something like the temporary password you are proposing, or a secret url that gets generated for an admin to manually email to the user so they can set a new password. I think it'd be nice if teams could run SqlPad without needing access to an SMTP server.
That said, I think the ability to add SMTP support would be awesome and very professional. I've never done any email stuff with node yet so I don't know what's involved.
If its something you want to tackle by all means go for it :)

All right then, I'll tackle the SMTP thing when I can :)

node-mailer?

in v2!


Adding OCR to the repository

Closes #406

Spec?

SimpleCov thinks it's covered, but I'm happy to add some tests for it explicitly.

Yeah, it's probably covered because it's not crashing, but something to make sure it's actually in the repo would be good.

Coverage remained the same at 100.0% when pulling 1b2d8a3474e90e35c3bc4ea43847d997fdaa9cc8 on repo-ocr into d218a842184b8fd6af2db5f39744497256895068 on master.


Update autoclusterplugin.md

Making the parameters adhere to common schema. Fixed formatting for examples in parameters table.

@shsagir

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#please-close
I'm closing this to make more fixes in a separate PR. Please open PRs from the private repository in the future.


[SPARK-44269][SQL] Assign names to the error class LEGACY_ERROR_TEMP[2310-2314]

What changes were proposed in this pull request?
The pr aims to assign names to the error class LEGACY_ERROR_TEMP[2310-2314].
Why are the changes needed?
Improve the error framework.
Does this PR introduce any user-facing change?
'No'.
How was this patch tested?
Exists test cases updated and added new test cases.

+1, LGTM. Merging to master.
Thank you, @beliefer.

@MaxGekk Thank you!


Android client doesn´t show previews of uploaded photos

Summary
Android client doesn´t show previews of uploaded photos
Environment Information

Device Name:  Android mobile
OS Version:  7.0
Mattermost App Version: 1.0 (Build 39)
Mattermost Server Version: 5.0.0

Steps to reproduce
Upload a photo with the android client
Expected behaviour
Show thumbnail (I added a screenshot of the same chat section shown in a Ios client)
Observed behavior
Shows placeholder

Hi @Twilek-de! Thank you for reporting this.
It is most likely that v1.0 does not yet support image previews on Android - would you like to try upgrading to a later version to see if that helps? (latest version is v1.9.1).


Attack function

Would it be possible to specify a mob that can be naturally aggressive (a pigzombie) to attack a spider or a zombie? Probably in Entityaddedhook(cant think of that name). Like:
function entityaddedhook(){
if entity added id = pigzombie{
check for spider
if findmob(Spider) = true{  //this part could be optional if you added the attack function auto after finding the mob
Attack entity(spider)
Would it be possible?

Entity.setAggressiveTo(entity, target);
This could be really useful, so I could make any wolves spawn target the player and such. However, entities like wolves will attack an entire entity type, so maybe there could be another function that allows us to make them attack an entity ID.

There are ways online but they are always lag.

Added in latest beta: Entity.setTarget(entity, target).


server workspace name issue

Hello. Thanks for writing well. Thank you. There is one problem, however, when connecting to another server, the workspace name only appears as / ㅡ (Remote). The problem is that you can't distinguish when connecting multiple servers. How can I solve this?

https://github.com/liximomo/vscode-remote-fs/issues/47#issuecomment-466320054


Add BrainGlobe collection

This is great, @adamltyson!!
One concern is with the cover image, though. This is more like the header image on Twitter/Linkedin/etc rather than a logo or avatar.
Ignore the gibberish pseudo-text, but these mockups should give you the idea...

The same image will be cropped differently depending on screen width and context:

You're welcome to use any of the images in images/, though neuro is under-represented. I suspect that one of the images from https://brainglobe.info/ or https://brainglobe.info/cellfinder would work well.
Or, we can help hunt down a good image for BrainGlobe if you'd like.

Ah yes, I didn’t look into what the images should be like. The image on my website  looks alright when cropped arbitrarily.

The image on my website looks alright when cropped arbitrarily.

Yes! I think that would be perfect!!

Hey @neuromusic, I've changed the image. It's a bit smaller than 1400px, if it needs to be bigger, I'm happy to go with one of the sample images. The images on the BrainGlobe website always look a bit weird when cropped arbitrarily.
It might be worth making the image criteria a bit more obvious. I only read the README, and the example yml file, and I imagine others may do the same.

It's a bit smaller than 1400px, if it needs to be bigger, I'm happy to go with one of the sample images.

Let's try this and see how it goes.

It might be worth making the image criteria a bit more obvious. I only read the README, and the example yml file, and I imagine others may do the same.

Will do, thanks for the feedback :D


feat: add intervenable_model to forward's function signature

Description
Added the intervenable_model parameter to the forward function signature, enabling user-defined intervention classes to have direct access to the model instance. This allows for more advanced manipulations such as using intervenable_model.model.lm_head(base) to interact with lower-level model components.
Testing Done
Tested the changes locally by defining custom intervention classes that access the model's internal components, including the lm_head. Verified that these interventions function as expected during model execution.
Checklist:

[x] My PR title strictly follows the format: [Your Priority] Your Title
[x] I have attached the testing log above
[x] I provide enough comments to my code
[ ] I have changed documentations
[x] I have added tests for my changes

Thanks for the change! The use case seems to be useful.
One general comment, could you turn the intervention signature into a more generic version using kwargs?
def forward(self, base, source, subspaces=None, **kwargs):
...
``

And the caller in these setter function should also take in **kwargs from user, if it is passed, then set.

The intervenable model forward call thus can take in arguments such as,

`pv_model.forward(base=..., sources=[...], intervenable_model=pv_model)`

Let me know if this makes sense! If you could make this change, it would be great since it will support many use cases.

Hi @frankaging , I think it totally makes sense and have updated the code accordingly. Please take a look when you have a chance. Thanks!

hi @frankaging I just made another PR
Now the function signature for users looks like
    def test_with_llm_head(self):
        that = self
        _lm_head_collection = {}
        class AccessIntervenableModelIntervention:
            is_source_constant = True
            keep_last_dim = True
            intervention_types = 'access_intervenable_model_intervention'
            def __init__(self, layer_index, *args, **kwargs):
                super().__init__()
                self.layer_index = layer_index
            def __call__(self, base, source=None, subspaces=None, model=None, **kwargs):
                intervenable_model = kwargs.get('intervenable_model', None)
                assert intervenable_model is not None
                _lm_head_collection[self.layer_index] = intervenable_model.model.lm_head(base.to(that.device))
                return base
        # run with new intervention type
        pv_llama = IntervenableModel([{
            "intervention": AccessIntervenableModelIntervention(layer_index=layer),
            "component": f"model.layers.{layer}.input"
        } for layer in [1, 3]], model=self.llama)
        intervened_outputs = pv_llama(
            base=self.tokenizer("The capital of Spain is", return_tensors="pt").to(that.device),
            unit_locations={"base": 3},
            # anything passed here will be forwarded to the __call__
            intervenable_model=pv_llama
        )

👀👀👀👀


wpa_supplicant: allow both imperative and declarative networks

Motivation for this change
:warning: Warning: this PR contains a patch for wpa-supplicant, an IMHO pretty sensitive software, also this is an experiment from me to see how well both static and imperative networks work in wpa_supplicant. So before considering this mergable, a few people with more C experience than I have should take a look!

For a while now it's possible to specify an additional config file in
wpa_supplicant[1]. In contrast to the file specified via -c this was
supposed to be used for immutable settings and not e.g. additional
networks.
However I'm a little bit unhappy about the fact that one has to choose
between a fully imperative setup and a fully declarative one where the
one would have to write credentials for e.g. WPA2-enterprise networks
into the store.
The primary problem with the current state of wpa_supplicant is that
if the SAVE_CONFIG command is invoked (e.g. via wpa_cli), all known
networks will be written to /etc/wpa_supplicant.conf and thus all
declarative networks would get out of sync with the declarative
settings.
To work around this, I had to change the following things:

The networking.wireless-module now uses -I for declarative config,
so the user-controlled mode can be used along with the
networks-option.

I added an ro-field to the ssid-struct in the
wpa_supplicant-sources. This will be set to 1 for each network
specified in the config passed via -I.
Whenever config is written to the disk, those networks will be
skipped, so changes to declarative networks are only temporary.

[1] https://w1.fi/cgit/hostap/commit/wpa_supplicant?id=e6304cad47251e88d073553042f1ea7805a858d1
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 113716 at 9ef9c044 run on aarch64-linux 1

2 packages built:

wifish
wpa_supplicant

1 suggestion:

warning: missing-patch-comment
Please add a comment on the line above, explaining the purpose of this patch.
Near pkgs/os-specific/linux/wpa_supplicant/default.nix:17:5:
   |
17 |     (fetchurl {
   |     ^

Is using wpa_supplicant with an external password file a solution to "passwords-in-store" problem?
networking.wireless.extraConfig = "ext_password_backend=file:/path/to/passwords.conf";

Interesting, I wasn't aware of this option, I'd guess so :)
However there's another usecase I'd like to cover: sometimes I only need a wifi net temporarily and then I really don't want to nixos-rebuild my system. Also, it can be helpful to initially configure a net with e.g. wpa_gui and "persist" it later on :)

It is against declarative nature of the service if config is read from an external file. It may crash if the external file is incorrectly formatted etc. I think this should be solved at wpa_gui side not at wpa_supplicant side. However I only used wired network, so I am not proficient in wireless configuration.

I think this should be solved at wpa_gui side not at wpa_supplicant side

The thing is, both wpa_cli and wpa_gui send a SAVE_CONFIG to wpa_supplicant with a payload, so the actual logic regarding how changes are persisted is implement in wpa_supplicant. Or am I misunderstanding the approach you're thinking of? :)

It is against declarative nature of the service if config is read from an external file

Yes. OTOH I think that a boundary of declarativity is reached: while I like to configure frequently used networks declaratively, I don't want to rebuild my system for let's say a hotel wifi.
Would you prefer a solution where this behavior is opt-in?

It may crash if the external file is incorrectly formatted et

That's a valid concern!
Please note that I don't expect this to be merged kinda soon. This was mostly intended as an "experiment" for now. Before this hits upstream master, a few more people should review this (especially the C patch). To give this some kind of basic test coverage, I'll use this on my laptop for now to see if I encounter any issues.

I marked the PR as draft to better reflect the experimental status. Feel free to undraft at any time.

Please note that I don't expect this to be merged kinda soon. This was mostly intended as an "experiment" for now. Before this hits upstream master, a few more people should review this (especially the C patch). To give this some kind of basic test coverage, I'll use this on my laptop for now to see if I encounter any issues.

I think patching wpa_supplicant itself is kinda extreme for this problem. Maybe you can try overriding systemd service's script attribute to combine configFile and /etc/wpa_supplicant.conf into a single file and then feed that file to -c argument.

Maybe you can try overriding systemd service's script attribute to combine configFile and /etc/wpa_supplicant.conf into a single file and then feed that file to -c argument.

Can you elaborate? As soon as wpa_supplicant writes to this file, declarative changes will be modified.

There is also networking.supplicant option. Is it possible to declare declarative networks in extraConf and set configFile.path to include temporary networks? This requires networking.wireless to be disabled, I presume.

For some reason, that one is duplicated and should be removed actually: https://github.com/NixOS/nixpkgs/issues/22401

Well, it is still available in 21.09 so you can try it.

Is it possible to declare declarative networks in extraConf and set configFile.path to include temporary networks?

AFAIU no. This path will be passed to wpa_supplicant with -I and then we have the exact same issue as described above.

It seems configFile.path  is passed with -c here. extraConf is written to a file and passed with -I.

Yes. And temporary networks have to be written to writable file. Hence configFile.path passed via -c. wpa_supplicant doesn't write to the file passed via -I.

I think this should work like this supplicant."wlan0".configFile.path = "/etc/wpa_suppliant.conf". And then you can set declarative configurations in supplicant."wlan0".extraConf.

This is the config passed via -I in the end. When you modify this network now in e.g. a CLI or GUI interface, it will be copied to /etc/wpa_supplicant. Since the list of known SSIDs is a linked list internally, the modified value will take precedence over the one from your NixOS config. And due to that property, the idea of using -I for declarative config rather than -c isn't a good one.

Manual for networking.supplicant.<name>.extraConf says Options defined here have precedence over options in configFile.

I don't know where this claim comes from, but I actually confirmed that overriding config in wpa_gui and having it saved to /etc/wpa_supplicant.conf takes precedence. I mean I hoped this wouldn't be the case as this would've saved the time I invested in patching wpa_supplicant :D

I think this is even better. If wifi password is changed temporarily, it can be overridden in the conf file without rebuilding the system. Especially at different places with the same SSID. Don't you think?

I think that silently overriding declarative (as in "single source of truth") values is not really desirable.

It sounded dangerous when you say it like that.

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

wpa_config_write re-saves network entries coming from the constant file (passed with -I) into the generic file (passed with -c), right? Actually this is an upstream issue. Maybe we should report this to wpa_supplicant developers?

IIRC the file passed with -I isn't supposed to be used for networks (even though that's possible). I mainly decided to use this mechanism for "our needs" :)

Maybe the best idea is, to introduce an option like networking.wireless.allowImperativeNetworks and making it disabled by default. Also introduce a new derivation, something like wpa_supplicant-ro (similar to gui.nix) and then replace pkgs.wpa_supplicant with pkgs.wpa_supplicant-ro if allowImperativeNetworks is true.

That's what I meant with "opt-in" solution :) Sounds reasonable to me.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/imperative-declarative-wifi-networks-with-wpa-supplicant/12394/1

I don't use wireless, but for those who do, there is definitely a problem. At first I didn't like the idea of patching wpa_supplicant itself, but then again failed to offer a more viable solution. So I thought about creating a new derivation, like wpa_supplicant_ro that includes C code patches. This way, an untouched version of wpa_supplicant would still be available in nixpkgs.

Yeah I agree with that and I'll do this change before it gets merged. For now, I'd like to get a bit of feedback about the overall approach to know whether I should continue focusing on getting this into nixpkgs :)

Ok, just implemented the new behavior as opt-in now :)

This looks great! Have you seen this?
What about naming the option as something like allowImperativeNetworks or allowAuxiliaryImperativeNetworks?
Because declarative networks are allowed regardless of the setting :laughing:

What about naming the option as something like allowImperativeNetworks or allowAuxiliaryImperativeNetworks?

Good idea, fixed in my last push :)

Awesome. I think this PR is ready for prime time. It still can't beat ethernet though :smile:

I think this PR is ready for prime time.

Yeah. I'm running it for >2 months now without problems.

It still can't beat ethernet though

That's true :)
@bb2020 I'll mark this as "ready for review" now. Will wait for a at least a week now.

I don't have wifi to test it, but the code seems fine to me. It is disabled by default and an untouched version of wpa_supplicant is still in nixpkgs so there is not much to complain.
I wish there was a solution without patching native code, but for now, this looks like the only option.

I'm going to merge this now.
I discussed a bit about the patch with my colleague Linus last week and we agreed that even though I'm not very confident that this will be merged into upstream, I'll give it a try and file a patch: https://lists.infradead.org/pipermail/hostap/2021-May/039618.html


[Feature] Support duplicate data verification

[ ] If this is non-trivial feature, paste the links/URLs to the design doc.

[ ] Update the documentation to include this new feature.

[ ] Tests(including UT, IT, E2E) are added to verify the new feature.

[ ] If it's UI related, attach the screenshots below.

[x] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Fixes apache/skywalking#12253.

[ ] Update the CHANGES log.

I think you followed the wrong context.
What we discussed is about adding data verification in the e2e tool for OAP. Not for database itself.
We don't want this performance cost in the database.


Draft: mesa: use manamesa and add dri

Manamesa adds fixes to the r100/r200 driver and makes those 2 drivers libdrm_radeon independent. Currently manamesa does NOT link due to multiple redefinitions due to me copying a lot of code from libdrm which conflicts with the dri userland drivers so DO NOT MERGE THIS RIGHT NOW, NOT EVEN WORTH MUCH TO REVIEW THIS FULLY. This does not require any patches as it supports managarm out of the box.
TODO:
r100/r200 compile fixes(ez) - Permanently Postponed(no one has both a r100 and r200 chipset in their sytem silly!)
nv driver support(chore, not worth much due to lack of support might be easy though, idk)
i915/i965 support(requires libpciaccess port before I can work on it, medium difficulty and I wont add that port due to lack of motivation to do so)
r300/r600 support(Far off from now, hard, Adds newish AMD gpu support)
NOTE TO ANYONE LOOKING TO CREATE A DRM SUBSYSTEM FOR MANAGARM:
I probably will not add new amd device support on the dri driver system later than GCN 2.0! This means that if you are looking to add the radeon kernel driver it will not add new device support(it will actually lower it :( ) so go with porting the amdgpu driver. The i915/i965 incoming driver support(when libpciaccess gets ported) also means that a i915/i965 port drm port would probably be better spent on manamesa UNLESS you want gallium fronted acceleration for things like D3D9.

This seems to be a personal fork? I'm not willing to merge that in favor of upstream mesa. Either get the patches into upstream or make this a separate package.

This seems to be a personal fork? I'm not willing to merge that in favor of upstream mesa. Either get the patches into upstream or make this a separate package.

I guess it could be considered a personal fork? I didnt want to bloat bootstrap-managarm with Mesa patches so I added it as a separate repository...there was talk of something like this inside a mesa branch but none of that got anywhere...Ill change this to be a different package once I finish r100/r200 support and add a bit of r300/r600 support.

what does this achieve? our goal would be to, ultimately, run Free software targeting Linux unmodified. There's few technical hurdles to this, and including libdrm headers inside mesa (for some reason) is not fixing any of them.
If there's any legitimate, non-managarm-specific fix, it should be upstreamed. If it is managarm-specific, it is likely something that is to fix in managarm, and not Mesa (unless it's a build system issue, like the patches this PR removes were).
Forking Mesa is a strange proposal, there's no technical or even political justification for incurring such a heavy maintenance burden on yourself.

Add r100/r200 support for those without libdrm

I don't see a driver. Though this commit is too large for anyone to sit through, so I could've missed it.

21.3.5 removed the r100/r200/nv/i915/i965 drivers that didnt depend on drm from the kernel. Managarm doesnt have the libdrm_radeon things needed to compile Mesa 21.3.5 unmodified, either way I dont like the idea of having libdrm on a microkernel system :( r300/r600 was also removed(main motivation for forking mesa) and since I have a r600 architecture GPU I wish to bring back support for it which would be too much to add in a simple patchfile.
Hope that paragraph answers most of your questions.

Eh...who closed this?

By the way, I am assuming that you are aware that the DRI driver still needs the kernel driver to work, even if you moved libdrm into Mesa. For example drivers/dri/r200/libdrmbits/radeon_cs_gem.c uses drmCommandWriteRead to submit commands to the kernel driver (because all libdrm is, is wrappers around the ioctl interface used to communicate with the kernel).

By the way, I am assuming that you are aware that the DRI driver still needs the kernel driver to work, even if you moved libdrm into Mesa. For example drivers/dri/r200/libdrmbits/radeon_cs_gem.c uses drmCommandWriteRead to submit commands to the kernel driver (because all libdrm is, is wrappers around the ioctl interface used to communicate with the kernel).

Nope!
yusufkhan@yusufkhan ~/m/s/p/mesa (amber)> grep -rlw cs_gem_emit
src/mesa/drivers/dri/radeon/libdrmbits/radeon_cs_gem.c
src/mesa/drivers/dri/r200/libdrmbits/radeon_cs_gem.c
yusufkhan@yusufkhan ~/m/s/p/mesa (amber)> grep -rlw radeon_get_device_id
src/mesa/drivers/dri/radeon/libdrmbits/radeon_cs_gem.c
src/mesa/drivers/dri/r200/libdrmbits/radeon_cs_gem.c
Its included but not used.

cs_gem_emit is used to set a function pointer in radeon_cs_gem_funcs, and that struct is used in radeon_cs_manager_gem_ctor, which in turn is used in rcommonInitCmdBuf (in drivers/dri/radeon/radeon_common.c).
Anyway, cs_gem_emit does the following:
    r = drmCommandWriteRead(cs->csm->fd, DRM_RADEON_CS,
                            &csg->cs, sizeof(struct drm_radeon_cs));

And drmCommandWriteRead is just
drm_public int drmCommandWriteRead(int fd, unsigned long drmCommandIndex,
                                   void *data, unsigned long size)
{
    unsigned long request;

    request = DRM_IOC( DRM_IOC_READ|DRM_IOC_WRITE, DRM_IOCTL_BASE,
        DRM_COMMAND_BASE + drmCommandIndex, size);

    if (drmIoctl(fd, request, data))
        return -errno;
    return 0;
}

Which will reach the kernel via the ioctl, and end up in radeon_cs_ioctl (in drivers/gpu/drm/radeon/radeon_cs.c in the Linux kernel), via the following entry in radeon_ioctls_kms (in drivers/gpu/drm/radeon/radeon_drv.c):
	DRM_IOCTL_DEF_DRV(RADEON_CS, radeon_cs_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),

In short, I’m aware that Mesa 22.x removed some drivers from upstream. As I told you before, they have been split off into a separate repo, and that is what we should use. We have libdrm ported and available (and not for Radeon and friends, if you need that, change the libdrm recipe to enable it. I highly doubt that this work will ever be accepted into bootstrap-managarm, and I know it will never be accepted under the name Mesa. Feel free to fix the issues mentioned by myself and others and open a new PR, but this one in its current state is doomed to fail.

21.3.5 removed the r100/r200/nv/i915/i965 drivers that didnt depend on drm from the kernel.

I believe all of these are now supported through DRM.

Managarm doesnt have the libdrm_radeon things needed to compile Mesa 21.3.5 unmodified, either way I dont like the idea of having libdrm on a microkernel system :(

This is not a valid reason to remove the dependency. There's nothing wrong with libdrm on microkernels. libdrm_radeon is built from the libdrm source through a flag. We don't have this enabled since we don't have the ioctl/drm subsystem component.

... and since I have a r600 architecture GPU I wish to bring back support for it which would be too much to add in a simple patchfile.

This driver was also unified with the rest of DRM.

EDIT2:This is the main driver portion https://gitlab.freedesktop.org/YusufKhan-gamedev/manamesa/-/tree/amber/src/mesa/drivers/dri

This isn't a driver (at least, not the whole thing).

Also, just to reiterate what was said on Discord for the record, xbstrap does not provide a way to mark conflicting packages or specify what libraries a package provides. For now, this is intentional. There are no conflicting packages and I’m not willing to start with that for this one either.

qookei: I see now, I thought it was independent since I saw many functions that were called that I knew didnt rely on kenrel drm...still could prove fun to remove drm as a dependency!

qookei: I see now, I thought it was independent since I saw many functions that were called that I knew didnt rely on kenrel drm...still could prove fun to remove drm as a dependency!

Fun perhaps, not something I’ll accept into master unless you have a really good reason for it. And just for the fun of it isn’t one of them. If that comes into this PR or remains in here, I wouldn’t count on it ever getting merged.

No. DRM was unified for a reason.
Make a better unified solution or implement a DRM compatibility layer if you wish to do something else.

Dennisbonke: My reason is I want to use my Riva TNT with managarm and drm doesn't support it

Dennisbonke: My reason is I want to use my Riva TNT with managarm and drm doesn't support it

Then add support to DRM for it? Or make it co-exist? No reason to rip out libdrm.

Dennisbonke: My reason is I want to use my Riva TNT with managarm and drm doesn't support it

Then add support to DRM for it? Or make it co-exist? No reason to rip out libdrm.

Easier said than done...

So it can coexist. Then make it so, as removing libdrm is not going to happen.

DRM supports nv04 devices.
https://nouveau.freedesktop.org/CodeNames.html#:~:text=NV04 family (Fahrenheit)


openapi3 - adds an internal output-spec-versions emitter option

This PR adds a new @typespec/openapi3 emitter option to support specifying which Open API 3.x specs to output.
Currently marked as @internal since currently only 1 version is actually supported. Once v3.1 is supported we can remove the @internal annotation.

All changed packages have been documented.

:white_check_mark: @typespec/openapi3

Show changes
@typespec/openapi3 - internal ✏

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs

This still would be shown as an emitter option in the docs and available right?

I tested the doc generation and the @internal annotation prevented docs from being updated (they did show up if I removed that annotation). That said I'm not opposed to creating a feature branch instead for this work.


fastqc and contrasts optional in the report

If no file is provided for contrasts and fastqc arguments, the respective paragraphs are omitted from the report.

This solves issue #24


Remove locks for tablets flag on Conn

Removes unnecessary Conn.mu locking on accessing tabletsRoutingV1 flag.
Conn.mu is overused, less it is used less contention is yielded along with more performance.

@dkropachev can you  please add the description also to the commit message?

@dkropachev can you please add the description also to the commit message?

Done

pls rebase on master

pls rebase on master

done


Connect ADBC and dbplyr through adbi

We need very little to make this work directly through adbi. Most of the "wrapper" code can go.
The odbc package creates connections with a subclass to indicate the database we're connecting to. This is important so that the generated dbplyr queries use the syntax understood by the database. We could do the same here. This would mean that adbi needs to add a subclass to its connection objects.
I think we're now at a stage where the SQL dialect is somewhat independent of the actual connection object. We could have PostgreSQL via:

RPostgres
RPostgreSQL
adbi
odbc

I wonder if we should instead extend dbGetInfo() for connection objects to include the SQL dialect and other info useful for query generation. The default dispatch in dbplyr could then take this into account. This will also make it easier to create dummy connections only used for query generation.
CC @hadley @mgirlich @nbenn.

Thanks, Hadley. I see how the new generic is better, but it is also... a new generic. This means extra work and an item more to document and to review when reading the documentation.
Regarding underspecification: I searched in the spec and, indeed, couldn't find it. But it is tested for, and the documentation is there: https://dbitest.r-dbi.org/reference/spec_get_info.html. I'll work on including this info in the spec document.

Spec will be added by https://github.com/r-dbi/DBI/pull/477. My vision here is to ask for more named elements for the "connection" generic, and to test them in DBItest. How does that sound?

Thanks, Dewey. That's the info I'd expose through dbGetInfo() . What other specifics can we get from there? Would adbcpostgresql report the version of the PostgreSQL server, or perhaps if it's a Redshift connection (if this is supported)? Other details that would allow discovering what is and isn't possible through this connection?


Stop reporting metrics sent by the batch processor

The batch processor metrics are not being used in any default dashboards but signicantly contribute towards metric timeseries created on the backend.

otelcol_processor_batch_batch_send_size
otelcol_processor_batch_timeout_trigger_send

You need to fix the tests by removing the name of the metrics we are looking for here:
https://github.com/signalfx/splunk-otel-collector-chart/blob/4786626888da7ad7ee329adc3545ce58bbe7483d/functional_tests/functional_test.go#L858-L860
and here: https://github.com/signalfx/splunk-otel-collector-chart/blob/4786626888da7ad7ee329adc3545ce58bbe7483d/functional_tests/functional_test.go#L1075-L1077

@atoulme, thanks


Changes made for table iteration

Description
Initially the tables used a simple string method of matching. Now its updated to iteration method that iterates over the tables.

Can you fix the formatting so that test passes, and add some new tests (leaving the existing ones as is) to show the new functionality?

Sure @tedivm 👍

Should we close this PR in favor of #26 ?

Yeah @tedivm  we can close it


node v6 issues

So it's more like that https://github.com/rlidwka/sinopia goes away. RIP.
Once again i think we need get call here all from https://github.com/rlidwka/sinopia/issues/376
Just started with testing on node v6. It works. In few days will try to test this fork.
If some one find npm/node related issue i think this is right place.
Thanks.

Glad that project received second breathe

Ok sorry for the delay tests on node 6 are fixed, 0.10 tests dont pass on OSX. Travis still passes them though. I think this is just because the tests are running by starting the server in a new process. I am trying to get the server in test to start in the same process.


Redirected routes not updating view

{ path : '/login', component : loader(VIEWS,'Login.vue')}
,{ path : '/logout', component : loader(VIEWS,'Logout.vue'), meta : { auth : true} }
,{ path : '/overview', component : loader(VIEWS,'Overview.vue'), meta : { auth : true} }
,{ path : '/home', redirect : '/overview'},
,{ path : '*', redirect: '/home'}

When current view is overview and eg the session has expired, this will call $router.push("/home")
which wil redirect again to overview. (why? i want this optional to goto to users choice)
the BeforeEach hook will than check if the session is OK and if not call $router.push("/login")
But because the isSameRoute does not take into account the redirectedFrom it will not generate a change but an abort
Is this a bug or intentional?
Can I resolve this another way, maybe missing a feature or not knowing.

When current view is overview and eg the session has expired, this will call $router.push("/home")
which wil redirect again to overview. (why? i want this optional to goto to users choice)

It's your code, and you don't show it to me, so how should I know?
This seems like a usage question, so this should be continued somehwere else.
We encourage you to ask it again on the forum  , Stack Overflow or on gitter and are happy to help you out there.
IF this ends up as a bug, we open another issue.

function isSameRoute (a, b) {
  if (b === START) {
    return a === b
  } else if (!b) {
    return false
  } else if (a.path && b.path) {
    return (
      a.path.replace(trailingSlashRE, '') === b.path.replace(trailingSlashRE, '') &&
      a.hash === b.hash &&
      isObjectEqual(a.query, b.query)
    )
  } else if (a.name && b.name) {
    return (
      a.name === b.name &&
      a.hash === b.hash &&
      isObjectEqual(a.query, b.query) &&
      isObjectEqual(a.params, b.params)
    )
  } else {
    return false
  }
}

Seems to me that this is your code and this does not take into account the redirectedFrom, to see if it is changed.

Sorry if I may have missunderstood what your issue is. Your original post is a bit confusing (maybe the language?) and does not contain a demo of the issue you seem to have so its hard to exactly see what you think is wrong.

Either you follow the Contributing Guidelines and provide a real report with a interactive demonstration about what the issue is,
or you go to the forum and we first see weither your problem (which i still don't really get) can be solved with the existing features.


Public Docker Image

[X] Dockerfile to build from zip artefact #548 f8cf3674327cf124f34f0a1ac3482ac94bf460e2

[ ] Create Github action to execute build and push to Docker Hub

https://hub.docker.com/r/predic8/membrane


Advance Kickstarter Campaign

meet with Ryan
rewrite pitch
work on video concept
work on campaign rewards and updates once campaign is launched
create sample book mockup pages using real example case study
investigate PressBooks as publishing platform

Create estimates of effort
Engage Jay and David Kindler in helping
Storyboard the video
Generate list of orgs we'll profile
Create a diagram of our open business model process


Vikram/sd3.5m skiplayercfg

Adds SkipLayerCFGDenoiser for SD3.5-Medium

Heya, just wondering what layers it is recommended to use this on, for which noise ranges?

Can someone help me understand what is the point of those changes? How does this affect output, speed and all?

SLG is for enhancing the guidance vector of a "certain part" of the model - in this case, we regard it as a way to enhance structural information like hands and anatomy,
It requires an additional forward pass to work so will slowdown the generation by around 33%

Dango233 do you know if this idea is unique to this model? Or has it been tried on 3.5 large, SDXL, SD1.5, etc?


Terminology: warning or rule violation, which one?

Throughout Sorald, we use the terms "warning" and "rule violation" interchangeably. To reduce confusion, we should pick one. I have no preference, I just want consistency. I can't find that there's any official terminology from SonarQube.
"Warning" is shorter than "rule violation", should we go with that? What terms do you use in the current paper?
@nharrand @monperrus @khaes-kth @fermadeiral

There is actually a slight difference: a warning points out a violation of a rule. A false positive is a warning without violation, and false negative is a violation without a warning.
As such, I think the correct terminology for us would be "warning", as we are not concerned with false positives/negatives in Sorald.

As such, I think the correct terminology for us would be "warning", as we are not concerned with false positives/negatives in Sorald.

I agree.

What terms do you use in the current paper?

We are using "rule violation" but I think you're right about the tool, it's better to use warning there.

Both are correct and have pros and cons.
I would prefer "rule violation" because it's more precise, more explicit, and cannot be confused
with compiler warnings, performance warnings, cost warnings, etc.

Since you are using "rule violation" for the paper, I think we should stick to that in the tool as well. I will start gravitating toward that terminology.

I'm fine with both of them and actually, Martin made a good point. I just want to mention the terminology in the paper should not be the only reason for our choice, we may change it a hundred times before submitting the paper :-)

I also thought @monperrus made a good point. "Warning" is pretty non-descriptive.

I'm gonna close this now. We gravitate toward "violation" rather than "warning" as it's more specific.

I'm gonna close this now. We gravitate toward "violation" rather than "warning" as it's more specific.


[BUG] @node-rs/crc32 module does not support ia32 for some insane reason, mirakurun fails to start

uname -srvmo: Linux 6.1.0-26-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) i686 GNU/Linux
cat /etc/issue: Debian GNU/Linux 12 \n \l
cat /proc/cpuinfo | grep name -m 1: model name      : Intel(R) Atom(TM) CPU N270   @ 1.60GHz
Version of Mirakurun: 3.9.0
Version of Docker: none. docker sucks
Version of Node: node -v: v18.19.0
Version of NPM: npm -v: 9.2.0

Issue (不具合の内容)
Error: Unsupported architecture on Linux: ia32
at Object. (/usr/local/lib/node_modules/mirakurun/node_modules/@node-rs/crc32/index.js:181:15)
Expected (期待される動作)
Should just work
Why does mirakurun depend on some rust-related CRC32 module when there are a million of them that work without needing rust.

upon further research, it looks like this node-rs/crc32 is only used by aribts/logo module to calculate PNG header CRC32. so extremely performance not critical piece. should just be rewriten using normal table-based crc32 version.


Add native module for linux-aarch64

native-linux-aarch64.tgz.txt
Here is a TGZ file of /home/ubuntu/.m2/repository/com/aayushatharva/brotli4j/native-linux-aarch64/. Just remove .txt extension (GitHub does not allow .tgz attachments).

Thanks a lot for the PR. <3
Can you add ARM build in GitHub Actions Workflow too so we can easily test it and build the binary?

GitHub Actions does not yet support ARM64 - https://github.com/github/roadmap/issues/95.
TravisCI and DroneIO do.


RFC: eslint-docs

eslint-docs is a tool created by me that makes maintaining ESLint plugins easier. It ensures that the names and descriptions of a plugin’s rules are consistent in the rule source, the documentation, and the README. Is this worth including in this awesome list?

Yes, you definitely should include it!


Can Marathon expose internal ip of the container?

When mesos spawns the container, can it expose the internal ip of the container which was spawned in bridge mode?

What do you mean with expose here?
I am currently experimenting with Weave and Mesos. I would like to have health checks using the internal IP instead of the host IP. Is it what you mean?

As far as I know it's not possible. Unless something has changed, related: #674

Close this issue, since it duplicates #674


feat: Filter symbols in the frontend

Description
A simple search box to filter the symbols. It is animated and such.
Related Issue
Filter symbols in the frontend - [#120]
Motivation and Context
Sometimes is hard to find the symbol with many monitored. This will help us.
How Has This Been Tested?
Searching something, then the data was filtered.
Screenshots:

Nice work @pedrohusky
I think you still have some formatting issues, but I can get it to fix.
Let me take a look when I get time.

Hmm, your code was ok and I tried to make it better, but I found some browser compatibility issues.
I may focus on another feature and get back to this.

Hmm, your code was ok and I tried to make it better, but I found some browser compatibility issues.
I may focus on another feature and get back to this.

Hi. What issues? Just to know.
@chrisleekr please see my last comment in security screen pull request. It is urgent.

@pedrohusky I close this PR because I made another PR #253 with the latest code.
Thanks again for your contributions!


npm istall on macOS Big Sur can't finish

Quick Summary:
I'm trying to run npm install elm but the process is frozen on download elm step.

Nothing happens after this.

Elm: 0.19.x
Operating System: macOS Big Sur (11.0.1)
Node version: v12.18.3 and v14.15.2

Related: https://github.com/elm/compiler/pull/2156

@lydell hello! I have a macbook pro 15 2017, it's not M1. Still related?

Ooops! Sorry. Maybe not.

On a MacBook Air 2013 running Big Sur 11.1 and npm 7.0.15, it succeeded. Admittedly I am entirely unfamiliar with npm, I got my copy through homebrew.

thank you, I also asks other developers. Looks like it is an issue on my machine. Let's close it.