UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v4.18 to before v5.4.136",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b3cebfe8c1cadf1817939dcc3688a2504a69c662",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f38527f1890543cdfca8dfd06f75f9887cce6151"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "b3cebfe8c1cadf1817939dcc3688a2504a69c662",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "f38527f1890543cdfca8dfd06f75f9887cce6151",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.4.136 by commit f38527f1890543cdfca8dfd06f75f9887cce6151, it was introduced in version v4.18 by commit b3cebfe8c1cadf1817939dcc3688a2504a69c662. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001312


root filesystem label is container_file_t when it should be root_t

Migrating this back from https://github.com/CentOS/centos-bootc/issues/184
Because we want to be able to add a proper Closes in this repository.

One thing I notice here...and I'm not yet certain if it's a bib regression or not, but looking at the disk image before it's booted:
$ guestfish --ro -a disk.qcow2
><fs> run
list-filesystems
><fs> list-filesystems
/dev/sda1: unknown
/dev/sda2: vfat
/dev/sda3: ext4
/dev/sda4: ext4
><fs> mount /dev/sda4 /
><fs> getxattrs /
[0] = {
  attrname: security.selinux
  attrval: system_u:object_r:container_file_t:s0\x00
}
><fs>

That's just really broken, we shouldn't end up with a physical disk image root labeled container_file_t!  It looks like actually all of the labels up to the deployment root are similarly broken (they should be something like root_t or usr_t).
However once we get to the deployment things are fine:
><fs> getxattrs /ostree/deploy/default/deploy/3ef1290eacdb05e50127ed5a920e264f228dae248addb10d98224a2e04918c2c.0/etc/fstab
[0] = {
  attrname: security.selinux
  attrval: system_u:object_r:etc_t:s0\x00
}
><fs> getxattrs /ostree/deploy/default/deploy/3ef1290eacdb05e50127ed5a920e264f228dae248addb10d98224a2e04918c2c.0/etc/passwd
[0] = {
  attrname: security.selinux
  attrval: system_u:object_r:passwd_file_t:s0\x00
}
><fs>

And it's specifically that /ostree/deploy/default/backing is also container_file_t, and the overlayfs picks up that context and that breaks everything.

BTW I don't have much experience with osbuild debugging...if someone can add a brief crash course into the README.md here on e.g. "how can I set a breakpoint right after org.osbuild.selinux runs that'd be awesome.  I read through https://www.osbuild.org/guides/developer-guide/index.html but didn't find anything like that.
Edit, ok osbuild --help shows a likely --break argument, but when I do e.g. osbuild --break org.osbuild.selinux /tmp/manifest-qcow2.json gives me...
source/org.osbuild.skopeo-index (org.osbuild.skopeo-index): Getting image list signatures
source/org.osbuild.skopeo-index (org.osbuild.skopeo-index): Copying 0 images generated from 4 images in list
source/org.osbuild.skopeo-index (org.osbuild.skopeo-index): Writing manifest list to image destination
source/org.osbuild.skopeo-index (org.osbuild.skopeo-index): Storing list signatures
build:    	d01a64a05a404fffed27a6182ca253009fa48b5b1c79cd1729e46fb032165855
ostree-deployment:	a45beec52e20b9ca354df13344e59e7d13b75eeaa17940ee3d4abb39d2d607a0
image:    	c90a3366e8c5638900e07decfcd238d42a1c02b029ff685d9410b87cd3fdc109
qcow2:    	b8b41e5c3f1581628872f9541e66f319b607bdbe1d24f6859c5b57fc221dbb74

but...I don't know what that means; as I understand it I should be able to find filesystem trees from those hashes I think, but I don't see them under /.osbuild.  (How could there be a hash for the qcow2 if I did --break?)
What I think is probably going on is that we need to do something a bit like this:
https://github.com/coreos/coreos-assembler/blob/90780f70cd4cd07ee84400c5e212c4060bbcd6c6/src/create_disk.sh#L295
Or I guess, since osbuild does that thing where it creates a temporary dir and then copies it all to the disk, we'd need to init the label for the root the same way.  I don't quite understand how this works in the outside-of-container osbuild flow unless by accident?

Something like rm -rf .osbuild and then a osbuild --break org.osbuild.selinux --export qcow2 --output-directory=/some/path manifest.json will drop you into /bin/bash for each org.osbuild.selinux stage encountered (there will likely be two and you'd want the second one).
I'll do some docs stuff about this today but the gist is that you need to have an export as well; and I think to not have the pipeline already in cache. I'm contemplating changing osbuild so that when you pass --break it will ignore caches and always export everything.

Thank you! I played around with this a bit and I think it's a bit random what labels we end up with on  the disk before the first boot.
When running the osbuild pipeline on a test Debian machine without selinux and run guestfish I see no labels at all for example.
The pipeline we generate in osbuild runs org.osbuild.ostree.container.deploy to install the files from the container into the deployment root. This stage is just a thin wrapper around  ostree container image deploy (took me a bit to find this in ostree-rs-ext) . And then org.osbuild.ostree.selinux which appears to be only labeling /boot (on /dev/sda2), /etc, /var (the last two are not on disk though). Pardon my ignorance here, assuming my above understanding is correct, what component should do the labeling of the sysroot/deployment root when we build the image (leaving it to firstboot as we did before seems to now trigger boot failures as recently observed in https://github.com/CentOS/centos-bootc/issues/184).
Following the code I see that there is a codepath from deploy.rs:deploy() that calls sysroot.deploy_tree_with_options to sysroot_finalize_deployment() which AIUI should do some labeling of the deployment root. So I'm clearly missing something.
Will moving to bootc install to-filesystem fix this issue - it seems both use the undelying ostree-rs-ext/lib/src/container/deploy.rs:deploy()` helper so maybe not?

The labeling should be from /.

https://github.com/CentOS/centos-bootc/pull/186 will undo the change that triggered this, but we still definitely need to fix the disk image labels.

When running the osbuild pipeline on a test Debian machine without selinux and run guestfish I see no labels at all for example.

We should just hard error out when trying to write a SELinux-enabled target system from a non-SELinux host.  It's possible but it's horrendously complex; today bootc install has explicit logic to disallow this...which we'd be using...if we were using bootc install...

The pipeline we generate in osbuild runs org.osbuild.ostree.container.deploy to install the files from the container into the deployment root.

The problem is around the filesystem root.  ostree is just a super fancy wrapper around chroot and hardlinks.  We need to ensure that what ostree calls the "physical /" aka the thing you see when you just mount the filesystem externally is labeled as root_t.  The coreos-assembler code linked above has some explicit logic to do that.  bootc...hmm, doesn't and it seems to work, which I think is actually a consequence of the fact that bootc always writes to one of:

A newly initialized root filesystem, where default labeling rules in the kernel take effect
An externally provisioned filesystem, where we assume this was done correctly

osbuild however makes a temporary root and then copies it, and I believe that's the source of the problem.
(I still don't understand why we don't default to writing directly to the target root filesystem and only offer "construct temporary tree" as a debugging aid, because doing it directly is WAY more efficient)

So I did https://github.com/containers/bootc/pull/290 but this won't help bib until it uses bootc install to-filesystem.
This...might help when run in the osbuild pipeline, or it might not.  I'm not yet sure until we can look at the details of how bib calls bootc here, and how some of the files are laid out which I am not yet sure of.
I think the most relevant thing going on here is the VOLUME /store gets us a temporary xfs filesystem tree on the host, but labeleled container_file_t (because normal selinux rules would block anything else).  But we should be able to happily make that root_t (and anything else we need).  I do still think it'd make sense to write to the real target filesystem by default, but if the above plus using bootc install to-filesystem doesn't fix it, then we can just probably hack this with a chcon -t root_t /store.


Flyweight pattern without DOM details

Can you build an implementation of zoo with flyweight model on top of this?
I will send another PR with flyweight DOM

Hey, thanks for the suggestion. However, I just created the Flyweight pattern here. You can review it and check if anything is wrong. Thanks again @srameshr

Constructor pattern already updated here. Closing.


Support for card.brand?

Not needed - this is a returned value, not an input to creating a payment method


Balance stuck at 0

Despite numerous confirmations lbrynet sees the account as having 0 balance running 0.7.5
user@Anastasia ~/.lbrynet # lbrynet-cli get_balance
0.0
user@Anastasia ~/.lbrynet # lbrynet-cli get_transaction_history
[{"confirmations": 452, "date": "2016-11-04 08:11", "label": "", "timestamp":<PHONE_NUMBER>, "txid": "36b5e81812c597e7915243359db18add14b0b3892d0f9fd533de84a282d3f8b0", "value": 19.94}]
user@Anastasia ~/lbry # git rev-parse HEAD
fe7700d726dfa034969e8b15f793468edaf235e6

Would you mind sending us your log file located at ~/.lbrynet/lbrynet.log to<EMAIL_ADDRESS>?
My suspicion is that the balance is stuck as reserved for some reason.

Recent log sent

Is #250 relevant here perhaps
~/.lbrynet/lbryum.log is 0 bytes on my system, could that be taken to assume lbryum is failing to start properly?
Although, then I would expect get_transaction_history and get_latest_blockhash to fail but they're both correct.

No, it looks like your wallet is connected loading fine.
Have you made any publishes ? Amounts used for publishing are not included in balance
You can check this by running "lbrynet-cli get_name_claims"
You can also install and run lbryum directly https://github.com/lbryio/lbryum without lbry , which should give you the correct balance.

I have not published anything yet.
I deleted my old installation, cloned master as of 0.7.5, generated a bunch of addresses by clicking the button in ?wallet page, sent coins from Polo, waited.
user@Anastasia ~ # lbrynet-cli get_name_claims []

Installing lbryum as a standalone app, it does correctly interact with the wallet including showing the balance and sending coins.
Updated lbrynet again, still 0 balance
user@Anastasia ~/lbry # git rev-parse HEAD
0abc081edc9a827374f1336bfa71f2738bf3a03e

Responded to email with further information.

@bitspill is this still a problem?

Unfortunately, yes.
lbrynet-cli get_transaction_history
[
  {
    "confirmations": 13351,
    "date": "2016-11-04 08:11",
    "label": "",
    "timestamp":<PHONE_NUMBER>,
    "txid": "36b5e81812c597e7915243359db18add14b0b3892d0f9fd533de84a282d3f8b0",
    "value": 19.94
  },
  {
    "confirmations": 9589,
    "date": "2016-11-11 08:08",
    "label": "",
    "timestamp":<PHONE_NUMBER>,
    "txid": "a5c04597beab08c5af7876bec0d360979b5a605fc82c205bd5794d5079e37a69",
    "value": -0.000113
  }
]

~/lbry # lbrynet-cli get_balance
0.0

~/lbry # git rev-parse HEAD
9140c95a0cbdcd09d2043c8f10848945f56db4c1

@kaykurokawa can you look at this?  This seems like a high priority bug.

Not sure which commit fixed it but I can now see my balance after updating today.
~/lbry # git pull
-- SNIP --

~/lbry # git rev-parse HEAD
13d74d1f7660c488a98284358d645bf09f7527df

~/lbry # pip install -r requirements.txt --upgrade
-- SNIP --

 ~/lbry # lbrynet-cli get_balance
10.0

thanks for the followup
On Fri, Dec 2, 2016 at 2:21 PM, bitspill<EMAIL_ADDRESS>wrote:

Closed #248 https://github.com/lbryio/lbry/issues/248.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lbryio/lbry/issues/248#event-880529835, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ACRRX5ArfdcHkTBWmW8nwmqWdvVjdqmDks5rEH3VgaJpZM4KqJ4d
.


add type = year to mat-datetimepicker

Hi, thanks for the great lib!
Any chance there could be another type added, where the user can just select a year?
Cheers.

I made the pull request #103 to add view for choosing year.

released in 4.1.0.


Graph freezes or breaks upon removing links

Basically the title, I think I might be doing it wrong since you seem to have done this in your exmaple.

I seem to have solved it, the issue was that there was a gap in the numbering of node or link id's

Actually that didn't seem to fix it, just made it happen less. To give some more detail:
I have a function that I want to delete many nodes, it also needs to go through and delete their attached links. I'm doing so by constructing new links / edges arrays and then assigning them.
This process works sometime but other times I get something like this:
[Vue warn]: Error in callback for watcher "netLinks": "Error: missing: 9"
Its always referring to an id that's missing from nodes, but I can't seem to figure out why it wants that id to be there, or how to correctly remove items from the links/nodes arrays.

Here is where I implemented the deletion:
https://github.com/JPWeir/Graf/blob/master/Vue/graf/src/graf_tools.js
Its very hacky, originally I was just splicing items out of the arrays. I got to this point after alot of trial and error as well as looking at your example.

yea im dumb

Hi I think have the same issue as you, basically have to remove a bunch of links but by using splice the wrong link gets removed sometimes. I think the problem is with the .index property not updating quickly enough when many links are removed. I went ahead and reproduced your code below for context, which is very similar to mine. Were you able to figure this out @N-Desmarais ?
removeSimLink(link_id) {
        // find index of link_id and splice
        let index = this.links.findIndex((link) => { link.id = link_id });

        this.links.splice(index, 1);
    }

Hey,
I fixed this a while back so I don't remember 100% but I believe you need to reassign the entire node or links array.
Emilio doesn't seem to support this anymore and I've opted to use d3-force instead of this wrapper I recommend you do the same.

Thanks for replying @N-Desmarais, and yes I just reasigned the entire links array using the filter method and words fine. I'd use d3-force but there's still a lot of functionality that this project already abstracted away from me. But I might reconsider in the future.


Clear screen feature request

In cargo watch you have the -c option that clears the screen on a new build.
Having this option can help when doing a large refactor and you have many errors that sometimes it is hard to see where the recompilation started.

Makes sense! I'd welcome a PR for this.

@ctron Can you point me into the right direction where I could add this in the codebase?

@ctron Just added the PR #886

Merged it. Many thanks. I'll do another rc release. And maybe that's it for 0.21.0 :crossed_fingers:

Thanks, happy to have this in for the next release.

@ctron I just want to mention to update the release note about the new feature.


Adb get_devices doesn't work on Windows

get_devices doesn't work, it returns an empty dictionary.
If I use adb.run_cmd("devices"), then it works.
This only happens on a Windows Machine, on my Mac it works.
Found out the problem was that the output from adb uses \r for line ending while the pyand library separates the list with \n

Here is my rewrited function:
def get_devices(self):
        """
        Return a dictionary of connected devices along with an incremented Id.
        adb devices
        """
        error = 0
        #Clear existing list of devices
        self.__devices = None
        self.run_cmd("devices")
        print "Output:", self.__output
        device_dict =  {}
        if self.__error is not None:
            return None
        try:
            n = 0
            output_list = self.__output.split("\n")
            for line in output_list:
                pattern = re.compile(r"([^\s]+)\s+device$")
                device = pattern.findall(line)
                print device
                if device:
                    device_dict[n] = device[0]
                    n += 1
                #endif
            if len(device_dict)==0:
                print "device list quickfix \r"
                output_list = self.__output.split("\r")
                print "output list:", output_list
                for line in output_list:
                    print "line: ", line, type(line)
                    pattern = re.compile(r"([^\s]+)\s+device$")
                    device = pattern.findall(line)
                    print device
                    if device:
                        print "device found: ", device
                        device_dict[n] = device[0]
                        n += 1
                        # endif
        except:
            self.__devices = None
            error = 1
        self.__devices = device_dict
        return self.__devices

Thanks for reporting this. I didnt really test anything on Windows at all so Windows-related issues were bound to exist.
Ill verify your change and commit it. Alternatively, you can create a pull request.
Cheers

I did a pull request, please have a look:
https://github.com/Zyg0te/pyand/pull/4

Can u add this for windows, I really love this library and need the change for my script.
import platform
def get_devices(self):
"""
Return a dictionary of connected devices along with an incremented Id.
adb devices
"""
error = 0
#Clear existing list of devices
self.__devices = None
self.run_cmd("devices")
print "Output:", self.__output
device_dict =  {}
if self.__error is not None:
return None
try:
n = 0
if platform.system().lower() != "windows":
output_list = self.__output.split("\n")
else:
output_list = self.__output.split("\r")
for line in output_list:
pattern = re.compile(r"([^\s]+)\s+device$")
device = pattern.findall(line)
print device
if device:
device_dict[n] = device[0]
n += 1
except:
self.__devices = None
error = 1
self.__devices = device_dict
return self.__devices

@SacrilegeTx Thanks for the feedback and apologies for the late response. Ive committed a fix for this and will be merging it now. Hope it works.


Other packages support?

Hi and thanks for the amazing work,
We are trying to use Diderot for the next semester, wondering if the XML compiler can support two other LaTex packages namely linguex and tipa for better involving linguistic symbols? Or, are there any other efficient way to incorporate those two packages?
Thanks,

Hi Jiaqi, let's discuss this over email.  Could you please email me?


Simon

This is a 2x2 version of the game "Simon". Basically, tiles will light up in a specific order which you then have to recreate. The goal is to copy the pattern correctly for as long as possible. When you mess up, your score will appear briefly and a new game will start. Highest score possible is 99, higher than that and it will not be able to display your score properly.

Very good game! It's fun!


bug fix

There was an incorrect order of writing variables

Can you also please add the changes for a 1.0.6 because 1.0.5 was released yesterday :-(


Add API automation tools for JavaScript, Ruby

Add a page on using API automation, similar to the one on browser automation.
For JVM:

Karate
RestAssured
other?

What are API automation tools for Ruby, JavaScript?

RubyMine van be used to test REST APIs: https://www.jetbrains.com/help/ruby/testing-restful-web-services.html

I use curb in my testing.
Ruby has a default http library called Net/http, but the common ones other people use are things like faraday, there's probably I'd say about 6 main ones.
HTTPClient
RestClient
Curb
Faraday
Net/Http
HttpRB
A bigger list is here: https://www.ruby-toolbox.com/categories/http_clients

Thnx @luke-hill - do you feel up to making a PR to add them?

I'll have some free time next weekend. I'll try chip in something then.

That would be great @luke-hill!


Cerebral boilerplate is broken

Uncaught TypeError: Cannot read property 'call' of undefined

Hm, this does not happen on my end? Did you do something first? It seems to be in regards of loading up the vendors bundle. That error appears when things are not loaded correctly.
It might be because you have the old version of the bundle. I had to make some changes to it. So clear your cache and try again :)

Still the same error.
http://pastebin.com/rDnevEy2

It was cache stuff. Works now.

Great! :+1:


setStartTimeBasedOnType is unused?

This method is in app/models/calendar but I couldn't see it being used anywhere in the code.

Hi @mcfiredrill, sorry for such long response.
I've stopped updating this project while ago and left some unused code and unfinished stuff.
I can't find that method too.
Any success with using this fork?

hi @marzubov ! I've been using your day/month view code, and tried to update the addon to work with the latest version of ember in my fork https://github.com/mcfiredrill/ember-calendar
There are still a few bugs to work out but mostly I've got it working.

It's good to hear that it's useful for someone :)
Please feel free to contact me if you have any further questions.


node regression

Hi, i am experimenting some of my own data, and I think it is relevant to your description about "node regression" setting, but I am not so sure.
So as I understand, (correct me if I am wrong.), take mnist experiment as example,
Each sample feed into the network is a digit image, conveted to a graph with 28x28 nodes.
The goal is to classify this entire graph to a label, say, 8.
What I am looking for is that, I have my own data which is a bigger graph, and there is a value or a vector of values on each node.
And i am thinking if it's possible to:

given a node, only feed in it's neighbors into network
the corresponding output of this node input is it's associate value.
I think it is more like I want to use a subgraph as training....

I am not so sure if this is the same as you mentioned in the usage.ipynb node classification/regression..
Do you have any hint or suggestion of how to do that?
Thx in advance~!

The task for MNIST is not to classify a graph (the 28x28 nodes grid is the same for all images) but to classify a graph signal. In this context the graph signal is the pixel values. The graph is structuring the pixels, i.e. defining pairwise relationships between them, and is fixed.
Your usage definitely fits in the node classification/regression regime. The code would however have to be adapted, I have nothing fully ready for this usage yet. Please contact me at<EMAIL_ADDRESS>if you're interested in doing that.

Hi thx, let me send a mail to you! :)

@jdily Hi, I have the same question as you, do you have any progress yet? Maybe you could give me some help~


Describe an alternative to the .json based generated code in psa-driver-interface.md

Description

Type: Enhancement Request
Priority:  Minor

Enhancement\Feature Request
Justification - why does the library need this feature?
In the documentation (mbedtls/docs/architecture/psa-driver-interface.md) the driver structure is defined by a “.json” file as input to “make”, for example:
“make PSA_DRIVERS="/path/to/acme/driver.json /path/to/nadir/driver.json" lib”
But it should exist another way.
Suggested enhancement
It's good to mention or describe an alternative way, for make-less IDEs like IAR, Keil etc., via a C glue layer instead of the .json based generated code.

Hi @AndreyButokNXP . Thanks for the suggestion. There is already a thread about this proposed interface on the Mbed TLS developer mailing list:
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-May/000087.html
Given that this proposed interface is not yet merged, it's better to make suggestions like this as responses to that thread rather than in this issue tracker.

OK, but the e-mail mailing list is very inconvenient to follow up. Adding comments to a pull request is OK, but it's a temporary solution.
Guess, better to use the one access point for mbedTLS issues, tasks and improvements.

When the proposed interface is stable enough to be merged, this issue tracker will be the right place to track specific issues. Until then, we prefer more dynamic discussion on the list.

OK

Hi Andrey,
The current plan is that the interface with a JSON file will become a PSA specification. In Mbed TLS, we'll also document a C level API, so that you can write glue code by hand.
Note that if you're distributing an IDE for a specific board with a predefined set of drivers, you can distribute the generated file.


Update README.md

typo in example

Thanks—I'll take a look at this soon.

I'm not seeing this behavior in version 3.16.0:
const humanizeDuration = require('humanize-duration')
humanizeDuration(22140000, { conjunction: ' and ' })
// => '6 hours and 9 minutes'

Am I missing something or are you on an older version?

@delikatessa Any updates here?

Closing this because I haven't heard back in several months. Feel free to comment and I can reopen.


Is this project still active?

Looks super cool, but the website says "Coming soon!" for some things and there were no updates for over 2 years. :smile:

I had the same question. Just built a starter setup...great instructions and models. I had some things I thought I could contribute... I made SVGs for laser-cutting the plexi formicarium lids, was thinking of re-designing the screw-holes to support brass inserts, and making new connectors for larger test tubes. Would be happy to contribute back, if maintainer is still tracking the project.

I'm active here, but less so on this project. I keep the repo open though, anyone is welcome to contribute.
I've freed my colonies as well, so I don't have any active colony to test things anymore!

Weird! This is a pretty cool project, I'll start printing mine and hopefully at some point will be able to contribute as well

Excellent, @schemen! I've already got some local additions (new connector sizes, SVGs for laser-cutting acrylic lids, etc.) but am currently working on making an outworld that's compatible with the system. I'll submit some PRs once I have everything up and tested.
Thanks again for putting this nice setup out there in open source, and providing FreeCAD models of everything. It's been very helpful, even though I'm still a novice with FreeCAD.


Ft authentication setup #37519892

Description

Created Authentication Setup and User signup with email verification feature

Why

A User should be able to create a new account on the application using this endpoint

Acceptance Criteria
GIVEN A user navigate to  api/v1/auth/signup route
WHEN A user provide/meets signup requirements
THEN A User should receive a 200 status message with the object:

{
    "status": "success",
    "data": {
        "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6Mywicm9sZSI6ImFkbWluIiwiaWF0IjoxNTg5MTA1MjgzLCJleHAiOjE1ODkxOTE2ODN9.XqHEcMCGEmoZn6YReDYPDB3RXBMjdyIYhjVe6TPW0P0",
        "firstname": "Rasak",
        "middlename": "Agbolade",
        "lastname": "Adeniyi",
        "userType": "whole saler",
        "role": "admin",
        "email"<EMAIL_ADDRESS>        "phone": "7031059595"
    }

What are the relevant project stories(issues)?
https://github.com/BuildForSDG/team-010-backend/issues/2
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented on my code, particularly in hard-to-understand areas
[x] I have added necessary inline code documentation

Hi bro, codacy has linting issues on your PR, your could also do is run npm run lint on your local machine to find all the linting issues

@rozay10 nice work, do a fix on the test script by adding  npx sequelize-cli instead of just sequelize it


[Leaderboard] Optimise loading of github user avatar image

Fixes #869
Note: the values 54px and 178px are taken from the size of the image component.
Acc no: c54c04774efaae20746fd3f29cdd619fea512e119bc1082b863572b2e8844104
Note: progress ongoing

Closing as there is an existing PR solving the same issue #942


[Feature Request] Can SMP RP2040 demo core0 and core1 both run freertos?

Hi,
I want to know whether multiple cores can run FreeRTOS at the same time. If yes, how to modify RP2040 demo to support this. Thanks.
From SMP demo RP2040, only one core run FreeRTOS.
FreeRTOS-SMP-Demos/FreeRTOS/Demo/CORTEX_M0+_RP2040/README.md
### Multicore Demo
The multicore demo application runs FreeRTOS tasks on one core which interacts
with the code running on the other core using Raspberry Pico SDK synchronization
primitives. There are two versions of the same demo - One version runs FreeRTOS
on core 0, the other runs FreeRTOS on core 1.

Hi @thomas-coding
As in each core runs a single-core FreeRTOS, or rather that both core participate in running the scheduler?

Hi dachalco,
I don't want to run pico SDK,  I want core0 and core1 both running FreeRTOS task at the same time, but not just signle-core FreeRTOS, I think its called "SMP", only one scheduler, and can assign task to core0 or core1 according to some rules. like there are three task (task1, taks2, task3). All these task is ready for run. After scheduler start, scheduler assign task1 to core0, and core0 running task1. scheduler assign task2 to core1, and core1 running task2. Then after a while, task1 enter the block state. scheduler can assign task3 to core1.
Can now support this? If yes, how to modify RP2040 demo to support this.
Thanks.

Hi,
I studied the code and made some attempts. It's OK now.
It need create new demo, copy OnEitherCore to OnDualCore, and mainly change is:
FreeRTOS/FreeRTOS/Demo/CORTEX_M0+_RP2040/OnDualCore/FreeRTOSConfig.h
#define configNUM_CORES                         2

Define two core both running FreeRTOS
FreeRTOS/FreeRTOS/Demo/CORTEX_M0+_RP2040/OnDualCore/main.c
//    multicore_launch_core1(prvCore1Entry);
//#if ( mainRUN_FREE_RTOS_ON_CORE == 0 )
    prvLaunchRTOS();
//#else
//    prvNonRTOSWorker();
//#endif

Not start core1 here because running on both core case, when core0 start scheduler, it will launch core1 .
Core1 running RTOS.

Close


Watch input before adding tag

Hi all! Maybe i haven't dig anouth, but can anyone answer me :  is there any convinient way to watch user input before adding tag? I'll try to explain: i have two separate blocks - search string, where is placed "ng-tags-input" perfect directive, and few blocks below, each has it own tags input, with its own model. When user typing in search string, last tag in that lower blocks should updated in real-time. I have made this work earlier, then search string was just a string: but now i was asked to add tags in this search string too, and faced with this problem. I need just change event and value from input, but it looks like not so easy, as it sounds. Only way, i can see now, it use good-old jQuery, but.. ) May be, there is a way to solve it using $scope?

JS
`var mod=angular.module("myApp",["ngTagsInput"]);
mod.controller("MyTags",AddTags);
function AddTags($scope){
console.log("Tags app has started");
$scope.tags=[];
$scope.addSearch=function(){
console.log("So tags we have is = "+$scope.tags);
$scope.tags.push({text:$scope.customTags});
}
}`
HTML

					<input type="text" ng-model="customTags"/><button ng-click="addSearch()">Search</button>

 Your recent search Sir,

					<tags-input ng-model="tags" ></tags-input>

This issue was selected to be spring-cleaned by a script. More information can be found here.
If anyone thinks this was a mistake and this issue should be reopened, please leave a message below explaining why. Before doing so, please consider reading the CONTRIBUTING file.


create workflow for reporting/resolving bugs

Edit templates for issues and create branch from master and auto merge changes to dev.

moved to #27


Add another empty column

A minor bug fix. In https://github.com/liampshaw/mcroni/commit/89cb8c9d24ca3bd5120765305cb4bb2d8b1634e4 and additional column was added, but the number wasn't incremented for the non-hits.
This PR just increases the number so all the outputs will play nicely with csvtk
Cheers,
Robert

Good catch - thanks!


Body is not defined after updating ejs from v0.8.4 to v2.3.3

I want to  enable dynamic includes (from variables) in ejs so I upgraded ejs to 2.3.3 after that this issue is showing
/views/layout.ejs:3
    1| <% include  templates/partials/header %>
    2|
 >> 3| <%- body %>
    4|
    5| <% include  templates/partials/footer %>

body is not defined
    at eval (eval at <anonymous> (/xxx/ejs/lib/ejs.js:464:12), <anonymous>:18:16)

Is there any workaround for this issue

I've made a workaround but you need to replace the res.view file in the views hooks with this code: https://github.com/Josebaseba/sails/blob/a1a7137a7edf25a419fdc6a2d3be8ababa5b8941/lib/hooks/views/res.view.js
Or add all this hook into /api/hooks/views and it should overwrite the sails core hook for that one.

@Josebaseba Do I need to install express also for this change?
error: Sending 500 ("Server Error") response:
 Error: Cannot find module 'express/lib/response'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at ServerResponse.res.view (/xxx/myApp/api/hooks/views/res.view.js:319:28)

I am getting this error on loading the view.

I have tried <%- include(somePath) %>. It is also not seems to work I got the following error
error: Sending 500 ("Server Error") response:
 Error: ENOENT, no such file or directory '/xxx/myApp/views/('test.ejs')'
    at Error (native)
    at Object.fs.openSync (fs.js:500:18)
    at fs.readFileSync (fs.js:352:15)
    at Object.exports.parse (/xxx/myApp/node_modules/ejs-locals/node_modules/ejs/lib/ejs.js:159:19)
    at exports.compile (/xxx/myApp/node_modules/ejs-locals/node_modules/ejs/lib/ejs.js:224:15)
    at Object.exports.render (/xxx/myApp/node_modules/ejs-locals/node_modules/ejs/lib/ejs.js:284:10)
    at Object.exports.renderFile (/xxx/myApp/node_modules/ejs-locals/node_modules/ejs/lib/ejs.js:318:20)
    at module.exports [as engine] (/xxx/myApp/node_modules/ejs-locals/index.js:85:7)
    at View.render (/xxx/myApp/node_modules/sails/node_modules/express/lib/view.js:76:8)
    at Function.app.render (/xxx/myApp/node_modules/sails/node_modules/express/lib/application.js:523:10)
    at ServerResponse.res.render (/xxx/myApp/node_modules/sails/node_modules/express/lib/response.js:827:7)
    at cb (/xxx/myApp/api/hooks/views/res.view.js:331:15)
    at /xxx/myApp/node_modules/ejs-locals/index.js:134:7
    at Object.exports.renderFile (/xxx/myApp/node_modules/ejs-locals/node_modules/ejs/lib/ejs.js:318:3)
    at module.exports [as engine] (/xxx/myApp/node_modules/ejs-locals/index.js:85:7)
    at View.render (/xxx/myApp/node_modules/sails/node_modules/express/lib/view.js:76:8) { [Error: ENOENT, no such file or directory '/xxx/myApp/views/('test.ejs')']
  errno: -2,
  code: 'ENOENT',
  path: '/xxx/myApp/views/(\'test.ejs\')',
  syscall: 'open' }

@Josebaseba thanks for sharing your solution
@jetsonjohn As far as I know, what you're trying to do is achievable today using partials.  Am I missing something?

@mikermcneil Yes that will work. Thanks

@jetsonjohn :+1:


E 0:00:01:0253   MainLoop.gd:57 @ _on_save_button_pressed(): Condition "!is_ancestor_of(p_node)" is true. Returning: false   <C++ Source>   scene/main/node.cpp:2302 @ is_editable_instance()    MainLoop.gd:57 @ _on_save_button_pressed()

Godot version
Godot_V4.1.1 Stable
System information
Pop OS, Intel(R) Core(TM) i5-1035G1 , Intel UHD Graphics 620, Driver Version <IP_ADDRESS>, Vulkan 1.3.246
Issue description
On this code:

I am receiving this error:

Scene tree:

Steps to reproduce
Trying to pack a node and its children in a scene:

With this code:

Minimal reproduction project
ANT-ItemCreator.zip

Actual minimum reproduction:
SaveBugn't.zip
This isn't a bug, but it is weird that you can't add a node to packed scene while it's in the scene tree. Does this have something to do with the node itself holding parentage information?
Regardless, this is easily worked around by doing packed_scene.pack(save_file.duplicate())

Hi. This is indeed happening to me too and the workaround proposed by @SomeSortOfSam doesn't seem to help.
If I understood correctly, the duplicate() is there to have a copycat of the node, out of the scene tree, right?

Hi. This is indeed happening to me too and the workaround proposed by @SomeSortOfSam doesn't seem to help.
If I understood correctly, the duplicate() is there to have a copycat of the node, out of the scene tree, right?

Yes I was unable to get it to work with duplicate(). I am confused because this worked in 4.0 when it came out. This also worked in 3.4.3 which is the last version I was using of 3.0.

Disregard close. Accidental click.

Yes I was unable to get it to work with duplicate(). I am confused because this worked in 4.0 when it came out. This also worked in 3.4.3 which is the last version I was using of 3.0.

duplicate() isn't working for me neither. I think I stumbled onto another thread some days ago, talking about a regression in Godot 4.0 that was fixed so maybe this is still the case?
If I can find it again, maybe it can be applied to 4.1 or give some clue...

 It applies to my case but this may help something else, so I'm leaving this here.
Before getting into the details: I'm pretty sure this error is a regression but I can't find the thread that talked about this.
This error is not actually hindering the ability to pack the element, but it complains about wrong ownership (at least in my case).
The starting situation is this: I have those "Props" elements which are instance of scenes already saved externally. Some of those nodes have a polygon attached to react to clicks.

The polygons are children of the nodes I want to save but owned by the root scene.
My solution is to remove the offending children on the fly and reassigning them to the proper parent afterwards. The following code is in a loop (on Props.get_children()) and it account a bit for other possible children that I may want to add in the future.
	var packed_scene: PackedScene = PackedScene.new()

	# Workaround starts here #################
	var not_owned_children = []
	for child in prop.get_children():
		if child.owner == prop: continue    # do nothing if the child is owned by its parent

		not_owned_children.append(child)     # add the not-owned child to a list
		child.get_parent().remove_child(child)   # Unparent it

	packed_scene.pack(prop)   # pack the node that's now clean
	ResourceSaver.save(packed_scene, prop.scene_file_path)

	# Workaround restarts here
	for child in not_owned_children:
		prop.add_child(child)    # Reassign the child where it belongs

This does the trick for me, but I will do more research in the next days because this is terrible and I'm sorry with my mom.
Hope this may help someone else in the meantime.

I have a very scuffed save/load concept I am trying to hack out at 1:30am. Mistakes were made here and I don't think I'm in a position to blame the engine devs. But I ran into this same issue. I have a manually instantiated node being added as a child to another node, the owner of the node is null. Nodes that are added under this parent in the scene editor (e.g. before runtime) work fine, it's just the nodes added at runtime that have this issue. And so, inevitably, the pack function throws and error and gives up. Luckily these are all direct children, so this workaround should get it done. I'll edit my comment when I've tested it.


Installing SDK 6.0 on Ubuntu 22.04 installs the runtime only

[Enter feedback here]
output from wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
`--2022-08-15 10:44:05--  https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb
Resolving packages.microsoft.com (packages.microsoft.com)... <IP_ADDRESS>
Connecting to packages.microsoft.com (packages.microsoft.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3692 (3.6K) [application/octet-stream]
Saving to: ‘packages-microsoft-prod.deb’
packages-microsoft-prod.d 100%[==================================>]   3.61K  --.-KB/s    in 0s
2022-08-15 10:44:05 (1.40 GB/s) - ‘packages-microsoft-prod.deb’ saved [3692/3692]
`
output from sudo dpkg -i packages-microsoft-prod.deb
(Reading database ... 204700 files and directories currently installed.) Preparing to unpack packages-microsoft-prod.deb ... Unpacking packages-microsoft-prod (1.0-ubuntu22.04.1) over (1.0-ubuntu22.04.1) ... Setting up packages-microsoft-prod (1.0-ubuntu22.04.1) ...
output from sudo apt-get update && \   sudo apt-get install -y dotnet-sdk-6.0
Hit:1 https://packages.microsoft.com/ubuntu/22.04/prod jammy InRelease Hit:2 http://apt.pop-os.org/proprietary jammy InRelease Hit:3 http://apt.pop-os.org/release jammy InRelease Hit:4 http://apt.pop-os.org/ubuntu jammy InRelease Hit:5 http://apt.pop-os.org/ubuntu jammy-security InRelease Hit:6 http://apt.pop-os.org/ubuntu jammy-updates InRelease Hit:7 http://apt.pop-os.org/ubuntu jammy-backports InRelease Reading package lists... Done Reading package lists... Done Building dependency tree... Done Reading state information... Done dotnet-sdk-6.0 is already the newest version (6.0.400-1). 0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.
output from dotnet --info
`global.json file:
Not found
Host:
Version:      6.0.8
Architecture: x64
Commit:       55fb7ef977
.NET SDKs installed:
No SDKs were found.
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.8 [/usr/lib/dotnet/dotnet6-6.0.108/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.8 [/usr/lib/dotnet/dotnet6-6.0.108/shared/Microsoft.NETCore.App]
Download .NET:
https://aka.ms/dotnet-download
Learn about .NET Runtimes and SDKs:
https://aka.ms/dotnet/runtimes-sdk-info`

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

ID: 80707602-f283-e796-d3b8-3287fbc011dc
Version Independent ID: 1d732b15-9e64-633a-000c-ad96d9d3818a
Content: Install .NET on Ubuntu - .NET
Content Source: docs/core/install/linux-ubuntu.md
Product: dotnet
Technology: dotnet-install
GitHub Login: @adegeo
Microsoft Alias: adegeo

I am facing the very same issue. Any workaround for that?

https://docs.microsoft.com/en-us/dotnet/core/install/linux-scripted-manual#manual-install
worked for me

This has been in transition to be included in the official Ubuntu feeds: https://github.com/dotnet/core/issues/7699
Docs update is in progress.


FINOS Tailored Git and GitHub Training

Description of Problem:
Developing and distributing FINOS specific/tuned Git/Github101 training has come up a few times. Programs that have suggested this be done include FDC3, FO, and DT (specifically the Kdb WG).
This epic is to capture those requirements so the ODP WG, FDX program and FINOS community can assess if Git/GitHub 101 training is something to take on, develop, distribute and deliver.
There is a draft/scratch pad, which @mcleo-d, @jbjonesjr and the ODP team has access to in FINOS.
As some have pointed out, there is a lot of good Git/Github training already, but the feedback we've received is that it would be good to have training material that is tuned to FINOS, FINOS processes, and FINOS tooling that includes examples and screenshots of FINOS tools such as Travis CI and CLA Bot.
Potential Topics:

Source Control 101
How Git is different from SVN, CVS, and other "traditional" tools
Basic concepts: Commits, Forks, Pull Requests, Etc.
Using Github interactively (and comparison with doing stuff at command prompt)
Github 101
Markdown 101
FINOS CLAs, the CLA Bot, and the FINOS Metadata model
The FINOS project blueprint
Using Github projects/using github for a kanban board
Using Github as a wiki
Github Pages 101, Docusaurus, and the FINOS microsite template

Examples of Git/Github training we might be able to leverage

Harvard CS50 Git/Github training
Git SCM

Stories

[ ] Refine list of training topics and set ToC on github.com/finos/open-developer-platform GitHub Pages
[ ] Organize quarterly training sessions via ODP meetings
[ ] Run first training session
[ ] Update ODP GitHub pages with training content (after first training session)

More history on https://finosfoundation.atlassian.net/browse/ODP-103

Closing this issue for now, as there haven't been updates on it since a long time.
There is a good amount of documentation that can be found on https://community.finos.org


Build failed after upgrade to 3.3.2 with a category.json contain slug attribute

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Prerequisites

[X] I'm using the latest version of Docusaurus.
[X] I have tried the npm run clear or yarn clear command.
[X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
[X] I have tried creating a repro with https://new.docusaurus.io.
[X] I have read the console error message carefully (if applicable).

Description
After I upgrade to 3.3.2, my website start to build failed.
I find that if my docs has routeBasePath: '/' in docusaurus.config.js and a category.json have "slug": "/" it will have error.
Please help thanks!
Reproducible demo
https://github.com/antoniohou/Docusaurus-Test
Steps to reproduce

Create website with command npx create-docusaurus@latest my-website classic
Delete src/pages/index.js
Add routeBasePath: '/' in docs in docusaurus.config.js
Add "slug": "/" in docs\tutorial-basics_category_.json

Expected behavior
Build success.
Actual behavior
Build failed.
Your environment
No response
Self-service

[ ] I'd be willing to fix this bug myself.

Thanks, yes it is a conflict in the generated filenames that only happens for this very specific case.
Will be fixed in https://github.com/facebook/docusaurus/pull/10131


Makefile: try to install clang-tidy package explicitly

Commit 43f1389 ("Makefile: enable clang-tidy in presubmit tests") added clang-tidy to only tools/docker/env/Dockerfile file.
We should try to explicitly install clang-tidy in Makefile for those who don't use docker.

I made this commit because docs/contributing.md says
Run tests locally (make install_prerequisites followed by make presubmit).
and "make presubmit" failed due to lack of clang-tidy command. After applying this commit, "make presubmit" survives up to start testing on current kernel.
But it is annoying that current kernel crashes during "make presubmit" because I don't mean to crash current kernel; I just want to confirm that I'm following right steps for making pull requests. Is there a better command instead of "make presubmit" ?
[  640.060691] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command "SVGA_3D_CMD_BIND_GB_SURFACE" causing device error.
[  640.061640] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command buffer offset is 0
[  640.062141] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command size is 16
[  640.113796] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command "SVGA_3D_CMD_DESTROY_GB_SURFACE" causing device error.
[  640.118213] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command buffer offset is 0
[  640.120093] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command size is 12
[  640.123028] BUG: unable to handle kernel NULL pointer dereference at<PHONE_NUMBER>000030
[  640.124918] IP: vmw_otables_takedown+0x66/0x100 [vmwgfx]
[  640.126716] PGD<PHONE_NUMBER>d31067 P4D<PHONE_NUMBER>d31067 PUD 133712067 PMD 0
[  640.128524] Oops: 0000 [#1] SMP PTI
[  640.130324] Modules linked in: nfc llc2 hci_vhci fcrypt pcbc rxrpc pptp gre l2tp_ppp l2tp_netlink pppoe pppox pn_pep phonet xfrm_user nfnetlink crypto_user l2tp_ip6 l2tp_ip l2tp_core ip6_udp_tunnel udp_tunnel af_key xfrm_algo kcm ipx p8023 psnap p8022 llc smc sctp dccp_ipv6 dccp_ipv4 dccp can_raw can_bcm can caif_socket caif rfcomm hidp cmtp kernelcapi bnep bluetooth ecdh_generic af_alg vhost_net tap vmw_vsock_virtio_transport_common vhost vfio_iommu_type1 vfio userio uhid hid snd_seq snd_seq_device snd_timer snd soundcore cuse vmw_vsock_vmci_transport vsock binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel vmw_balloon joydev input_leds intel_rapl_perf serio_raw shpchp vmw_vmci mac_hid sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
[  640.141519]  ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear aesni_intel aes_x86_64 crypto_simd vmwgfx cryptd glue_helper psmouse ttm drm_kms_helper syscopyarea sysfillrect ahci e1000 libahci sysimgblt mptspi fb_sys_fops mptscsih drm mptbase scsi_transport_spi i2c_piix4 pata_acpi
[  640.147905] CPU: 1 PID: 8961 Comm: host.test Not tainted 4.15.0-112-generic #113-Ubuntu
[  640.149266] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
[  640.151830] RIP: 0010:vmw_otables_takedown+0x66/0x100 [vmwgfx]
[  640.153095] RSP: 0000:ffffb9db10f6fa90 EFLAGS: 00010246
[  640.154625] RAX:<PHONE_NUMBER>000000 RBX:<PHONE_NUMBER>000006 RCX:<PHONE_NUMBER>000000
[  640.156134] RDX: ffff90ce6aa40380 RSI:<PHONE_NUMBER>000005 RDI: ffff90ce6aa00000
[  640.157467] RBP: ffffb9db10f6faa8 R08: ffff90ce6a9f54d0 R09: ffff90ce6aa00090
[  640.158746] R10:<PHONE_NUMBER>000000 R11: 00000000ffffffff R12: ffff90ce6aa00000
[  640.160064] R13:<PHONE_NUMBER>000000 R14:<PHONE_NUMBER>000000 R15: ffffb9db10f6fb8c
[  640.161312] FS:  000000c000034410(0000) GS:ffff90ce79640000(0000) knlGS:0000000000000000
[  640.162296] CS:  0010 DS: 0000 ES: 0000 CR0:<PHONE_NUMBER>050033
[  640.163083] CR2:<PHONE_NUMBER>000030 CR3:<PHONE_NUMBER>fbc003 CR4:<PHONE_NUMBER>1606e0
[  640.163898] Call Trace:
[  640.164695]  vmw_release_device_early+0x7d/0xa0 [vmwgfx]
[  640.165572]  vmwgfx_pm_notifier+0x61/0xb0 [vmwgfx]
[  640.166404]  notifier_call_chain+0x4c/0x70
[  640.167360]  __blocking_notifier_call_chain+0x4b/0x70
[  640.168276]  __pm_notifier_call_chain+0x1f/0x40
[  640.169042]  snapshot_open+0x164/0x230
[  640.169797]  misc_open+0xff/0x170
[  640.170585]  chrdev_open+0xc4/0x1b0
[  640.171322]  do_dentry_open+0x21d/0x370
[  640.172045]  ? __inode_permission+0x5b/0x160
[  640.172751]  ? cdev_put.part.2+0x20/0x20
[  640.173440]  vfs_open+0x4f/0x80
[  640.174108]  path_openat+0x6bf/0x18b0
[  640.174762]  ? __switch_to_asm+0x35/0x70
[  640.175398]  ? __kprobes_text_end+0x3dcd0/0x3dcd0
[  640.176003]  do_filp_open+0x9b/0x110
[  640.176606]  ? __check_object_size+0xc8/0x1b0
[  640.177203]  ? __alloc_fd+0x46/0x170
[  640.177757]  do_sys_open+0x1ba/0x2c0
[  640.178314]  ? do_sys_open+0x1ba/0x2c0
[  640.178853]  ? _cond_resched+0x19/0x40
[  640.179350]  SyS_openat+0x14/0x20
[  640.179851]  do_syscall_64+0x73/0x130
[  640.180310]  entry_SYSCALL_64_after_hwframe+0x41/0xa6
[  640.180789] RIP: 0033:0x4778fa
[  640.181240] RSP: 002b:000000c000093bb0 EFLAGS: 00000202 ORIG_RAX:<PHONE_NUMBER>000101
[  640.181688] RAX: ffffffffffffffda RBX: 000000c000022000 RCX:<PHONE_NUMBER>4778fa
[  640.182163] RDX:<PHONE_NUMBER>000000 RSI: 000000c0006975c0 RDI: ffffffffffffff9c
[  640.182610] RBP: 000000c000093c28 R08:<PHONE_NUMBER>000000 R09:<PHONE_NUMBER>000000
[  640.183084] R10:<PHONE_NUMBER>000000 R11:<PHONE_NUMBER>000202 R12:<PHONE_NUMBER>00015d
[  640.183529] R13:<PHONE_NUMBER>00015c R14:<PHONE_NUMBER>000200 R15: ffffffffffffffff
[  640.184001] Code: 84 24 90 cf 02 00 48 8d 14 d0 80 7a 10 00 74 db 48 83 c2 08 89 de 4c 89 e7 e8 87 f9 ff ff 83 c3 01 41 3b 9c 24 88 cf 02 00 72 cd <41> 8b 45 30 85 c0 74 7c 49 8b bd d0 01 00 00 e8 06 fc fe c9 85
[  640.185597] RIP: vmw_otables_takedown+0x66/0x100 [vmwgfx] RSP: ffffb9db10f6fa90
[  640.186194] CR2:<PHONE_NUMBER>000030
[  640.186912] ---[ end trace 7496302d24b3a81a ]---
[  640.187602] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command "SVGA_3D_CMD_DESTROY_GB_MOB" causing device error.
[  640.188858] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command buffer offset is 0
[  640.189475] [drm:vmw_cmdbuf_work_func [vmwgfx]] ERROR Command size is 12


Meta: Collaborate With AssemblyScript

Since this project has some commonality with AssemblyScript there is possibility to collaborate. This is just and idea to explore.

NectarJS also aims to preserve the dynamicity of JavaScript whereas AssemblyScript is a strict, typed subset of JS( or TS). And AssemblyScript focuses on WASM while NectarJS focuses on cross-platform binary generation. So what ideas do you have when you say collaboration?

NectarJS  back end may be a super set of the AS or TS backend. So there might be shared parts.

NectarJS transpiles JS to C++ code which is then passed to gcc or any other compiler of choice to generate the end file, whearas AssemblyScript uses binaryen to directly compile to WASM. So based on this inital observation, there is little room for collaboration until a custom transpiler for WASM is built. So let us hear from @adrien-thierry.

As @obnoxiousnerd  said, the objective of AssemblyScript is to transpile/compile a subset of TS to WASM. On way could be that AS uses NectarCPP ( https://github.com/Nectar-lang/nectarcpp ) and transpile to c++ before compiling, but i don't see any interest compared to what they are doing... If there is any other idea, it could be interesting

Perhaps:

nectar-lang can use MIT instead of *GPL.
Integration to front ends for TS, PS, CS, Elm, etc. use their compiler to transpile to JS and Nectar takes over.

@sirinath Your second point is already in the works. We have TypeScript integration done, with more coming soon(I'm thinking of working on some). Although I can't comment much on changing license of NectarCPP but I think its a good move, considering the main transpiler, NectarJS is now under MIT.

Hi, a big update will be released soon, with a lot of new stuff, better JS support (prototypes), better perf, and a lot of new features (low level binding, operator overloading ...)


Fix issue #275: Description of the changes made

Use the same Delimeter selected to output data file. #275

@mckaragoz new PR, let me know if it's all okay. Cheers.

Could you also fix the typo?

@mckaragoz type fixed too. Cheers.

Thanks 🥇


Sync everything when there are groups

Hello,
I have the following manifest:
repos:
  - dest: org
    branch: main
    remotes:
    - name: origin
      url: git@gitlab.com:vonpupp-org/org.git
    - name: https
      url<EMAIL_ADDRESS>    - name: nas
      url: ssh://nas/share/repos/gitlab.com:vonpupp-org:org.git
  - dest: org-media
    branch: main
    remotes:
    - name: origin
      url: git@gitlab.com:vonpupp-org/org-media.git
    - name: https
      url<EMAIL_ADDRESS>    - name: nas
      url: ssh://nas/share/repos/gitlab.com:vonpupp-org:org-media.git
  - dest: albertdelafuente.com-hugo-refined
    branch: master
    remotes:
    - name: origin
      url: git@gitlab.com:albertdelafuentecom/albertdelafuente.com-hugo-refined.git
    - name: https
      url<EMAIL_ADDRESS>    - name: nas
      url: ssh://nas/share/repos/gitlab.com:albertdelafuentecom:albertdelafuente.com-hugo-refined.git

groups:
  default:
    repos: []
  org:
    repos:
      - org
      - org-media

As you can see I have an "org" group which works when I sync with tsrc --verbose sync --group org -r org. Now I just added the last repo and I want to sync everything in the file. I thought of adding as default all the repos, which works, but... as I am adding more and more repos to the manifest I tend to forget to add them to the default group, so they are not part of the sync process.
I tried to use a general regex match like tsrc --verbose sync --group default -r .* but that didn't work. The behavior is "Workspace is empty", which kind of makes sense and kind of doesn't also depending on the point of view.
Possible solutions:

tsrc --verbose sync --group default -r .*. Allowing the regular expression . or .*
tsrc --verbose sync --group all (being the all name group a reserved name)
tsrc --verbose sync --all (a new flag for such purposes)

I hope it makes sense.

I think --group all makes the most sense. We already have the concept of a "default" group.
Remember that we already have '--all-cloned' which does things slightly different than what you need.
Do you want to try and send a patch ?

Sure, I can try to submit a PR probably next week.
I thing --group --all would be better since it is not ambiguous in a scenario of a hypothetical all group existing. Otherwise we would have kind of a recursive situation, which is what brought me here in the first place. Would you agree with --group --all @dmerejkowsky?


Outline not working in our project

Unity: 2020.2.3f
Pipeline: URP Version 10.2.2
I have tried to apply your Shader in a demo project of mine. Everything is working except the outline. I have imported my models into your project and everything works. When I add your demo models into my project, it doesn't.
Are there any additional requirements for the outline pass to work?
I did follow your instructions to setup the project.

You need improt ModelOutlineImporter.cs to your project.
Name model like XXX.ol
Check out Read/Write Enable in Model Setting.
See:https://github.com/Jason-Ma-233/JasonMaToonRenderPipeline#平滑法线导入工具modeloutlineimporterlegacy
------------------ 原始邮件 ------------------
发件人:                                                                                "ChiliMilk/URP_Toon"<EMAIL_ADDRESS>发送时间: 2021年2月11日(星期四) 凌晨0:32
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS>主题: [ChiliMilk/URP_Toon] Outline not working in our project (#1)
Unity: 2020.2.3f
Pipeline: URP Version 10.2.2
I have tried to apply your Shader in a demo project of mine. Everything is working except the outline. I have imported my models into your project and everything works. When I add your demo models into my project, it doesn't.
Are there any additional requirements for the outline pass to work?
I did follow your instructions to setup the project.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thank you, gonna try that. I assumed the word legacy implied this to not be necessary anymore.

I have tried setting up the ModelOutlineImporter, it does generate a new mesh with the @@@ prefix.
The outline is still not working tho :(

Just use original model，ModelOutlineImporter.cs will save the smoothness normal data in original model.
However, your situation does not look like an error caused by ModelOutlineImporter.cs.

Please check out Frame Debug ,did you have "Render Outline" Job?
意、未尽
<EMAIL_ADDRESS>
------------------ 原始邮件 ------------------
发件人:                                                                                "ChiliMilk/URP_Toon"<EMAIL_ADDRESS>发送时间: 2021年2月12日(星期五) 晚上10:25
收件人<EMAIL_ADDRESS>抄送: "意、未尽"<294257363<EMAIL_ADDRESS>主题: Re: [ChiliMilk/URP_Toon] Outline not working in our project (#1)
I have tried setting up the ModelOutlineImporter, it does generate a new mesh with the @@@ prefix.
The outline is still not working tho :(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Just use original model，ModelOutlineImporter.cs will save the smoothness normal data in original model.
However, your situation does not look like an error caused by ModelOutlineImporter.cs.

Please check out Frame Debug ,did you have "Render Outline" Job?
Also check SurfaceType,by default the outline not support transparent type,but you can change it in ToonForwardRender.cs（by changing the rendering order).
意、未尽
<EMAIL_ADDRESS>
------------------ 原始邮件 ------------------
发件人:                                                                                "ChiliMilk/URP_Toon"<EMAIL_ADDRESS>发送时间: 2021年2月12日(星期五) 晚上10:25
收件人<EMAIL_ADDRESS>抄送: "意、未尽"<294257363<EMAIL_ADDRESS>主题: Re: [ChiliMilk/URP_Toon] Outline not working in our project (#1)
I have tried setting up the ModelOutlineImporter, it does generate a new mesh with the @@@ prefix.
The outline is still not working tho :(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Just use original model，ModelOutlineImporter.cs will save the smoothness normal data in original model.
However, your situation does not look like an error caused by ModelOutlineImporter.cs.

Please check out Frame Debug ,did you have "Render Outline" Job?
Also check SurfaceType,by default the outline not support transparent type,but you can change it in ToonForwardRender.cs（by changing the rendering order).
May be check "Quality" and "Graphics" , did you set  the rendering asset that use toon forward data?
意、未尽
<EMAIL_ADDRESS>
------------------ 原始邮件 ------------------
发件人:                                                                                "ChiliMilk/URP_Toon"<EMAIL_ADDRESS>发送时间: 2021年2月12日(星期五) 晚上10:25
收件人<EMAIL_ADDRESS>抄送: "意、未尽"<294257363<EMAIL_ADDRESS>主题: Re: [ChiliMilk/URP_Toon] Outline not working in our project (#1)
I have tried setting up the ModelOutlineImporter, it does generate a new mesh with the @@@ prefix.
The outline is still not working tho :(
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.


missing handler aten::group_norm

While converting pytorch model into trt I faced error. Please guide me how to fix it.
Exception has occurred: AssertionError
missing handler aten::group_norm, available handlers: ['prim::Cons....

i got sth like this,
missing handler prim::CallMethod, availble handlers: [...
can anyone help?

Got the same one, can anybody help??

While converting pytorch model into trt I faced error. Please guide me how to fix it.
Exception has occurred: AssertionError
missing handler aten::group_norm, available handlers: ['prim::Cons....

I've got it, this might be your own function, so you have to write your own handler, according to the handlers/ops.py


Operating Systems and Browsers are 100 percent unknown

I am using git version b6b47d3bc7d0cf38745d32a3ad262bab87dbb7fe.
I tried with both my apache and nginx logs and in both cases 'Operating System' and 'Browsers' are 100% unknown. Am I missing something here? Maybe I need to enable something in apache/nginx to log this?

Sounds like a log config issue. Can you please post a few lines from your access log and the log format that you are using? Thanks

Closing this. Feel free to reopen it if needed.

It's standard apache and nginx logs. I will see that I can get an example the next time I have access.

This should do it:
log-format COMBINED

I'm having this same issue with just Apache (on Arch Linux). Uncommenting log-format COMBINED did not fix the problem. Here is my current config file. Any ideas?

@treetrnk Please comment out the log-format you are using and use the NCSA Combined Log Format:
log-format %h %^[%d:%t %^] "%r" %s %b "%R" "%u"

Make sure no other log-format lines are uncommented.

That didn't take care of it either. Everything is still showing as unknown.

@treetrnk please post/attach a few lines from your access log and I can take a look.

Here are the logs.
I originally was using the common log format, but even after switching to the format you suggested, everything is showing up as unknown.
Thanks for taking a look.

@treetrnk Assuming the first three lines were not meant to be there, I was able to run goaccess v1.2 using the NCSA Combined Log Format. This worked for me, (I got rid of the first three lines though)
goaccess sample.log --log-format=COMBINED

Here's the output


Urbit Proxy - preventing moon IP address leaking

Urbit crowd being particularly mindful of privacy issues, there is a following thing of interest regarding
current Moon architecture:
We can already hide behind our cloud planet in talk.
But there is still theoretical possibility of someone scanning our moon address space.
I did a simple experiment with tcpdump. People running ships on their home PC are "toast". Current IP geolocation services are effing good. They almost identify you to a block (to a district in my case).
If we use a moon instead, we are good, but some malicious actor could still scan our moon address space.
Most people will probably run only one or two moons. This presents significant danger wrt discovering someone real location.
Is it possible to hook up into ames on the planet and have a little command like
|hide ~mymoon
to prevent external address resolutions on ~mymoon.
Or maybe even
|proxy ~mymoon wherein all traffic to the moon would be proxied through the planet.
This could be humble beginnings of native Urbit VPN

nothing is stopping you from sending a thousand |hi's in parallel - or
well, your ISP/the parent planet might object, but that sort of detection
can be put in even in the serial case
On Tue, Mar 27, 2018 at 12:22 AM, mikolajpp<EMAIL_ADDRESS>wrote:

I should note that for now this is largely theoretical attack. At current
vere a discovery |hi takes a few seconds depending on latency. It would
take a few hundreds years to scan entire moon space.
This can become a problem once we have more performant VM.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/689#issuecomment-376423563, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhtqdRtMNYXbOLmIg9LtCGkod5dU1ks5tiejJgaJpZM4S8VLW
.

By parallel you mean requests from the same ship, or spawning a thousand comets and coordinating?
If the first, I can't see how current vere handles that differently. It is not like we spawn worker threads, so a thousand |hi would still take a thousands of seconds to complete, would not they?

the latency is mostly actual network latency, and not local processing
throughput :P
On Tue, Mar 27, 2018 at 11:29 AM, mikolajpp<EMAIL_ADDRESS>wrote:

By parallel you mean requests from the same ship, or spawning a thousand
comets and coordinating?
If the first, I can't see how current vere handles that differently. It is
not like we spawn worker threads, so a thousand |hi would still take a
thousands of seconds to complete, would not they?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/689#issuecomment-376628108, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhhfmSOuG5Byql6WvGyUtuuYy6BBHks5tioUPgaJpZM4S8VLW
.

I will, uh, adjust  my opinion on vere performance then ;-)

Don't adjust it too far!
(In particular, the fora.urbit.org load-time/timeout is a problem of
precisely the sort you first thought)
On Tuesday, 27 March 2018, mikolajpp<EMAIL_ADDRESS>wrote:

I will, uh, adjust my opinion on vere performance then ;-)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/689#issuecomment-376633103, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhgJVWELJDhGnSugzPGOKmlS6bPInks5tiojegaJpZM4S8VLW
.


Update site.py

fixup: windows system use "\" to join , fix to avoid such like admin/upload/202302\a.jpg name.

Please check the running under linux.
It is recommended that you change to use the Path class to implement file path concatenation.


[storage] delete retire log in batch

Motivation
It's very wasteful to delete the retire log entries key by key, not only disk space wise, but also CPU when you scan through the key range deleted. (We've already observed seek_to_first() went slow as hell.)
This utilizes the range delete capability of RocksDB to do it more efficiently. But sending too many small range deletes can also be a (slightly different) performance concern. So this did some tricks to ensure large enough batches.
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
Will test on nightly env.

@wqfish  I will update the commit msg upon squash.

squashed and rebased. gonna fix naming etc according to the latests.
(temporarily closing again)

:umbrella: The latest upstream changes (presumably b9aebd4a7425a4b1104d2c416573e95c2ee39335) made this pull request unmergeable. Please resolve the merge conflicts.

rebased

@bors-libra r=zamsden

:pushpin: Commit 2fb50d5 has been approved by zamsden

:hourglass: Testing commit 2fb50d5ab7bee1762a713bfd5f0259019cd74190 with merge dc669c87475d480b4c5a0380e449749e15f1f927...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: zamsden
Pushing dc669c87475d480b4c5a0380e449749e15f1f927 to master...


Expose build.target .cargo/config setting as packages.target in Cargo.toml

Hey!
I'm trying to do my first cargo contribution by implementing per-crate target settings as per the irlo thread ; and I think I have a draft that looks good-ish (the root units returned by generate_targets have the right kinds set).
Closes #7004
Edit: the below problem description is now solved in the latest version of this PR, please ignore
But for some reason running on a test project now blocks on Blocking waiting for file lock on build directory and I have literally no idea how my changes could trigger this… would anyone have an idea of how the changes could lead to infinitely blocking there? (I already tried cargo clean just in case and it didn't appear to help)
FWIW, the output that looks hopeful to me is, on my testbed workspace:
Root units [out of generate_targets] are [...]:
 - package ‘smtp-client’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-server’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-rpc’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config-example’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config-example’ with kind ‘Target(CompileTarget { name: "wasm32-unknown-unknown" })’
 - package ‘smtp-queue’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-message’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-server-fuzz’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘yuubind-config’ with kind ‘Target(CompileTarget { name: "wasm32-unknown-unknown" })’
 - package ‘yuubind’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’
 - package ‘smtp-queue-fs’ with kind ‘Target(CompileTarget { name: "x86_64-unknown-linux-gnu" })’

(where both yuubind-config and yuubind-config-example are being configured to be wasm32-unknown-unknown and the other ones stay as host).
Interestingly enough, if I remove the target setting from yuubind-config (and leave it on yuubind-config-example) then it does no longer block on waiting for file lock on build directory, even though it does not actually compile with wasm32-unknown-unknown. And it does appear to correctly build yuubind-config-example as wasm32.
My investigation shows that it appears to happen iff there is a package with package.target being set that has dependencies.
This most likely is a bug in my code (eg. I build only the root units and not the whole unit graph maybe?), and am going to keep investigating it as such, but maybe someone would already know how dependency resolution could interact with build lock acquisition and give me hints?
Anyway, thank you all for all you do cargo!

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

As this PR currently appears to work (for my test repository), I'd like to ask for a first round of review before polishing up all the details that are sure to be problematic.
What do you think about this? As this is my first cargo contribution, maybe there is some obvious place I forgot changing, and I should be doing this before even thinking of adding tests and polishing things up? Also, should I (and if yes is there an example somewhere in the code of how) hide this new option behind an unstable gate?
If things look good enough, I'll be glad to poke around the cargo test framework and try adding tests, and to look for what documentation might need updating.
(BTW, there are already failing CI tests that appear to be unrelated to my changes, like this one, I'm not sure whether I'm expected to drive-by fix them or not)

With the holidays in the US we are not paying as much attention as we normally do. For example the unrelated CI failing are something to do with Nightly, and normally there would be a preity prompt PR fixing it (or turning off Nightly testing) that you could rebase onto. Thank you for your contribution and patients.
Tests and documentation would be appreciated. I for one find it a good place to start finding out "what are you trying to do" as a start of a code review.
It is possible that we will make this insta stable, but it is more likely that when someone does a full review we will want a feature flag. Instructions for adding one are at https://github.com/rust-lang/cargo/blob/8917837fb682c6515c1cbfdbd16be95bb64bd6f1/src/cargo/core/features.rs

Thanks to @ehuss for #9033 that fixes CI.

Thank you for your feedback! I have just fixed an issue I noticed while using a patched cargo, and rebased to a master that hopefully has CI fixed.
I also added the documentation, that hopefully should help understanding what this diff is about.
I haven't added tests yet, though, as I'd like to confirm that at least the idea of the change is legit. The irlo thread listed in the top post, AFAIU, says that this setting should be made available, but I'm not sure that eg. [package] is the right place to put it in.
Does this sound reasonable enough? And what do you think about the documented changes, that I hopefully implemented not too awfully here?
Cheers!

Thank you for your feedback! I have just fixed an issue I noticed while using a patched cargo, and rebased to a master that hopefully has CI fixed.
I also added the documentation, that hopefully should help understanding what this diff is about.
I haven't added tests yet, though, as I'd like to confirm that at least the idea of the change is legit. The irlo thread listed in the top post, AFAIU, says that this setting should be made available, but I'm not sure that eg. [package] is the right place to put it in.
Does this sound reasonable enough? And what do you think about the documented changes, that I hopefully implemented not too awfully here?
Cheers!

Another thought I just came up with: should package.target = "wasm32-unknown-unknown" imply lib.test = false? What about package.target = "i686-unknown-linux-gnu" when the host is x86_64-unknown-linux-gnu?

Another thought I just came up with: should package.target = "wasm32-unknown-unknown" imply lib.test = false? What about package.target = "i686-unknown-linux-gnu" when the host is x86_64-unknown-linux-gnu?

I think I have noticed another issue of this PR as is, though I still have to actually check it: feature resolution happens only once, and so if a crate is depended on with a different set of features by target = "wasm32-unknown-unknown" and host-target crates, it'll end up with all features enabled for both targets. Which can end up causing issues, when eg. one optional dependency isn't supported on one of the targets.
Fixing this would require changing the feature resolution algorithm, which I expect would be quite a bit more invasive. How do you think we should go? First land the “basic” stuff and then work towards fixing feature resolution while keeping the flag gated? Or finish work on getting the feature resolution first, and only then land it all at once, at the expense of this ending up being a (much?) bigger PR?

I think I have noticed another issue of this PR as is, though I still have to actually check it: feature resolution happens only once, and so if a crate is depended on with a different set of features by target = "wasm32-unknown-unknown" and host-target crates, it'll end up with all features enabled for both targets. Which can end up causing issues, when eg. one optional dependency isn't supported on one of the targets.
Fixing this would require changing the feature resolution algorithm, which I expect would be quite a bit more invasive. How do you think we should go? First land the “basic” stuff and then work towards fixing feature resolution while keeping the flag gated? Or finish work on getting the feature resolution first, and only then land it all at once, at the expense of this ending up being a (much?) bigger PR?

Uh well, I posted that message faster than I wanted to, sorry for the notification noise.
So I also wanted to say, I've addressed a few of the comments, and replied to a few other comments. Split the refactoring towards #9046, and merged that branch here so it still works (hope git won't merge conflict me at the end, it's the first time I work in a “please don't rebase” scenario, usually I'd have just squash-rebased on top of that other branch)
Note to self about things still remaining:

Fixing the RustcTargetData handling, maybe by filling the cache on-demand? (if that's confirmed to be the way to go)
Feature-gate the two flags
Add tests
Figure out how to move forward with respect to feature flags that get depended on by multiple targets

Uh well, I posted that message faster than I wanted to, sorry for the notification noise.
So I also wanted to say, I've addressed a few of the comments, and replied to a few other comments. Split the refactoring towards #9046, and merged that branch here so it still works (hope git won't merge conflict me at the end, it's the first time I work in a “please don't rebase” scenario, usually I'd have just squash-rebased on top of that other branch)
Note to self about things still remaining:

Fixing the RustcTargetData handling, maybe by filling the cache on-demand? (if that's confirmed to be the way to go)
Feature-gate the two flags
Add tests
Figure out how to move forward with respect to feature flags that get depended on by multiple targets

(Note: I've just rebased on top of master now that #9046 landed)

(Note: I've just rebased on top of master now that #9046 landed)

Ok, so with this latest commit I have I think solved all the issues that have been raised, except:

Actually adding kinds after the fact, because I could not think of any case where the full list of kinds is not known by just exploring the workspace yet. This is because AFAIK artifact dependencies are not a thing yet — as soon as they are we'll just have to call .add_kind() at the places where testing shows crashes and things should just work. But I have not been able yet to think of any test case that would hit a situation where a kind only appears outside the workspace, as then the unit kind would AFAIU just be ignored to take its reverse-dep's kind instead.
Handling feature resolution by having one feature resolution per kind, to avoid that a crate that has features F and G, where F is used by wasm32-wasi and G by $host, ends up building both F and G for both wasm32-wasi and $host. (I have a concrete case where this happened, and F cannot build on $host nor G on wasm32-wasi) The solution to this needs to be informed by the current state of implementing artifact dependencies, as artifact dependencies will also influence feature resolution: if A depends on artifacts from B and C, B depends on D with feature F and C on D with feature G, do both B and C build with a D that has features F and G, or do they each get their own D? Depending on the response of this question + the status of the implementation of artifact dependencies, it will be hopefully possible to make progress here without creating merge conflicts between the two PRs — I don't want to cause trouble to other PRs that would currently be in the process of being written :)

Ok, so with this latest commit I have I think solved all the issues that have been raised, except:

Actually adding kinds after the fact, because I could not think of any case where the full list of kinds is not known by just exploring the workspace yet. This is because AFAIK artifact dependencies are not a thing yet — as soon as they are we'll just have to call .add_kind() at the places where testing shows crashes and things should just work. But I have not been able yet to think of any test case that would hit a situation where a kind only appears outside the workspace, as then the unit kind would AFAIU just be ignored to take its reverse-dep's kind instead.
Handling feature resolution by having one feature resolution per kind, to avoid that a crate that has features F and G, where F is used by wasm32-wasi and G by $host, ends up building both F and G for both wasm32-wasi and $host. (I have a concrete case where this happened, and F cannot build on $host nor G on wasm32-wasi) The solution to this needs to be informed by the current state of implementing artifact dependencies, as artifact dependencies will also influence feature resolution: if A depends on artifacts from B and C, B depends on D with feature F and C on D with feature G, do both B and C build with a D that has features F and G, or do they each get their own D? Depending on the response of this question + the status of the implementation of artifact dependencies, it will be hopefully possible to make progress here without creating merge conflicts between the two PRs — I don't want to cause trouble to other PRs that would currently be in the process of being written :)

:umbrella: The latest upstream changes (presumably #8037) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably #8037) made this pull request unmergeable. Please resolve the merge conflicts.

Hm no nevermind scratch that about being an error, I could see it being useful still for just-libs that have tests and only want to cargo check on one target, for example.

Hm no nevermind scratch that about being an error, I could see it being useful still for just-libs that have tests and only want to cargo check on one target, for example.

Thank you for your feedback! As there was a merge conflict, I've just added two commits to handle your review comments, and then rebased the whole thing on master, so the only two changes (apart from the few merge conflicts, particularly the feature-gate-format change in the new 1c515fe) are in the last two commits :)

Thank you for your feedback! As there was a merge conflict, I've just added two commits to handle your review comments, and then rebased the whole thing on master, so the only two changes (apart from the few merge conflicts, particularly the feature-gate-format change in the new 1c515fe) are in the last two commits :)

Oh and I just noticed I forgot to answer this question:

For feature resolution I think it's probably best to leave the nitty-gritty there as an open question on a tracking issue, we probably don't need full semantics of that here just yet. Does what's here not work in some situations, though?

So there is one situation I found where the current semantics are problematic: when one feature is incompatible with one target.
For instance, I have a feature that makes sense only on wasm32, in which I've put const_assert_eq!(mem::size_of::<usize>(), mem::size_of::<u32>()); because I wouldn't be surprised if there were memory safety issues that could arise from some conversions in there.
With the current way feature resolution works (ie. one big fixpoint on the whole crate graph, regardless of build kind), if non-wasm32 depends on this crate and wasm32 code depends on this crate with the wasm32-specific feature enabled, then the non-wasm32 code will also try to build the wasm32-specific feature and will thus fail to build.
So, especially given it would probably be a breaking change to do that later (because we'd remove features that were previously enabled, though they were not explicitly depended upon… not sure what the actual policy is there, I'd guess it's OK if crates on crates.io remove a feature from one of their dependencies but it probably wouldn't be OK for cargo to do so), I think we will have to fix this before stabilization and I don't think there'd be much debate as to the expected semantics.
IOW, I'm mostly wondering whether it's better to do it just now, or to do it in a follow-up PR, to make things more manageable to review :) (though I must say I haven't implemented it yet so I don't know yet how hard it'll be to do)

Oh and I just noticed I forgot to answer this question:

For feature resolution I think it's probably best to leave the nitty-gritty there as an open question on a tracking issue, we probably don't need full semantics of that here just yet. Does what's here not work in some situations, though?

So there is one situation I found where the current semantics are problematic: when one feature is incompatible with one target.
For instance, I have a feature that makes sense only on wasm32, in which I've put const_assert_eq!(mem::size_of::<usize>(), mem::size_of::<u32>()); because I wouldn't be surprised if there were memory safety issues that could arise from some conversions in there.
With the current way feature resolution works (ie. one big fixpoint on the whole crate graph, regardless of build kind), if non-wasm32 depends on this crate and wasm32 code depends on this crate with the wasm32-specific feature enabled, then the non-wasm32 code will also try to build the wasm32-specific feature and will thus fail to build.
So, especially given it would probably be a breaking change to do that later (because we'd remove features that were previously enabled, though they were not explicitly depended upon… not sure what the actual policy is there, I'd guess it's OK if crates on crates.io remove a feature from one of their dependencies but it probably wouldn't be OK for cargo to do so), I think we will have to fix this before stabilization and I don't think there'd be much debate as to the expected semantics.
IOW, I'm mostly wondering whether it's better to do it just now, or to do it in a follow-up PR, to make things more manageable to review :) (though I must say I haven't implemented it yet so I don't know yet how hard it'll be to do)

Nah that's a really good point about target-specific features. Still ok to not handle here though, fine if we handle that later! I do think it will block stabilization of any form, however. All that being said I don't think it'll be the end of the world to soup-up the v2 feature resolver to fix this.

Nah that's a really good point about target-specific features. Still ok to not handle here though, fine if we handle that later! I do think it will block stabilization of any form, however. All that being said I don't think it'll be the end of the world to soup-up the v2 feature resolver to fix this.

What's the status of this PR? No rush, but I'm eager to use this feature in nightly if possible.
Thanks!

:umbrella: The latest upstream changes (presumably #9184) made this pull request unmergeable. Please resolve the merge conflicts.

I've been busy with work and life stuff over the past few weeks, sorry for not having been able to come back to this PR earlier! Here it is updated with the review comments handled — this idea of taking TARGET from build.rs is awesome!
I've pushed two new commits, and then force-pushed a rebase to fix the merge conflict. Hopefully this now looks good :)
I've prepared the text for the tracking issue by copying the formatting of a random other tracking issue, not sure whether it's supposed to be posted before or after the PR lands:
#### Summary

Feature gate: `per_package_target`
Discussion: https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336
Implementation: https://github.com/rust-lang/cargo/pull/9030
Documentation: TODO (based on [these previous changes](https://github.com/rust-lang/cargo/pull/9030/commits/d9e97c26efa99d52d30961a256811c43f7187433#diff-3bc7476e0b88b61ea4e3bd46743021ef33c927f3052c1f7800bc8aa053627b31)?)

#### Unresolved issues

- [ ] Define interaction with features: in workspaces where crate X is built for architecture A and depends on crate Z with feature F, and crate B is built for architecture B and depends on crate Z with feature G, we want the A version of Z to be built with F only and the B version of Z to be built with G only; but the current behavior is to build both the A and B versions of Z with both F and G
- [ ] Make sure things work correctly with artifact dependencies, that could introduce kinds across the build graph

#### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

(I also guess a separate issue should be opened for the first unresolved issue at least, so as to be able to track it properly)

:umbrella: The latest upstream changes (presumably #9290) made this pull request unmergeable. Please resolve the merge conflicts.

I've just squash-rebased onto a newer master, sorry for changing the history but always having to handle merge conflicts due to changes that I had done and undone in later commits was getting cumbersome — hopefully github will still show the commit history by clicking the links in the “force-pushed” line :)

:umbrella: The latest upstream changes (presumably #9298) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton Could you give another look at this PR? I think I handled your last comments, so hopefully it should be ready to go :)

Thank you for your feedback! And no problem about this falling under your radar, it fell under mine for a long time before that :sweat_smile:
The review comments should have been handled, I rebased and fixed a compile error that appeared since the last rebase, CI passed, and I opened https://github.com/rust-lang/cargo/issues/9406 for the tracking issue. I'm just not clear about the unstable documentation, as AFAIU the rust unstable book is only for rustc and this PR already has changes to something that may be the unstable documentation?

Ok thanks! This looks good to me so I'll approve
@bors: r+
For the tracking issue I'll fill in some details.

:pushpin: Commit fcd761729e9d7853ba8e30674f9d9a45671d1ed9 has been approved by alexcrichton

:hourglass: Testing commit fcd761729e9d7853ba8e30674f9d9a45671d1ed9 with merge d1c0a9d9ca31ec1b861940b30c1a660dfa2e3b56...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing d1c0a9d9ca31ec1b861940b30c1a660dfa2e3b56 to master...

How can I use this?

Can someone please explain how to use this feature? I can't find any documentation

Normally you can find the documentation of an unstable feature from "Unstable Features" chapter in The Cargo Book. The usage is documented there as well.
For more usages, you may also want to take a look at how cargo tests this feature, or keep an eye on the tracking issue to see how people use it.


[MINOR][K8S] add missing docs for podTemplateContainerName properties

What changes were proposed in this pull request?
Adding docs for an enhancement that came in late in this PR: #22146
Currently the docs state that we're going to use the first container in a pod template, which was the implementation for some time, until it was improved with 2 new properties.
How was this patch tested?
I tested that the properties work by combining pod templates with client-mode and a simple pod template.
Please review http://spark.apache.org/contributing.html before opening a pull request.

Can one of the admins verify this patch?

cc @mccheah @onursatici @skonto

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Thank you for your first contribution, @aditanase .

ok to test

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99341/
Test PASSed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/testing-k8s-prb-make-spark-distribution-unified/5418/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/testing-k8s-prb-make-spark-distribution-unified/5418/

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5418/
Test PASSed.

Test build #99364 has started for PR 23155 at commit 290b764.

Test build #99364 has finished for PR 23155 at commit 290b764.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/99364/
Test PASSed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/testing-k8s-prb-make-spark-distribution-unified/5441/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/testing-k8s-prb-make-spark-distribution-unified/5441/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/5441/
Test PASSed.

@dongjoon-hyun is this ok to merge? Should I squash it and ping you again?

Ping @aditanase


Open Saved Clips Menu Error

TeslaCam Browswer 0.0.949
Ubuntu 18.04.2 LTS O/S
Click File > Open Saved Clips...
Then the error below is received.

@gbgadgets can you confirm is this is still happening with the current version? #27 highlights some other path problems that might exist.

Closing due to non-response please feel free to re-open if problem still exists.


Removes lua_ssl_trusted_certificate from crowdsec_openresty.conf in Docker Mode

Fixes https://github.com/crowdsecurity/cs-openresty-bouncer/issues/27
This removes  lua_ssl_trusted_certificate through my testing everything still works as expected on both ssl and normal sites.

Actually according to the docs this is only required for the following which doesn't even look used
Specifies a file path with trusted CA certificates in the PEM format used to verify the certificate of the SSL/TLS server in the [tcpsock:sslhandshake](github://github.com/?anchor=tcpsocksslhandshake) method.

I just tested this now using a V2 recaptcha key [v2 Tickbox] and it worked as expected

I just tested locally and I have the same issue has we faced when using captcha:
2022/04/06 10:44:10 [error] 11#11: *1 [lua] crowdsec.lua:444: Allow(): Error while validating captcha: no resolver defined to resolve "www.google.com", client: <IP_ADDRESS>, server: localhost, request: "POST / HTTP/1.1", host: "helloworld.local", referrer: "http://helloworld.local/"

As the resolver is not found, the request not banned if the captcha is wrong.
Also, I realized that you need to remove the lua_ssl_trusted_certificate from ./openresty/crowdsec_openresty.conf file in the docker image. You forgot because you're using the install script instead of the docker image.
How to reproduce

Check out this PR
Remove the line 3 from ./openresty/crowdsec_openresty.conf
Change Dockerfile line 20 by COPY ./openresty/crowdsec_openresty.conf /etc/nginx/conf.d/crowdsec_openresty.conf
Build the image, add a decision with type captcha and run the image with secret et site key to have captcha running

Ok i'm going to put this on hold for, it is required for the captcha I just don't think the overhead is worth it. So going to try figure out if this is possible to improve

I'm not exactly sure whats causing the extreme memory usage, but this at least fixes it for my case

I did edit the Dockerfile to add the resolver line back into crowdsec_openresty.conf for testing though


Report feature: Add 'remaining vars' to the report of each table

Need to identify which table had those remaining variables. Maybe use the target question id of that step.
Questions:

What if the table was created in 'Background' (when we implement that)? We'll need to create a different convention for that?
Also, it may become more complicated when we have to combine the Background table and a Scenario's table. Do we record the remaining variables that were in the table, or include the ones that were in the background data that weren't used up?

Questions to keep in mind when addressing #138