Allow excluding thirdPartyCompatibility from GMM

Expected Behavior
Per the GMM spec, I would like to have the ability to exclude thirdPartyCompatibility from the generated module.json since it's optional.
In summary, I would like to have the ability to do at least do the following:
tasks.withType(GenerateModuleMetadata) {
    thirdPartyCompatibility = false
}

Current Behavior (optional)
Currently when working with JavaFX projects, either using the JavaFX plugin or manually specifying the JavaFX dependencies, we get a module.json that looks like below:
...
{
  "group": "org.openjfx",
  "module": "javafx-base",
  "version": {
    "requires": "20.0.2"
  },
  "thirdPartyCompatibility": {
    "artifactSelector": {
      "name": "javafx-base",
      "type": "jar",
      "extension": "jar",
      "classifier": "linux"
    }
  }
}
...

This can cause issues to downstream consumers such as this JLink error Error: Two versions of module javafx.base found in /path/to/build/jlinkbase/jlinkjars (javafx-base-20.0.2-mac-aarch64.jar and javafx-base-20.0.2-linux.jar) since the published .module file will have the classifier entry.
Context
This is a follow up per @Vampire recommendation based on a Slack Conversation.
In summary, I would like to have the ability to do at least do the following:
tasks.withType(GenerateModuleMetadata) {
    thirdPartyCompatibility = false
}

To explain, lets consider the following build.gradle file for a typical OSS JavaFX library package:
plugins {
    id 'java'
    id 'java-library'
    id 'application'
    id 'maven-publish'
    id 'org.openjfx.javafxplugin' version '0.0.14'
}

group = 'org.example'
version = '1.0-SNAPSHOT'
description = 'An example JFX app'

repositories {
    mavenCentral()
}

application {
    mainModule = 'org.example'
    mainClass = 'org.example.Launcher'
}

java {
    sourceCompatibility = JavaVersion.VERSION_17
    targetCompatibility = JavaVersion.VERSION_17
    modularity.inferModulePath.set(true)
}

javafx {
    version = '20.0.2'
    modules = ['javafx.controls', 'javafx.graphics']
}

publishing {
    publications {
        mavenCustom(MavenPublication) {
            artifactId = 'example'
            group = project.group
            version = project.version
            from components.java

            pom.withXml {
                def root = asNode()
                root.dependencies.'*'
                        .findAll() { it.groupId.text() == 'org.openjfx' }
                        .each { it.remove(it.classifier) }
            }

            pom {
                name = 'Example'
                description = project.description
            }
        }
    }

}

When publishing this package, it yields the proper pom.xml as its common practice to remove the classifier from the JavaFX dependencies for consumers, but the module.json is currently a bit problematic.
The pom.xml:
...
<dependency>
  <groupId>org.openjfx</groupId>
  <artifactId>javafx-base</artifactId>
  <version>20.0.2</version>
  <scope>runtime</scope>
</dependency>
...

The module.json:
...
{
  "group": "org.openjfx",
  "module": "javafx-base",
  "version": {
    "requires": "20.0.2"
  },
  "thirdPartyCompatibility": {
    "artifactSelector": {
      "name": "javafx-base",
      "type": "jar",
      "extension": "jar",
      "classifier": "linux"
    }
  }
}
...

This can cause issues to downstream consumers such as this JLink error Error: Two versions of module javafx.base found in /path/to/build/jlinkbase/jlinkjars (javafx-base-20.0.2-mac-aarch64.jar and javafx-base-20.0.2-linux.jar) since the published .module file will have the classifier entry.
I'm looking for an option that I can prevent this from happening and yield the following module.json:
...
{
  "group": "org.openjfx",
  "module": "javafx-base",
  "version": {
    "requires": "20.0.2"
  }
}
...

which behaves as expected to downstream consumers when we publish our JavaFX libraries.
Currently, I'm resorting to the following code to modify the module.json before publishing:
tasks.withType(GenerateModuleMetadata).configureEach {
    doLast { _ ->
        def gmmFile = it.outputFile.get().asFile
        def inJson = new JsonSlurper().parseText(gmmFile.text)
        def filteredVariant = inJson.variants.findAll { it.name == configurations.runtimeElements.name }
        // remove "thirdPartyCompatibility" from GMM
        filteredVariant.dependencies.first().each {
            if (it.group == 'org.openjfx') {
                it.remove('thirdPartyCompatibility')
            }
        }
        def outJson = JsonOutput.toJson(inJson)
        gmmFile.write(JsonOutput.prettyPrint(outJson))
    }
}

Here's an example from a published library before and after the fix above:

Before: https://repo1.maven.org/maven2/eu/hansolo/fx/charts/17.1.47/charts-17.1.47.module
After: https://repo1.maven.org/maven2/eu/hansolo/fx/charts/17.1.51/charts-17.1.51.module

I assume you get the "thirdPartyCompatibility" part in the Metadata, because you define the dependencies with classifier.
You could get rid of that by not defining a classifier in the dependency and instead:

Define a component metadata rule that makes all the "Variants" of JavaFX known as proper Gradle Variants
Select Variants in you own build based on attributes on the classpath(s)

I think JavaFX should publish Gradle Metadata with the corresponding variant information. And the JavaFX plugin should be updated to use that (or maybe it won't be needed at all).
Here is the rule that you could use: https://github.com/gradlex-org/java-ecosystem-capabilities/issues/57
Then don't define classified dependencies, but request attributes on the classpath configurations - e.g.:
sourceSets.all {
    configurations.getByName(compileClasspathConfigurationName) {
        attributes {
            attribute(OperatingSystemFamily.OPERATING_SYSTEM_ATTRIBUTE, objects.named(LINUX))
            attribute(MachineArchitecture.ARCHITECTURE_ATTRIBUTE, objects.named("x86-64"))
        }
    }
    configurations.getByName(runtimeClasspathConfigurationName) {
        attributes {
            attribute(OperatingSystemFamily.OPERATING_SYSTEM_ATTRIBUTE, objects.named(LINUX))
            attribute(MachineArchitecture.ARCHITECTURE_ATTRIBUTE, objects.named("x86-64"))
        }
    }
}

(and do not use the Java FX plugin)

@jjohannes Thanks for that alternative approach. I had looked into that approach last week, but I was trying to find a meet-in-the-middle approach where we can help JavaFX library maintainers transition to (this issue is for the benefit of JavaFX library maintainers) without too much tech debt of having to maintain a running list of all JavaFX classifiers in their repos.
Some maintainers just don't publish GMM at all.
Another alternative I saw a different JavaFX library maintainer doing is below, which is sort off undesired since it removes stuff entirely from the GMM.
   // Prevent pom & module.json from containing JavaFX runtime dependencies
    if ( taskNames.stream().anyMatch( t -> t.startsWith('pub') ) ) {
        configuration = 'compileOnly'
    }

I'm not sure if upstream JavaFX will be publishing a GMM anytime soon. I realize that's likely the best preferred solution, but given my uncertainty here if that will ever happen I opened this issue. I thought it was a fair proposal given that since thirdPartyCompatibility is optional per the spec that there should be a built-in way to exclude it in gradle.
I'm also not sure if it will be a straightforward solution to have every JavaFX library maintainer adopt what's proposed in https://github.com/gradlex-org/java-ecosystem-capabilities/issues/57 and drop the JavaFX plugin since the plugin is what's in the getting started docs for JavaFX, see https://openjfx.io/openjfx-docs/#gradle, so it's almost a JavaFX mantra at this point to use the JavaFX plugins 😆.
Having said that, I still would think this new config setting could help ease the burden on other similar scenarios, obviously the most notable being JavaFX here. Another good meet in the middle approach could be updating the JavaFX gradle plugin, but I'm unsure what the approach would be there without impacting consumers. Thoughts?

I would definitely welcome if you fix that JavaFX mess @jjohannes :-D

I took a look at the plugin. It's not that much code actually. So well... I ended up with a full implementation for moving it to variant support and removing the "hard link" to org.javamodularity.moduleplugin. Lets see....
https://github.com/openjfx/javafx-gradle-plugin/pull/151

When the task to generate GMM was designed, it was a conscious decision to not allow users to easily mess with the generated content.
Given the conversation and the fact that there is a better path for JavaFX, I will close this as there is no plan to provide such an escape hatch.

@ljacomet Thanks, that's alright to close as my main concern when I opened the issue was with JavaFX. I kept it open because its likely other oss libraries might suffer from the same situation even outside the JavaFX context.
I still think something like this might still be useful in the long run and I don't see it as an escape hatch since per spec thirdPartyCompatibility is optional to begin with, but I understand that from Gradle's point of view and design choice it's something that is low priority.

@samypr100 you are looking at this from a slightly wrong angle.
That it is optional in the spec means it is optional in the file, as it can be absent if not needed, i.e. no classifier is used.
But it does not mean that a user of Gradle should be able to leave it out.
The sense is, "configure your project correctly, then the correct GMM file is produced".
This has various advantages, for example also the POM is then most likely correct, and it also works in other situation like if you for example consume the build in a composite build.
If you would do the latter, it would behave differently than when consuming the published artifact as you manually manipulate the metadata for the publication, no matter whether you do it like in your doLast manipulation or via something like pom.withXml.
So I don't think this is "low priority", but a good and sane design decision, that is intended to force you fixing your build model instead of manipulating some file on publication.
The main problem with JavaFX is, that the JavaFX Gradle plugin in its current state does a hack-around to work-around the suboptimal JavaFX publishing. This hack-around causes the dependencies with classifiers to be used and thus "breaks" your model which is then persisted in the GMM. Your doLast hack, or a skipThirdPartyCompatibility escape hatch, is just another hack-around to revert the negative effect the other hack-around had on the produced GMM.
If the problem in the JavaFX publication is work-arounded properly, using component metadata rules to properly declare the variants like @jjohannes suggested is then less a hack-around, but a proper work-around that solves the problem in JavaFX publication without the negative effect on GMM.
If there are other "other oss libraries that suffer from the same situation even outside the JavaFX context", those situation should be reported separately in case there is no proper work-around, so that Gradle could provide a way to properly work-around the problem without needing to manually manipulate the produced GMM which then just shifts the negative impact to an even later time as I described above. :-)

@Vampire Apologies, I do see both angles. I think I just keep going back to how easily this situation can happen without library publishers noticing.
Would issuing a warning if you're publishing a GMM that includes thirdPartyCompatibility be an acceptable path forward?

In my opinion no, as it can be a perfectly fine situation, it just is not in the JavaFX case.
But that's on the Gradle folks to decide, not me. :-)

Yes, I can see it being perfectly fine as well, but the lack of corresponding variant information can be a problem too 😂


KeyError: 'video_fps'

KeyError: 'video_fps'

If you want to control the FPS used for video input, you should use the key "fps" instead of "video_fps." please ref to link

I use the key "fps" instead of "video_fps." ,but it still doesn't work !!!
messages = [
{
"role": "user",
"content": [
{
"type": "video",
# "video": "IMG_3309.MOV",
"video": "test1.mp4",
"max_pixels": 360 * 420,
"fps": 2.0,
},
{"type": "text", "text": text1},
],
}
]
(Qwen2-VL-2B-Instruct1) hxy@thor:~$ python /media/ssd4/hxy/LLaVA-Video-72B-Qwen2/Qwen2-VL-2B-Instruct1.py
Qwen2VLRotaryEmbedding can now be fully parameterized by passing the model config through the config argument. All other arguments will be removed in v4.46
Loading checkpoint shards: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:01<00:00,  1.42it/s]
请输入问题：有什么
qwen-vl-utils using torchvision to read video.
Traceback (most recent call last):
File "/media/ssd4/hxy/LLaVA-Video-72B-Qwen2/Qwen2-VL-2B-Instruct1.py", line 91, in
image_inputs, video_inputs = process_vision_info(messages)
File "/home/hxy/anaconda3/envs/Qwen2-VL-2B-Instruct1/lib/python3.9/site-packages/qwen_vl_utils/vision_process.py", line 332, in process_vision_info
video_inputs.append(fetch_video(vision_info))
File "/home/hxy/anaconda3/envs/Qwen2-VL-2B-Instruct1/lib/python3.9/site-packages/qwen_vl_utils/vision_process.py", line 260, in fetch_video
video = VIDEO_READER_BACKENDSvideo_reader_backend
File "/home/hxy/anaconda3/envs/Qwen2-VL-2B-Instruct1/lib/python3.9/site-packages/qwen_vl_utils/vision_process.py", line 193, in _read_video_torchvision
total_frames, video_fps = video.size(0), info["video_fps"]
KeyError: 'video_fps'

@jackhexiangyu12 I changed the video file path from "file://my_video.mp4" to "my_video.mp4" then it worked.
@ShuaiBai623  It seems like in the video_process.py the cutting off of "file://" is not working because the if-condition is indented too far (checking torchvision.version)


sct_check_dependences should be more sensitive to python dependences installation

Related to issues #862, #863, #864.
For exemple, it should at least test import XXX

It now tests for it.


Dockerize the experiment scaffold tool to avoid managing dependencies

As we start getting exp contributions (and also support python, go experiments) - the scaffold tool needs to be dockerized - so that developers can do a docker run with --type <go/python/ansible>, --config <attributes.yaml> and by mounting the litmus exp folder as volume - to generate all the required artefacts in desired path. It will prevent the need to install dependencies before using the scaffold tool.

cc: @AmitKumarDas

is there any existing steps that does the same

The litmus-sdk is now available as a binary and does not need dependency setup: https://github.com/litmuschaos/litmus-go/tree/master/contribute/developer-guide


dgoss README references older goss version

The dgoss README references 0.3.6 instead of 0.3.7 in the MacOS install instructions https://github.com/aelsabbahy/goss/blob/master/extras/dgoss/README.md#mac-osx

Reworded it to only be an example version rather than the latest.

Please reopen if the verbiage isn't clear.


doc(README): mention Linux (>= 3.14) TCP Auto Corking

TCP Auto Corking in Linux >= 3.14 can be an obstacle especially when parsing packets emitted from QuorumCnxManager.SendWorker.run().
This commit adds a small note about TCP Auto Corking to README.

Sorry for missing this PR @AkihiroSuda !
Hmm, are you sure that this is not fixed by https://issues.apache.org/jira/browse/ZOOKEEPER-2098? In other words, you are seeing the message split into multiple packets? How could auto-corking cause that?
cc: @Yasumoto

@rgs1
Thank you for the response.
The issue has not been fixed by ZOOKEEPER-2098, as ZOOKEEPER-2098 is not related to the non-buffered DataOutputStream used in QCM.SendWorker.
https://github.com/apache/zookeeper/blob/0cbc8eee21bda31184d4e7f11100bc0bb300f376/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L779-781
When corking is enabled, I can get "corked" (i.e., "merged") packets rather than split packets, and zktraffic fails to parse FLE Messages.
A typical "corked" packet is as follows:
+------------------------------------------------------------+
| integer length of FLE Message (zktraffic cannot parse this)|
+------------------------------------------------------------+
| FLE Message                                                |
+------------------------------------------------------------+

When corking is disabled, the length field gets split from FLE Message field, and zktraffic succeeds to parse FLE Messages.
(Note that zktraffic just ignores the length field with a BadPacket("Too small") exception. )
Ideally, zktraffic should implement full TCP stack, as the behavior can change in future Zookeeper releases, especially when ZOOKEEPER-901(Redesign of QCM) gets fixed.
However implementing TCP is very troublesome work. :cry:

@AkihiroSuda it's not that hard, I am parsing full TCP streams for https://github.com/pinterest/thrift-tools. It just uses more memory! But we should support his in ZKTraffic soon...

+1


Page.PDF is wrapping text to a new line

We're having an issue where text is wrapping when we render a PDF. The HTML previews ok and page.screenshot renders as expected, however, the output PDF has the text wrapped to a new line.
I've reproduced this locally on MacOS and have included a zip of the code to run.
Steps to reproduce
Tell us about your environment:

Puppeteer version: 5.4.1
Platform / OS version: MacOS Catalina (10.15.7) and node:12.13.0-stretch (Debian) Docker based env.
Node.js version: 12.18.1 (MacOS), 12.13.0 (Linux)

What steps will reproduce the problem?
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: true,
    args: [
      '--no-sandbox',
      '--disable-gpu',
      '--disable-setuid-sandbox',
      '--disable-dev-shm-usage',
      '--homedir=/tmp',
      '--data-path=/tmp/data-path',
      '--disk-cache-size=0',
      '--disk-cache-dir=/tmp/cache-dir',
      '--font-render-hinting=none',
    ], // All mandatory
    ignoreHTTPSErrors: true,
  });
  const page = await browser.newPage();
  await page.goto('http://pptr-pdf-text-wrap.s3-website-us-east-1.amazonaws.com', {
    waitUntil: ['networkidle0', 'load'],
    timeout: 0
  });

  await page.waitForSelector('#page');
  await page.waitForTimeout(2000);

  const width = 1588;
  const height = 2246;

  await page.addStyleTag(
    {'content': `@page { size: ${width}px ${height}px; margin: 0; }`}
  )

  await page.setViewport({
    width: width,
    height: height,
  });
  await page.screenshot({
    path: 'text-wrap.png',
  });

  await page.pdf({
    path: 'text-wrap.pdf',
    printBackground: true,
    pageRanges: '1',
    width: width,
    height: height,
  });

  await browser.close();
})();

Unzip pptr-pdf-text-wrap.zip
NPM install
Run node index.js

What is the expected result?
PDF has the text "Enter Text Here" on a single line as per the PNG and HTML preview
text-wrap
What happens instead?
PDF has text "Here" word wrapped to a new line.
text-wrap.pdf

Bump... anyone run into this issue before?

It's always boiled down to a CSS/HTML layout issue when I've had this issue.
That is to say, the div holding your text might not be the full width of the page.  I believe that the images will still render at their full width unless you constrain them to resize into their div containers.
I suggest that you enable some type of border around your text to see what the actual shape of that bounding box really is.


Implemented Custom Stylable Toast

Fixes: #225 .
Description:
Implemented a Custom Stylable Toast to be displayed which adheres to the Theme of the android app and replaced the default Toast. It improves the styling and theme of the app and the user-interface. The Toast can later be changed very easily if the need arises to do so.
Current Toast:

Custom Stylable Toast:

@sastry17 sir please review my PR.


Added Dependabot from the Old Repo

Description
Changes proposed in this pull request:

Added missing Dependabot configuration.

Related issue(s)

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


0.9.3

Changes:

Simplifying integration of new models and handling/presentation of their status (active, legacy, retired)
Cleaner handling of max_tokens vs context window tokens
updated openai python package to 1.13.3

Tested locally in venv, using Docker and on a test Unraid system before public release

Using the models.json file decouples development from model support.


WIP: WFR2-prep nirspec

https://jira.stsci.edu/browse/JWSTSIAF-130

No merge because part of WFR2 exercise.


Add new guild properties

Pull Request Etiquette

[x] I have checked the PRs for upcoming features/bug fixes.
[x] I have read the contributing guidelines.

Changes

[x] Internal code
[x] Library interface (affecting end-user code)
[ ] Documentation
[ ] Other: _____

Closes Issue: NaN
Description
Discord has added these new properties a while back.

We also have to add the new boosting properties premium_tier and premium_subscription_count. Member also has premium_since now.

Do we want to use the client naming of "Boosted" or Premium?

We could probably remove retrieveVanityUrl with this as well. The code is now a guild property it seems.

Do we get an update event when it is added?

@DV8FromTheWorld I haven't confirmed it but I would think so.

If we get WS events for this, then let's remove the method.
Need to detail that it has been removed and replaced by the non network variant

Reminder: Add the events to ListenerAdapter and add documentation


bst artifact checkout should default to directory if neither --tar nor --directory given

See original issue on GitLab
In GitLab by [Gitlab user @beckyella16] on Jul 12, 2019, 10:58
Summary
If neither the --directory or --tar options are given for bst artifact checkout, it immediately errors out, saying that one of these options is required:
cd doc/examples/autotools/
bst artifact checkout hello.bst

output:
ERROR: One of --directory or --tar must be provided

Perhaps we should create a default directory to checkout the artifact into if the --directory and --tar options are not given.
This is consistent with how bst workspace open foo.bst behaves.

In GitLab by [Gitlab user @jennis] on Jul 12, 2019, 11:10
mentioned in merge request !1451

In GitLab by [Gitlab user @beckyella16] on Jul 15, 2019, 13:32
mentioned in merge request !1476

In GitLab by [Gitlab user @beckyella16] on Jul 15, 2019, 13:54
marked this issue as related to #1067

In GitLab by [Gitlab user @marge-bot123] on Jul 16, 2019, 12:52
closed via merge request !1476

In GitLab by [Gitlab user @marge-bot123] on Jul 16, 2019, 12:52
mentioned in commit 0f1938dd6b263fcf754221815986b3cee5cde9c9


Added MAXWSNENV and MAX32600MBED to flash_test.py

Added MAXWSNENV and MAX32600MBED to flash_test.py

You might also want to add these boards to the remaining tests - basic_test.py and speed_test.py.  If you do that, then you can use automated_test.py to verify all tests work and get performance metrics.

They are already supported in those tests. I just some how overlooked the flash one.

Excellent, I see that now.  The script flash_test.py was brought in in #104, so it probably didn't exist when your brought your targets in.


wireguard: unable to route all traffic through interface

Issue description
I'm unable to route all traffic through a properly configured Wireguard interface using both networking.wireguard and wg-quick(8); when using allowedIPs = [ "<IP_ADDRESS>/0" "::/0" ] I'm unable to ping any system outside my own, except for my router.
If some other IP range is allowed, say <IP_ADDRESS>/24, I am able to ping the interface, but my traffic is not routed through it.
Steps to reproduce

Store a valid Wireguard configuration in /etc/wireguard/wg-test.conf with AllowedIPs = <IP_ADDRESS>/0,::/0 under [Peer].
Run wg-quick up wg-test.

Or alternatively:

Define a Wireguard interface via networking.wireguard with allowedIps = [ "<IP_ADDRESS>/0" "::/0" ].
Rebuild system.

Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.83, NixOS, 18.09.1420.5d4a1a3897e (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.1.3`
 - channels(root): `"nixos-18.09.1420.5d4a1a3897e"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

likewise. I can ping the interface with allowedIPs of <IP_ADDRESS> exactly, but not with a catchall rule

one potential fix for this might be implementing the network user-namespace based approach I've feature requested in https://github.com/NixOS/nixpkgs/issues/52411

@Moredread, the issue remains.

I had to add a networking.firewall.allowedUDPPorts = [ 51820 ]; to my server's config.
The server is configured via a nix module. It seems weird that it doesn't configure iptables.

I wasn't able to get this working, even after adding a manual route to the wireguard server (through my default gateway and regular eth0). Any suggestions?

I have the same problem. Doesn't matter whether I use wg-quick or the nixos options approach. Wireguard otherwise works fine when having only specific IP:s allowed, but now I wanted to route all traffic.

So I solved my specific problem a bit differently. I now move the wireguard interface(s) into a different Linux network namespace and then start my compositor (sway) within that network namespace. This works really well for me with the added benefit of effectively forcing all processes run within sway such as firefox, mail client etc. to use only the wireguard interface(s) (because there aren't any other interfaces). It also prompted me to write this simple utility to do what I need: https://github.com/johnae/netns-exec
While not exactly what the wireguard dev suggests (I found it a bit too messy/difficult to launch dhcpd, wpa_supplicant or iwd + wireguard within a different namespace), it's close enough for me.

Hi @johnae, interesting solution - is there a benefit to your netns-exec over using ip netns exec?
I arrived at a similar solution by taking the existing, (seemingly complete or abandoned) wg-netns project and creating my own wg-netns fork that works with NixOS and warns against a couple common sources of DNS leaks. It uses ip netns exec underneath, but achieves a similar effect as you've described - I'm left with a tmux session (easily changed to sway or whatever) that is running in a netns with only lo/wg0 inside.

@colemickens yeah I saw that one but I wanted a setuid binary so that I could run it as my normal user. The ip command has such a large surface area so I wouldn't want to make that setuid.
I have a very basic... well "display manager" (if you squint hard) based on https://github.com/lotabout/skim and I run that on tty1 and tty2 - so I get some options like "sway private" for example. For that to be seamless combined with network namespaces I need to be able to run it as my normal user.
See https://github.com/johnae/nixos-configuration/blob/bb71d52b96f3e518decd167160357c8f4a3898cb/home/fish.nix#L9
and
https://github.com/johnae/nixos-configuration/blob/bb71d52b96f3e518decd167160357c8f4a3898cb/home/fish.nix#L110
Also messing around with the gpg-agent service home-manager as it must run within the same network namespace when you use the gnome3 pinentry variant (this is a socket activated service). I've gotten it to work but it's still a bit wip, nothing committed yet (and certainly no pull req against home-manager, if I ever do one).

@colemickens I actually found another project today called exactly netns-exec (same as mine) but quite a few years old written in C - this https://github.com/pekman/netns-exec. I opted to keep my version written in Rust since it's less code and hopefully somewhat more trustworthy because of Rust but it probably doesn't matter much in the end whichever one uses.
What that other project did have however was netns-exec-bus which is a shell script for making the abstract dbus socket into a normal socket which can be used from within a namespace. So I adapted that a bit and now I don't need to run gpg-agent in any special way, can just use the service defs from home-manager which is pretty awesome overall. See here: https://github.com/johnae/nixos-configuration/blob/master/pkgs/netns-dbus-proxy/netns-dbus-proxy.sh and here: https://github.com/johnae/nixos-configuration/blob/bd1fb72978504db13642af10e7aec398b1ebe740/home/fish.nix#L9

I have encountered the same issue when I was trying to connect my new NixOS setup to the same wireguard server my other devices are using.
Using ip route add <server_endpoint_ip> via <gateway_ip> dev <interface> I was able to route the ipv4 traffic over the server, however, routing ipv6 still did not work.
If anyone else reading this has the same issue: In the end, I found it a lot easier to use networking.wg-quick [see PR #53043 for details) instead of networking.wireguard. With it, everything mostly worked out-of-the-box without me having to add any routes manually. I had to change only a few things in my configuration.nix (for example rename ips to address for the interface configuration).
It would be really useful / awesome to have more information on how to set this up in the NixOS Wiki.

I am facing this issue, and used ip route add <server_endpoint_ip> via <gateway_ip> dev <interface> to fix it.
IIRC, openvpn runs this command when you start it, how come wg-quick doesn't do it?

@G-071 @NilsIrl I'm facing this issue myself. When you're describing this command to fix the issue:
ip route add <server_endpoint_ip> via <gateway_ip> dev <interface>

Is this run on the server or the client? Should the server_endpoint_ip be the public IP of the server or the tunnel endpoint?

I'm using good ol' stateful Wireguard interface configuration on my laptop with interactive wg-quick on the command line.  It also didn't work for me but adding this line from the NixOS module to my configuration.nix made it work:
https://github.com/NixOS/nixpkgs/blob/05195accdc596c6c9eadfa7d283d7b780f87f96f/nixos/modules/services/networking/wg-quick.nix#L309

Is this run on the server or the client?

client

Should the server_endpoint_ip be the public IP of the server or the tunnel endpoint?

server_endpoint_ip: the public IP of the server
gateway_ip: the ip of your router
interface: the physical interface, e.g. wlp3s0

@NilsIrl Great, thanks. This may be a bit difficult for me, given I'd like to support mobile devices that may not be able to run commands like that, but I may be able to get it to run on my macOS client.

@G-071 @NilsIrl I'm facing this issue myself. When you're describing this command to fix the issue:
ip route add <server_endpoint_ip> via <gateway_ip> dev <interface>

Is this run on the server or the client? Should the server_endpoint_ip be the public IP of the server or the tunnel endpoint?

The {server ip} as in my suggested update to the wiki https://nixos.wiki/index.php?title=Wireguard&type=revision&diff=5201&oldid=4777
endpoint = "{server ip}:51820"; # ToDo: route to endpoint not automatically configured https://wiki.archlinux.org/index.php/WireGuard#Loop_routing https://discourse.nixos.org/t/solved-minimal-firewall-setup-for-wireguard-client/7577

Is this run on the server or the client?

client

Should the server_endpoint_ip be the public IP of the server or the tunnel endpoint?

server_endpoint_ip: the public IP of the server
gateway_ip: the ip of your router
interface: the physical interface, e.g. wlp3s0
PS: I just realised that dev <interface> is optional and would personally recommend to not specify it.

Should the endpoint route be added by https://github.com/NixOS/nixpkgs/blob/nixos-20.09/nixos/modules/services/networking/wireguard.nix
For my part I will test the use of networking.wg-quick.interfaces instead of networking.wireguard.interfaces for configuring my client and report back if that worksforme.

For my part I will test the use of networking.wg-quick.interfaces instead of networking.wireguard.interfaces for configuring my client and report back if that worksforme.

networking.wg-quick.interfaces worksforme (without setting DNS).  I get DNS via my original non wireguarded IP connection.  A separate topic for me is to understand the best way of handling DNS in a wireguarded environment.

Hello, I've currently tried following both regular wireguard and wg-quick approaches as mentioned in the wiki, is there a tl;dr version to configure the server so that it can allow all IPs? I'm a newbie to all of this and have been scratching at this for a few days now, thanks in advance.

Hello, I've currently tried following both regular wireguard and wg-quick approaches as mentioned in the wiki, is there a tl;dr version to configure the server so that it can allow all IPs? I'm a newbie to all of this and have been scratching at this for a few days now, thanks in advance.

networking.wireguard isn't really meant for "redirect all traffic" usecases, as elaborated in https://github.com/NixOS/nixpkgs/issues/52411. It might change in the future once we get declarative network namespace support through networkd.
However, using wg-quick should work. When it comes to debugging individual setups or server configurations, please ask in the Forums or on IRC, closing this issue.

networking.wireguard isn't really meant for "redirect all traffic" usecases, as elaborated in https://github.com/NixOS/nixpkgs/issues/52411. It might change in the future once we get declarative network namespace support through networkd.
However, using wg-quick should work. When it comes to debugging individual setups or server configurations, please ask in the Forums or on IRC, closing this issue.

running ip route add <server_endpoint_ip> via <gateway_ip> dev <interface> after wg interface is brought up

thanks! here is a snippet
server_ip='....' # your wireguard server address

wg-quick up wg0
# workaround for NixOS
gateway="$(ip route list default | awk '{ print $3 }')"
echo "set gateway: ip route add '$server_ip' via '$gateway'"
sudo ip route add "$server_ip" via "$gateway"
sleep 0.5 # wait for 'ip route add' to take effect

wg-quick down wg0
sudo ip route del "$server_ip"

running ip route add <server_endpoint_ip> via <gateway_ip> dev <interface> after wg interface is brought up

thanks! here is a snippet
server_ip='....' # your wireguard server address

wg-quick up wg0
# workaround for NixOS
gateway="$(ip route list default | awk '{ print $3 }')"
echo "set gateway: ip route add '$server_ip' via '$gateway'"
sudo ip route add "$server_ip" via "$gateway"
sleep 0.5 # wait for 'ip route add' to take effect

wg-quick down wg0
sudo ip route del "$server_ip"


How to use DrupalVM to develop Drush itself?

Issue Type

Bug Report / Support Request

Your Environment
Vagrant 1.8.6
VirtualBox 5.0.26r108824
ansible <IP_ADDRESS>
  config file =
  configured module search path = Default w/o overrides

Your OS

macOS (10.11.6)

Summary
I periodically submit pull requests to Drush, and the workflow for that within Drupal VM is not easy. Where it's installed presently, the code cannot be edited from the host machine (in an IDE) making it very tedious and error-prone to code and test. It would be great if this were easier. The Drush directory, as it is, could be exposed outside the VM somehow, but I think it would be better to add the option to use the Drush instance in the site's vendor directory. That has the benefit that the code in the application repo is the same code that's actually being used in the VM, allowing for easy testing of changes and exposing the active code to the IDE for debugging and correct code completion, among other things.

Heh good timing. #711 makes this possible. As of 3.6.0 (not yet released) f you have drush set as a composer dependency, it will be used rather than the globally installed drush. This only applies to provision and the host drush alias though. If you ssh to the machine and use drush it will resolve to the globally installed drush though.

@TravisCarden - Also note that if you remove drush from installed_extras in 3.6.0+ (or current master), then Drush won't be installed internally at all, and you could clone it yourself as-needed.

Going to mark as closed, as I think we have a couple decent options for this now; use master until 3.6.x is released.


Name Delegation Design Discussion

DNS delegation is the idea that I can own the domain example.com but delegate hosting of my container images to container.hosting. Think MX records, where I have a DNS name that tells me where to send email for a domain without the dedicated special DNS record.
Today, AppC supports a method for doing this type of delegation that uses HTTPS, and HTML meta tags. This type of delegation is inspired by the method used by the go get package management system as well.
One critique of this method is that there is an RFC for this sort of meta information called 'well-known URIs'. I believe that using this type of well-known scheme is a better choice today and will stay out of people's way better; in fact we prototyped this in a project called abd.
FAQ
Why not DNS: If we used DNS it would make it hard to bootstrap trust of this source based on the existing well understood TLS infrastructure on the internet today. With systems like Let's Encrypt in place today I think it would be smart to rely on this existing trust root. We do this in rkt today and it works nicely.
But I have this way better way of doing delegation: We can add additional methods, but having some method to start for delegation is super helpful.
I don't want to allow outbound traffic to the internet: Container engines can allow for this feature to be turned off or configure that certain domains are statically delegated to internal mirrors. This is all about having a default UX.

On Wed, Apr 06, 2016 at 05:15:43PM -0700, Brandon Philips wrote:

I believe that using this type of well-known scheme is a better
choice today and will stay out of people's way better…

I think blob delegation should be outside the scope of the image
format, since blobs that are content-addressed based on a
cryptographic hash can be fetched from any content-addressable storage
(CAS)—although registries probably want to include hints about hosts
providing blobs required by a given image 1.  Baking CAS repository
information into the image manifests requires folks to make
distribution-time decisions at image-creation time (and image authors
and distributors need not be the same people).
 Subject: DNS-based delegation (was: Proposal for a new project: OCI Image Format Spec)
 Date: Sat, 12 Mar 2016 15:34:11 -0800
 Message-ID<EMAIL_ADDRESS>

@wking This isn't about blob delegation. This is about delegation of naming for images. Which is explicitly in scope (see the README).

On Thu, Apr 07, 2016 at 06:47:35AM -0700, Brandon Philips wrote:

@wking This isn't about blob delegation. This is about delegation of
naming for images. Which is explicitly in scope (see the README).

Ah, it's just about discovering manifest hashes.  Developing and
versioning the separate image/naming/signing components 1 in a
single repository sounds complicated to me (do you make a major bump
when you adjust the naming spec, even though you haven't touched the
image spec?).  But discovering manifest hashes using an approach like
this sounds like one of several reasonable registry approaches to me.

@philips Let's make a note here to consider cases such as notary for naming delegation.
Have we decomposed naming delegation to particular set operations?

@stevvooe I don't see how notary relates to name delegation. Do you have a doc?

@stevvooe Ping.

@philips You can read here. The link is fairly straightforward. Let me know if you have more questions.
Perhaps, I am misunderstanding naming delegation. We may need a clear definition and identification specific use cases it solves for the individual user. Part of the crux with naming delegation is that it is great for ISVs and service providers but I'd like to better understand where the user gains benefit. We struggled with our efforts from this angle when we looked into this. If I were, say, a data scientist, why should I have to setup DNS and a web service to deploy software in my local infrastructure?
I do find such strategies as go get or well-known urls to be elegant but getting them reliably deployed can be a nightmare in some organizations (well-known being the clear winner here, perhaps).
We also may want to value offline use cases slightly higher. In typical deployments, there may only be a few organizational mirrors. In the abd examples and some of the proposals we had in this area, it focuses on mirrors in the Internet at large but it seems more likely to have a local mirror, rather than spreading requests across the internet.

Every enterprise I work with wants a trusted repository of data.  This is a model they are very familiar with.  Think rpm/deb repo or Java's maven repos.  How does this name delegation model work for this model?  For example imagine nginx comes from nginx.com.  But in the "enterprise" they want to mirror the images from nginx.com to their local servers such that when a user pulls "nginx" it goes to the on prem repo and not the internet.

Configuration to declare where the mirror is for nginx.com or more likely
'*'. It is just namespaces that has some default useful semantics.
On Thu, Apr 21, 2016, 7:49 PM Darren Shepherd<EMAIL_ADDRESS>wrote:

Every enterprise I work with wants a trusted repository of data. This is a
model they are very familiar with. Think rpm/deb repo or Java's maven
repos. How does this name delegation model work for this model? For example
imagine nginx comes from nginx.com. But in the "enterprise" they want to
mirror the images from nginx.com to their local servers such that when a
user pulls "nginx" it goes to the on prem repo and not the internet.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/image-spec/issues/11#issuecomment-213218303

Does this work today already on rkt or appc?  I'd like to understand more.  I'm trying to wrap my head around this.  The fact that it's model after go is the problem for me.  Go has so many distribution problems where other languages like node and Java don't really.  But the fundamental difference in the two is that node/Java have a centralized de facto store for everything (npm/mvn central).  I have an easier time grasping the idea that name resolution is not decentralized but instead done based on a small set of chosen trusted sources.

@ibuildthecloud Is what you are suggesting actually, technically different than an indefinitely caching proxy with a hand written white list? In that case, such proxys already exist, and no software on OPCs side is necessary. Just set up your "in enterprise" systems to use the companies proxy, and curration and trust management can happen when writting the white list.

Is there room for TUF's delegation notions to get incorporated here? The have a pretty fine grained way of delegating trust for certain packages to different sources, with a well-studied set of security / authenticity guarantees.

On Fri, Apr 22, 2016 at 09:08:29AM -0700, Kamal Marhubi wrote:

Is there room for TUF's delegation
notions to get incorporated here?

Notary [1,2] is a wrapper around TUF.  More notes on that and thoughts
about trust delegation here 3.
 Subject: Signature verification after image-format translation
 Date: Fri, 15 Apr 2016 14:50:18 -0700
 Message-ID<EMAIL_ADDRESS>

On Fri, Apr 22, 2016 at 9:08 AM Kamal Marhubi<EMAIL_ADDRESS>wrote:

Is there room for TUF http://theupdateframework.com/'s delegation
notions to get incorporated here? The have a pretty fine grained way of
delegating trust for certain packages to different sources, with a
well-studied set of security / authenticity guarantees.

Namespaces in TUF and in particular Notary can use a DNS form.
Here is a concrete example from the docs:
https://github.com/docker/notary/blob/master/docs/getting_started.md#understand-notary-naming

Here are the three use cases as I see it:

User doesn't care at all about name delegation, they use an existing registry for all images (e.g. gcr.io/brendanburns/foo, gcr.io/brendanburns/bar, ...)

User is running inside their own data center, doesn't trust anyone, doesn't want to go outside their LAN.  In this case user still doesn't care about delegation, but they run their own registry and push all images their:  (e.g. my-registry.internal/foo, my-registry.internal/bar)

Neither of those two care about name delegation.  The interesting middle use case is when someone wants to establish domain based policy (e.g. 'you can only run images from my-company.com) but doesn't want to run their own registry.  In that context, they want their end-users to pull my-company.com/bar/foo but have that image actually be hosted on my-company.com.gcr.io/bar/foo
it seems to me that there are two questions here:

How do you securely get/set the mapping from my-company.com to gcr.io?

Options here appear to be DNS CNAME records, or a well-known URI

Can you manipulate the rest of the image path?  If so how?

I think the answer here should be "no" the risks are just to big and the win is minimal.

@brendandburns To clarify, are you saying that the user should be able to configure the naming authority for my-company.com? If a user pulls, my-company.com/bar/foo and gets my-company.com.gcr.io/bar/foo, what is the name of the resulting image?

Can you manipulate the rest of the image path? If so how?

I think the answer here should be "no" the risks are just to big and the win is minimal.

We can agree, here. Allowing remotes or local to manipulate paths quickly gets out of hand.
Put differently, if we expressed naming as a function f(name) -> y, what is the type of y? Can we express the naming problem in this manner?

@stevvooe the name of the image is still my-company.com/bar/foo just like if you visit www.company.com and it CNAME's to storage.googleapis.com your browser still shows www.my-company.com in the URL bar.

@stevvooe put another way, this all happens in the DNS subsystem, so the client code pulling the image doesn't even notice.  They just see my-company.com resolve to <IP_ADDRESS> which happens to be the IP for my-company.com.gcr.io

On Wed, Apr 27, 2016 at 3:27 PM Brendan Burns<EMAIL_ADDRESS>wrote:

The interesting middle use case is when someone wants to establish domain
based policy (e.g. 'you can only run images from my-company.com) but
doesn't want to run their own registry. In that context, they want their
end-users to pull my-company.com/bar/foo but have that image actually be
hosted on my-company.com.gcr.io/bar/foo

Yes, exactly.

it seems to me that there are two questions here:

How do you securely get/set the mapping from my-company.com to gcr.io?

Options here appear to be DNS CNAME records, or a well-known URI

CNAME doesn't work if you want TLS delegation to be "secure", right?
I think of delegation based on DNS/well-known URI as a "globally
distributed default". If you want to override the default you need to
configure that policy at a cluster/machine level, similar to download
credentials.
Depending on the language we come up with here it will look like something
like this:
"delegationOverrides": [
 {
    "name": "example.com/*",
    "mirrors": ["gcr.io"]
 },
 {
    "name": "quay.io/*",
    "mirrors": ["gcr.io"]
  }
]

Can you manipulate the rest of the image path? If so how?

I think the answer here should be "no" the risks are just to big and the
win is minimal.

+1 the entire name should be sent to the delegating party.

It seems to me that TLS should be fine, as long as the thing you are delegating to holds the cert for the original registry.
I think there are two cases to consider (and maybe this is the source of confusion) there is the pure delegation case: "I don't have a registry, but I want a vanity domain" and the mirror case "There's some registry out there, but for various reasons, I want to actually access those images at some other mirror location".
I was really mostly thinking about the former.  The mirror one is sort of interesting but doesn't seem like a server-side protocol, but rather a client-specific configuration.

It seems to me that TLS should be fine, as long as the thing you are delegating to holds the cert for the original registry.

I don't see how we can dismiss TLS here. We still need to provide secure connections to both the white label domain and the upstream. They may be different.
How can this happen at a pure dns-level if the primary and delegate domains may have different implementations and certificates? If it really is just pure DNS, why not just tell users to use a CNAME and be done with this? If it really is just CNAMEs, do we even need to specify anything?

@stevvooe I'm not dismissing TLS.   The CNAME option would involve a user defining a whole subdomain (e.g. registry.mycompany.com) creating a new different cert just for that subdomain, and storing that cert with their registry provider.  And then CNAME over to the registries DNS, (similar to the flow here: https://www.keycdn.com/blog/cdn-ssl-made-easy/)
I think the goal in the spec is to design the best practice for how it would work, so that implementors know what they need to build (e.g. an interface that accepts a cert), even if the actual mechanism doesn't require an implementation.
Anyway, CNAME is one of the two options.  A well-known URI is the other option.  I tried to list the pros and cons of each in my earlier post
I think that the best effort in this issue is to decide which option is preferred by the maintainers.
If it is easier for me to put the options and pros/cons into a markdown doc and have the discussion in a PR, I can do that too. (and if I missed any pros/cons let me know)

@brendandburns I see. Sorry about the harsh wording here.
How is this different from using TLS with a CNAME as one normally would? It sounds like a very standard usage. Am I missing something? Why does it need to specified? Seems like it belongs in recommendations or best practices.
As an interesting data point, I have suggested this approach situations looking "spruce" up the registry urls. Typically, this is easy if you host your own registry. The problem arises when using providers such as AWS ECR, Docker Registry and GCR (please correct me if I am wrong). They would have to host a private key for each domain. Would such a provision push a requirement for services running a registry to accept certificates to use for white labeling?

@stevvooe
In my mind, hosting keys isn't really a challenge for most cloud providers, since they already have to do it in order to terminate SSL for their load balancers.
Regarding spec. versus best practice, I guess the point is that this issue says: "define a spec" if we decide that CNAME is what we would suggest then we'll just close this issue as "done" ;)

In my mind, hosting keys isn't really a challenge for most cloud providers, since they already have to do it in order to terminate SSL for their load balancers.

In principal, but are any registry providers currently offering this? I couldn't find it in gcr or ecr and I don't think Docker Hub has it either.
Either way, I am not sure that CNAME is an interesting case. It sounds like more interesting topic is decoupling naming from location.

Is there some technical reason why this discussion is termed "name delegation" and not "discovery?"   It seems so much simpler if we talk about discovery.  That is just defining a process of looking at X, Y, and Z in some specific manner.

In my understanding, name delegation and discovery are two related
processes, and one is harder than the other ;). Name delegation is the
science of creating unique identifiers, it typically requires either
centralization or randomness. In the DNS system, name delegation is
centralized, when you create a new domain name, you reserve it in a
central registrar. However, DNS lookup (aka discovery) is
de-centralized, you typically use the DNS server provided to you by your
ISP, and indeed, there is no way to even access the central registry for
most devices.
I think that both problems are interesting, though I feal name
delegation is FAR FAR FAR more vital in terms of "lets not f--- this
up", as it is much harder to change and fix after the standard is published.
On 04/29/16 04:19, Darren Shepherd wrote:

Is there some technical reason why this discussion is termed "name
delegation" and not "discovery?" It seems so much simpler if we talk
about discovery. That is just defining a process of looking at X, Y,
and Z in some specific manner.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/image-spec/issues/11#issuecomment-215612525

@stevvooe CNAME is one way of decoupling naming from location.  It's a way of saying: "for this location, the canonical (that's the 'C') location is this other location over here"
and though no one currently provides it, it seems that the point of developing a specification is to encourage providers to add support.
Again, in my mind there are two options with the pros and cons outlined above.  Though personally I prefer the CNAME solution, it seems like the purpose of this issue is to get to a "(dis)agree and commit"
I'm not sure what the process is for that.  Shall we just have a vote?

@brendandburns Yes, the purpose is to get to a solution and commit. Ping the other maintainers: @jonboulle @jstarks @jbouzane @vbatts to chime in on how they feel. If you are coming new to this thread see @brendandburns excellent write-up on pros/cons of various options for name delegation.
Also, paging @josephschorr from the Quay.io team as well as we have considered this feature for quite some time (we called it "white label").
Personally, I am leaning towards well-known as it gives a "zero trust" sort of model to delegation. It is also is used by other "modern" internet plumbing stuff like OpenID Connect.

@brendandburns, @stevvooe: Speaking just from the perspective of the registry, as @philips alluded to, we've considered the idea of "white labeling" via CNAME for some time. The original goal was to allow name owners (e.g. "redhat.com") to delegate pulls from their own domain to Quay, such that docker pull cooldomain.com/someimage would be rewritten as docker pull quay.io/someorgforcooldomain/someimage. We quickly realized that there were two major issues with doing so:

It wouldn't really work for the top-level domains when used for the internet as a whole, which means that a subdomain would have to be used (e.g. "docker.cooldomain.com")
We'd have to store private keys as all our traffic is SSL terminated.

The SSL issue in particular is the reason we did not move forward, as storing private keys on behalf of a variety of users is a concerning proposition. Well-known has the nice benefits of working with top-level domains and not requiring us to store keys, so we'd prefer that route from our perspective. It also has the nice added bonus of allowing domain owners to choose dynamically to serve different images from different registries.

@philips I still think we need a solid problem definition before moving forward. I'd still like a solid answer to, if we represent naming delegation as a function f(name) -> y, what is the type of y? The reason I ask it in this format is that for well-known vs CNAME, the type of y may be very different. In the well-known case, y could be a fairly wide set of protocols and locations. With CNAME, the type of y is just another address and the client is left to resolve the target protocol.
This brings other questions. Is f configurable? Can name be transformed before passing to f?

On Fri, Apr 29, 2016 at 12:08:51PM -0700, Stephen Day wrote:

… if we represent naming delegation as a function f(name) -> y,
what is the type of y?

Labels to all the steps would be nice.  In the beginning, you have
something like ‘cooldomain.com/someimage’.  In the end you have a CAS
hash from which you can unpack the bundle (see also #23).  It sounds
like things folks have discussed are:

metadata_interpolate(name, platform_information) -> URL 1
cname_redirect(URL) → URL 2
well_known_redirect(URL) → URL 3
local_mirror(name?) → URL? 4

At what point does this turn into CAS requests for pulling the actual
image?  And if those CAS requests are over HTTP, where are they sent?

@stevvooe @philips
I think the problem definition is
func getNamespaceDelegate(originalName DomainName) (DomainName, error)

where an IP address is a degenerate domain name.
I see no reason not to do anything else.
There may be a bigger type (e.g. []Mirror) used to implement that function, but that's what the function is.

On Mon, May 02, 2016 at 09:40:16AM -0700, Brendan Burns wrote:

func getNamespaceDelegate(originalName DomainName) (DomainName, error)

If your initial image name is ‘cooldomain.com/someimage’, I'm guessing
‘cooldomain.com’ is what you're feeding this function.  Are you
requiring DNS- or IP-based names for all images and not supporting
names like ‘debian’?  Or are those names allowed, and they just don't
get namespace delegation?  And how is the resulting DomainName tied
back into CAS resolution?

Personally, I think we need to require well-formed domain names.
Both of the methods discussed so far (either DNS or a well-known-URI) require a domain name that is resolvable.

On Mon, May 02, 2016 at 09:49:26AM -0700, Brendan Burns wrote:

Both of the methods discussed so far (either DNS or a
well-known-URI) require a domain name that is resolvable.

For DNS-based delegation, sure, but DNS-based naming and delegation is
optional 1.  The overall name-resolution problem is to go from a
container name (whatever format) to a CAS hash.  In [2,3] I sketch out
name → CAS hash in a generic:
registryLookup(name, trustStore) → (CAS hash, error)
format, and having more clarity on how this optional DNS-delegation
layer fits into that bigger picture would be helpful.
 Subject: Re: [oci-tob] Proposal for a new project: OCI Image Format Spec
 Date: Tue, 1 Mar 2016 14:00:06 -0800
 Message-ID<EMAIL_ADDRESS>
 Subject: Re: [oci-tob] Proposal for a new project: OCI Image Format Spec
 Date: Tue, 1 Mar 2016 21:29:47 -0800
 Message-ID<EMAIL_ADDRESS>

I guess my view on this is that they are two related, but independent problems.
In my mind, here is how they go together:
Basically registryLookup(...) in your above requires the name of an actual, functioning registry.
Whereas getNamespaceDelegate just requires a registry name (which may be an alias)
So the code looks like this:
var originalName DomainName

resolvedName := originalName
for {
  newName, _ := getNamespaceDelegate(resolvedName)
  if newName == resolveName {
    break
  }
  resolvedName = newName
}
hash, _ := registryLookup(resolvedName, trustStore)

On Mon, May 02, 2016 at 10:12:42AM -0700, Brendan Burns wrote:

Basically registryLookup(...) in your above requires the name of
an actual, functioning registry.

I was imagining users could configure their client to use a number of
registries, over a number of registry protocols.  Then the client
could check them all (“Registry1, have you heard of image ‘debian’?
No?  Registry2, have you heard of image ‘debian’?  Ah you have three
images called ‘debian’.  It looks like I only trust the second and
third, and the third is newer, so off to the CAS engine to resolve
sha256:ca6e…”).
But yeah, clients would have to have registry configuration trasmitted
out-of-band.

So the code looks like this…

Ok, so this is optional pre-processing for image names that look like
domains.  That sounds good to me, and explains why the delegation
functions are domain/IP → domain/IP mappings.

hrm, I kind of strongly believe that all images are the combination of the (registry, image-name) tuple.  e.g. an image named debian shouldn't exist, there is an image named debian.org/debian
For the purposes of trust, this means that either:
Owner delegated trust (aka, registry aliases)
I trust debian.org and debian.org delegates trust to gcr.io via either of the mechanisms described  above.
or
User delegated trust (aka corporate mirrors)
I explicitly configure the client to say "I trust debian.mycorpmirror.org for debian.org or alternately, I trust mycorpmirror.org for *

On Mon, May 02, 2016 at 10:59:16AM -0700, Brendan Burns wrote:

hrm, I kind of strongly believe that all images are the combination
of the (registry, image-name) tuple…

I disagree, but this level of trust discussion should probably happen
in #22.  For the purpose of DNS-based delegation, we agree that you
need an initial domain name associated with the image to seed the
delegation algorithm.

@brendandburns The problem with assuming that an image is an (registry, image-name)-tuple is that we couple naming to the registry, we couple trust to the registry. The ideal setup for this is to ensure that degian.org/debian is the same where ever it comes from, given the same configuration on a client. If trust is delegated to gcr.io, an image named gcr.io/debian.org/debian shouldn't pop up somewhere. Only debian.org/debian should exist.
But this is part of my concern for including naming and transport in an image specification: once we start talking about any of these, we must start talking about trust. While I understand the reasoning in including these, it feels like including TLS in the HTML specification.

@brendandburns BTW, thank you for the functional description. This can help to ensure we are discussing the same approach.
Abstractly, we can say the function looks like this:
func resolve(name string) (Location, error)

Where Location can be either an alias or concrete location.

Personally, I think its important that name is a resolvable domain name, so I'd rather have some type other than string in there, but other than that, yes, that seems correct.

@stevvooe I guess I just fundamentally disagree. the domain name in the image name isn't a registry, its a namespace.  We may ultimately resolve the domain name, and try to find a registry, but calling it a registry in this context confuses what we are trying to achive.
I shouldn't even go looking for debian.org/debian anywhere unless either:
a) debian.org delegates trust to some other registry
b) I (or my admin) have explicitly configured a mirror in my client config.
I don't think that we want random registries around the world serving images that they grabbed from other locations without those locations explicit consent.

@brendandburns I'm not sure how you can disagree with your own assertion:

hrm, I kind of strongly believe that all images are the combination of the (registry, image-name) tuple.

Based on what you've said, I'm also confused as to how you can disagree with the following:

The problem with assuming that an image is an (registry, image-name)-tuple is that we couple naming to the registry, we couple trust to the registry. The ideal setup for this is to ensure that degian.org/debian is the same where ever it comes from, given the same configuration on a client. If trust is delegated to gcr.io, an image named gcr.io/debian.org/debian shouldn't pop up somewhere. Only debian.org/debian should exist.

Why should debian.org be responsible for debian.org's trust? Shouldn't it be up to the client to decide who to trust if they want to trust debian.org? Why should "trust" be delegated to the registry?

@stevvooe
I'm in favor of both (hence the a) and b) in the previous comment) but I believe that the default should be that the trust is placed in the domain name.
For better or worse, domain names are the entities that hold the root of trust in our world.  By default, if I see an image that is google.com/foo I'm going to assume that Google is responsible for that image, and therefore it seems to me that the google.com domain name should be responsible for the trust (or the delegation of the trust), since Google/google.com is on the hook for the reputation of the image.
Users should be able to override who they trust (that's the part b) in the above) but it should definitely be an explicit, client side action for example, I could imagine a "mirror config" for a client that looks like:
{
   "mirrors": [{
         "host": "google.com",
         "registry": "gcr.io"
    },
   ...
}

which explicitly says that the client should map google.com to gcr.io in the resolution step above.
Importantly, I expect this kind of configuration to be the exception not the rule.

On Mon, May 02, 2016 at 01:25:19PM -0700, Brendan Burns wrote:

For better or worse, domain names are the entities that hold the
root of trust in our world.

The X.509 hierarchy based on some assumed-responsible CAs is fine, and
a reasonable choice for a number of workflows.  But I don't see a need
to require it in the spec.  For example, if I know the publisher (say,
because I work with them) and I trust their OpenPGP key, I don't see
why I wouldn't trust name↔hash assertions signed by that key.  There's
no reason why an OCI verification framework couldn't support both
OpenPGP and X.509 signatures, so why force the latter?

Hrm, I really think we're conflating two issues:

is who do I trust for name to hash resolutions, and in that context, I 100% agree that if I trust a registries keys, its fine for me to trust their name to hash regardless of whether then name matches their domain name or not.

how do resolve a (possibly aliased) image name down to a concrete image name.

This issue is concerned with 2.
I don't think we want to make name resolution be part of what a registry does, I think we want to do all of the name resolution first, and then go to one or more registries for the name to hash mapping using the fully resolved image name.

On Mon, May 02, 2016 at 01:35:29PM -0700, Brendan Burns wrote:

how do resolve a (possibly aliased) image name down to a concrete image name.

This issue is concerned with 2.

Both of those issues should be covered by the trust model.  Otherwise
a malicious agent could abuse the image-name canonicalization to point
folks at the “wrong” canonical name.

then go to one or more registries for the name to hash mapping using the fully resolved image name.

This delegates still delegates the trust model to the registry.
The problem comes when working with multiple registries. Which keys do you trust when they disagree? The only way to manage this is centralization. One approach is to partition the namespace with DNS.
I am not sure that one can honestly separate naming and trust models without redundancy and ambiguity. Can this be done without making such separate systems completely incompatible?

On Mon, May 02, 2016 at 01:47:24PM -0700, Stephen Day wrote:

The problem comes when working with multiple registries. Which keys
do you trust when they disagree?

For example, if the registry (or registries, it doesn't matter) has
two name→hash associations that disagree on the hash, and one is
signed by Alice, and another is signed by Bob, and I trust both Alice
and Bob, then I'll use the newer association.  If Alice or Bob is
doing that maliciously, then the solution is to remove them from my
trust store, not to delegate all trust to a single registry.
With the X.509 trust delegation, maybe a debian.org/debian→hash
assertion is signed by a key with a debian.org cert backed by some-CA.
If that sort of thing is in my trust store, then I'll pick the newest
association signed by that key (or any other similar keys supported by
my trust store).  So I still don't see a need to centralize at the
registry level.

Perhaps I'm missing something (and I apologize if I do), but wouldn't the ultimate trust model still consist of having the image pulled being signed by a recognized public key? That way, even if it is served by gcr.io/debian, I can still verify it is the Debian image by either transporting the Debian key manually or out-of-band (which is what Notary does)

On Mon, May 02, 2016 at 03:26:19PM -0700, josephschorr wrote:

… wouldn't the ultimate trust model still consist of having the
image pulled being signed by a recognized public key?…

Yeah, I think end-to-end signing is important.  Which is why I think
@brendandburns name canonicalization ((2) in 1) needs to be covered
by the trust model 2.  In other words, I should be able to fetch a
‘debian.org/debian’ image from gcr.io/debian.org/debian (or a local
file, #23, or wherever, it shouldn't matter) and still be checking
my local trust store to see if I trust the signers to sign the
‘debian.org/debian’ image.  That shifts the earlier deconstruction 3
to:
func RegistryLookup(name string, trust TrustStore) (hash string, error)
{
var registry = name;
for (looksLikeDNS(registry)) {
  var resolvedName, _ := getNamespaceDelegate(registry);
  if (resolvedName == registry) {
    break;
  }
  registry = resolvedName;
}

return registryLookup(name, registry, trust)

}
where registryLookup is performing the name (e.g. debian.org/debian)
→ hash lookup and verifying signatures using keys trusted to sign
‘name’.  ‘registry’ is just a hint in case registryLookup wants to ask
that domain (e.g. gcr.io), but it could also just ask a local
registry, etc., etc.
The earlier deconstruction 3, on the other hand, was fetching the
resolved name (e.g. gcr.io/debian.org/debian) from the registry,
which means that the canonicalization (or “name resolution”, or
whatever you want to call debian.org/debian →
gcr.io/debian.org/debian) was untrusted (or trusted independently
based on your X.509 trust used implicitly inside
getNamespaceDelegate).  This sounds much less reliable (or at least,
it's harder to reason about).

I will re-iterate, there are really two different issues here:

I want a name for my image based on my domain (mycompany.com/foo) but I have no intention of hosting my own registry.  I should have the ability to redirect you to a registry so that you can know where to get the image.  This is name resolution.

There is mirroring, which is I am registry a.com but I want to host image that originate at b.com/bar such that if you ask me for that image, I can deliver it, and you (because you trust my signing) know that it is the same image that a.com would have shipped me.

I think that this issue is concerned with 1, not 2.
There is definitely trust involved in name canonicalization, but I think that we have to require that the trust is implemented by having the owner of the domain (mycompany.com) own name canonicalization.
The reason for this is that it is otherwise very difficult for me (as an image owner) to change the canonicalization of the name (say I switch from mycompany.com -> a.com to mycompany.com -> b.com.

On Fri, May 06, 2016 at 10:57:51AM -0700, Brendan Burns wrote:

There is definitely trust involved in name canonicalization, but I
think that we have to require that the trust is implemented by
having the owner of the domain (mycompany.com) own name
canonicalization.
The reason for this is that it is otherwise very difficult for me
(as an image owner) to change the canonicalization of the name (say
I switch from mycompany.com -> a.com to mycompany.com ->
b.com.

This assumes:

That X.509 certificates based on a shared CA pool let folks agree
on which keys can sign for mycompany.com.
That images named with a {host}/{other-stuff} pattern belong to
the keys from (1).

Both of those are reasonable choices for an implementation and are
probably requirements for DNS-based delegation, but I don't think they
should be requirements for all name→CAS implementations.  For some
systems there's no need to drag in X.509 at all, and I think we want
to support those systems too.

Hrm, I think all of the signing stuff is out of scope for this issue.  In my mind there are two ways that we establish trust:

I use DNSSEC to ensure that the DNS resolution is trusted.
If we use well-known URIs, then we also use standard HTTPS CA certs to ensure that I trust the data I receive from that well known URI.

People who don't want this can use IP addresses for their registry prefix, which inherently will skip name resolultion.

On Fri, May 06, 2016 at 11:16:46AM -0700, Brendan Burns wrote:

People who don't want this can use IP addresses for their registry
prefix, which inherently will skip name resolultion.

And folks who are using a sneakernet and OpenPGP?  I agree that lots
of folks are going to be distributing images over HTTPS involving
their usual DNS and X.509 trust, but I'd rather that wasn't the only
naming/signing scheme that this specification supports.  For example,
the #23 use case (project publishing its application), it would be
nice if step 1 for pushing verifiable content wasn't “get a domain and
have a well-known CA certify your ownership of such”.  Lots of
projects are already pushing OpenPGP-signed tarballs and Git tags, so
allowing OpenPGP signing for images (without DNS-based namespacing)
would make life easier for them.

@wking in that case they can use any name they want, and then install the appropriate mirror definition in their clients.
This is why I think there are two different issues getting smashed around here.
One is discovery/naming: how do I go from the name of an image to an actual place where I can get a bunch of file hashes.
The other is trust: I have this collection of tarballs, how do I assert that they are the thing that I think they are and that they are sourced from a source I trust.
In your use case, name resolution and discovery aren't necessary.  You already have the files in a tarball.  Only the trust part is needed.
But for most users that isn't the way they will interact with images.
And for people who distribute images but don't want to get a domain name there are always the existing hosted registries (e.g. gcr.io)
I could imagine defining some sort of null registry localhost? which basically means "There is no corresponding registry"

On Fri, May 06, 2016 at 02:04:54PM -0700, Brendan Burns wrote:

This is why I think there are two different issues getting smashed
around here.

I agree that there are at least two issues, I just don't want to see
resolution for one (DNS-based delegation) negatively impact another
(naming and trust).

And for people who distribute images but don't want to get a domain
name there are always the existing hosted registries (e.g. gcr.io)

With that approach, how will folks sign/verify gcr.io or localhost
images?

@wking
So my thought is that you would sign with your keys prior to uploading the image to the registry, but I haven't thought super deep about the signing problem, since I think its different than name resolution, and I've focused name resolution for this issue.

On Thu, May 19, 2016 at 10:18:18AM -0700, Brendan Burns wrote:

… but I haven't thought super deep about the signing problem, since
I think its different than name resolution, and I've focused name
resolution for this issue.

I think signing is going to be inseparable from name resolution.
There needs to be clarity about which name is being verified 1, and
if it's not the user-supplied name (e.g. it's a canonical version),
there needs to be clarity on the trust model for the canonicalization
2.
On the other hand, signing should be orthogonal from distribution.
So a client should be able to fetch the image from any provider (a
CNAMEd host, local mirror, email attachment, etc.) and still be able
to verify that the image has the name you're looking for.  For example
(based on 3):
$ oci-image-tool unpack path/to/my-oci-image.tar.gz debian-1.0
which unpacks the image whose name matches debian-1.0 after checking
that the debian-1.0 entry is appropriately signed.
$ oci-image-tool unpack https://gcr.io/brendanburns/foo mycompany.com/foo
which unpacks the image whose name matches mycompany.com/foo after
checking that the mycompany.com/foo entry is appropriately signed.
With that orthogonal signing in place, how you get from a
user-specified mycompany.com/foo to a fetching location (e.g. a
https://gcr.io/brendanburns/foo mirror) doesn't matter much to me.

@wking
I think we agree.  I view name resolution as being solely about figuring out where to download the thing from.
The name that you use for validating signing is still the original name.
Put clearly in an example:
I start pulling company.com/bar/foo which redirects me to the company.com.gcr.io/bar/foo registry, I download the layers from that registry.
But then once downloaded, I verify the images using the original name mycompany.com/bar/foo and using keys that are distributed by that company.
Make sense?

On Thu, May 19, 2016 at 12:34:05PM -0700, Brendan Burns wrote:

But then once downloaded, I verify the images using the original
name mycompany.com/bar/foo and using keys that are distributed by
that company.

Sounds good to me, although it sounds more like the pseudo-code in 1
and text in 2 than the pseudo-code in 3 or text in 4.  And if
the original name is still being used (which I like), I think the
redirecting is better described by “mirroring” 5 than by
“delegation” 6 or “canonicalization” 7.  And there's no need to
worry about key hosting 8 or the security of a particular sub-step
(like mirror choice) 9.
And with this optional mirror-lookup procedure, I want to make sure
non-DNS image names are still supported 10.  They wouldn't get this
DNS-based mirroring, but there are many other possible mirroring
approaches.
And I am absolutely fine with folks mirroring any image they have
legal access to.  With the image name being a property of the image
that's independent of mirroring, I don't see why you'd have a problem
with that 11.

I guess I think:
if the owner of the name choses the remapping then it is "delegation" since there no other locations where that image can be found.
if the owner of the client chooses the remapping then it is "mirroring" since it is copied from wherever the original source is located.
but it's semantics, I guess.  If we have rough agreement on the goals, do we have a preference for DNS or well-known URL?  (or both?)

On Thu, May 19, 2016 at 02:09:02PM -0700, Brendan Burns wrote:

if the owner of the name choses the remapping then it is
"delegation" since there no other locations where that image can be
found.

How many images are licensed “all rights reserved”?  I'd guess for
things like Debian images, you could have third-parties choosing to
mirror images as they see fit, although the original author is always
free to bless (or not) those mirrors as they see fit (e.g. they can
say “a.example.com and b.example.com also carry this image”, while
c.example.com and d.example.com are serving copies as well).

If we have rough agreement on the goals, do we have a preference for
DNS or well-known URL?  (or both?)

I don't care once things get down to this level.  I just get jumpy
when folks start talking about requiring DNS-based names ;).

@wking I think we should require dns compatible names.  whether the domain actually exists or not is up to the end user.

On Thu, May 19, 2016 at 02:31PM -0700, Brendan Burns wrote:

I think we should require dns compatible names. whether the domain
actually exists or not is up to the end user.

What's the benefit to requiring DNS-based names but allowing
nonexistant domains?  I explained why I want X.509 to be one option
among many for image trust earlier [1,2].  You floated localhost-based
naming earlier 3, but I think we agree that you won't be using an
X.509 certificate chain [4,5], because no CA will certify you as the
owner of ‘localhost’ (I hope ;).  And if you're using OpenPGP or
similar, the name is an opaque string as far as trust is concerned.
So folks intending to use DNS-based mirror discovery should be using
DNS-based names (with valid domains) 2.  But I don't see how you
benefit from having ‘localhost/my-app-v1.0’ instead of my preferred
‘my-app-v1.0’ as an image name for folks who don't need DNS-based
mirror discovery.

We have been discussing naming for quite some time but I would like to propose to the @opencontainers/image-spec-maintainers that we move this to the post-v1.0.0 milestone for two reasons:

Naming is an "optional layer" for the specification scope. We have moved the other "optional layers" out such as signing in #22 to post-v1.0.0 as well so we can focus on the initial release being the required layers.

We all have a really solid idea of how this will work using well-known URIs and pointing at a registry that implements the v2 CAS API. But, we should focus on getting those registry transports working first before we add a layer on top. I know a variety of the registry implementations at Google, Amazon, and Quay.io have this on their roadmap.

We can discuss during the call tomorrow or here. If you are ok or not ok moving to post-v1.0.0 speak up below.

I still want this idea. It was one of the earliest topics, and lengthy discussion.
Keeping this in the milestone "post-v1.0.0" and not closing, though there may be merit in opening a new issue with concise overview.
Particularly, now that there are multiple choices of public registries, including running your own, but having an on-premise registry that is not just a pull-through-cache, which can serve up an identified image, which a verifiable author of said content.


feat: tenant ecosystem management

Fixes https://github.com/didx-xyz/aries-cloudapi-python/issues/176
Fixes https://github.com/didx-xyz/aries-cloudapi-python/issues/157
Fixes https://github.com/didx-xyz/aries-cloudapi-python/issues/186
Fixes https://github.com/didx-xyz/aries-cloudapi-python/issues/176
Fixes https://github.com/didx-xyz/aries-cloudapi-python/issues/185

Ok addressed your feedback. Please let me know if you see anything else that needs changing :)


Can't remove bold from several color names when using bw base scheme

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf
[x] I have searched through the existing issues

Info

OS

[ ] Linux
[x] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[x] bash
[ ] zsh
[ ] fish

Problem / Steps to reproduce
When you use bw as the base scheme, there are several color names that you can't remove the bold ansi attribute from.
I have checked my environment variables, and FZF_DEFAULT_OPTS is not set. Reproduced on macos 13.2.1 using fzf 0.38.0 installed via homebrew. I have replicated the issue using both iTerm.app and Terminal.app as terminal emulators.
$ echo "line one\nline two\nline three" | fzf --color='bw,query:regular,fg+:red:regular,hl+:green:regular'

At the query prompt, type li.
I observe that the bold attribute is still applied to the query, the text of the current line (fg+), and the highlight on the current line (hl+) as shown here in iTerm:

and here in Terminal:

I also observe that by changing the base scheme to dark, or omitting the specification of the base scheme from the --color specification, thereby causing fzf to use the default of dark on my true color terminal, that the regular ansi attribute appears to work properly, ie it disables bold.

Thanks for the report. An easy workaround at the moment is to use --no-bold option, which prevents "boldification" of any element.
fzf --color=bw --no-bold

https://github.com/junegunn/fzf/blob/d7daf5f72411f29eca3ab398c7a8a951ca230cad/src/options.go#L2002-L2019


Typing < (less than) introduces a pause and the cursor is placed before it

Description
This seems to be a visual bug. This seems to happen anywhere. If you type the first character of a pair, the pair is completed and you are in the correct position...it's still a little annoying though and I would like to know if I could fix it. Commenting this plugin out in my config removes this issue.
Mapping  bug

Steps to reproduce

Minimal config
I am just using the most basic lazy.nvim config from the README. I'm using nvim-cmp.

This is not an autopairs issue. I played with my config more and realized that I had a mapping for nvim-cmp like so:
['<C-b'] = cmp.mapping.scroll_docs(-4),
notice the missing > for the key...lol. my bad on this, closing. Could have swore commenting this plugin out fixed it...but I guess I instead stashed my changes or something which included these keymaps.


ui-comp dialog select/multi-select assumes correct styling

So this spawned from an observation made over here: https://github.com/ManageIQ/ui-components/pull/266#issuecomment-372790492
tl;dr - dialog selects are broken on master, this work fixes them
This work restores the odd voodoo combination of relying on bootstrap/select from ui components
This work rolls back jquery, which introduces a bug rendering selects kinda useless
This work updates ui-components to a version with dialog select that supports pf4
Looooooook it works now

Can confirm both single-select and multiselect look good with this one :).
But... something's indeed fishy.. If I remove yarn.lock and yarn again, it stops working completely, back to the browser version, and error in the console.
So.. I'm thinking something in yarn.lock either doesn't quite match package.json now, or we still haven't nailed some dependency down properly.

oh curious... ok... will look into that...

Thanks.. I tried picking just some changes in yarn.lock and not others, but half the time when trying I get an error about not being able to find bootstrap.. So IDK.
If you don't find anything, maybe we can just merge, and hope it doesn't break again, but .. feels like there's a surprise lurking still :)

OK sooooo maybe your yarn.lock was showing its age? in sore need of a rebuild 🤔
deleted it... reinstalled, everything looks good, 's that was done was restore the updated jquery version... but maybe it cleaned out some odd collisions that was happing ? not entirely sure... but give this a try...

Confirmed this is now behaving consistently :) yarn ; yarn start .. it works :), rm -rf node_modules yarn.lock ; yarn ; yarn start .. it still works :).
Also, fixes the bug .. merging :)


Documentation: leftovers on https://ammonite.io from before removal of ammonite-shell

Searching the page still brings up occurrences of removed patterns from ammonite-shell, like ls! (9 hits) || (7 hits)

Yes, would be nice if these were removed from the docs. I installed Ammonite a few months ago, and like once a week I'll try to use if for something --> I try shell commands --> they don't work --> I think "well I guess it's broken" --> I stop using it.

These need to be updated, yes. Feel free to submit PRs to remove those.


[python3] about_iteration.py

So there's this function in about_iteration.py which is supposed to calculate a number from the Fibonacci sequence, judging from the name of the variable. But instead it just adds up the numbers in range (1,6):
def test_iterators_are_a_type(self):
    it = iter(range(1,6))

    fib = 0

    for num in it:
        fib += num

    self.assertEqual(__ , fib)

So fib = 0 + 1 + 2 + 3 + 4 + 5 = 15

The variable has a bad name, your right. To me the test works fine. You have a iterator and you use a for statement to iterate over it.
    for num in it:
        fib += num

Maybe changing the name from fib to sum will make this test cleaner. The fibonacci sequence doesn't use the index explicitly, and making this loop to return a fibonacci number will imply a big refactor, so I vote for changing the variable name to a better one.

Agreed. Anyone want to PR it?


Refactor feature extraction key

Description

All backbone/feature extraction keys are now in

model:
    feture_extractor:
        backbone:
        layers:

FeatureExtractor selects timm or torchfx based on the parameters passed to it.
This PR ended up way bigger than I thought 😃

Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] Refactor (non-breaking change which refactors the code base)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist

[x] My code follows the pre-commit style and check guidelines of this project.
[ ] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing tests pass locally with my changes

Is there a github discussion/issue from which one can read why
"TimmFeatureExtractor will be removed in the future version."

?

Is there a github discussion/issue from which one can read why
"TimmFeatureExtractor will be removed in the future version."

?

@jpcbertoldo, we have recently spotted that timm feature extractor provides inconsistent results, which overall adversely impact the performance of the models. We therefore decided to use torchfx feature extractor

Is there a github discussion/issue from which one can read why
"TimmFeatureExtractor will be removed in the future version."

?

I've gathered our motivation here https://github.com/openvinotoolkit/anomalib/discussions/779


Update to release 0.2.0

Also update xarray and attrs mininum version required

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Table column with Json column value bug

Package
filament/tables
Package Version
v2.1
Laravel Version
v8.75
Livewire Version
No response
PHP Version
PHP 8.1.3
Bug description
I have a RelationManager named RelationsRelationManager that connects with a branch_relations table.
This table has a json column fees.
Although the form works fine and I am able to save json data in fees columns, i.e. fees.fee.type, I am unable to show them in the table.
Data are saved correctly in the database {"fee": {"fee": "43", "type": "oneoff"}}.
It seems that table instead of looking in the column fees for fee.type it searches for a fees relationship.

namespace App\Filament\Resources\BranchResource\RelationManagers;

use App\Models\Branch;
use Filament\Forms;
use Filament\Resources\Form;
use Filament\Resources\RelationManagers\HasManyRelationManager;
use Filament\Resources\Table;
use Filament\Tables;

class RelationsRelationManager extends HasManyRelationManager
{
    protected static string $relationship = 'relations';

    protected static ?string $recordTitleAttribute = 'dropoff_id';

    public static function form(Form $form): Form
    {
        return $form
            ->schema([
                Forms\Components\Select::make('dropoff_id')
                    ->options(Branch::orderBy('sef')->get()->pluck('sef', 'id')),
                Forms\Components\Toggle::make('is_active')
                    ->required(),
                Forms\Components\Select::make('fees.fee.type')
                ->options(['oneoff' => 'One Off', 'two-way' => 'Two Way']),
                Forms\Components\TextInput::make('fees.fee.fee'),
            ]);
    }

    public static function table(Table $table): Table
    {
        return $table
            ->columns([
                Tables\Columns\TextColumn::make('dropoff.sef'),
                Tables\Columns\TextColumn::make('fees.fee.fee'),
                Tables\Columns\TextColumn::make('created_at')
                    ->dateTime('d-m-Y H:i'),
                Tables\Columns\TextColumn::make('updated_at')
                    ->dateTime('d-m-Y H:i'),
            ])
            ->filters([
                //
            ]);
    }
}

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class BranchRelation extends Model
{
    protected $fillable = [
        'pickup_id',
        'dropoff_id',
        'is_active',
        'fees',
        'meta',
    ];

    protected $casts = [
        'is_active' => 'boolean',
        'fees' => 'array',
        'meta' => 'array',
    ];

    function pickup(): BelongsTo
    {
        return $this->belongsTo(Branch::class, 'pickup_id');
    }

    function dropoff(): BelongsTo
    {
        return $this->belongsTo(Branch::class, 'dropoff_id');
    }
}

It is the first time I use this package, I read the documentation but could bot find any relative information. I apologize if there are any mistakes.
Steps to reproduce
No response
Relevant log output
Call to undefined relationship [fees] on model [App\Models\BranchRelation]. (View: /var/www/html/vendor/filament/tables/resources/views/index.blade.php)

Have you tried using -> instead of .?

Thank you @ryangjchandler, I have also tried fees->fee->type and fees->>fee->>type, I do not see any errors then but it still not works.

Dot-syntax is reserved for relationship columns, i.e. accessing an author's name with author.name. Therefore, you must use getStateUsing() to access array data:
Tables\Columns\TextColumn::make('fee_type')->getStateUsing(fn (BranchRelation $record) => $record->fees['fee']['type'] ?? null)


merge package template from Kronos-Tools/npm-package-template

Updated standard to latest version

Codecov Report

Merging #242 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #242   +/-   ##
=======================================
  Coverage   88.42%   88.42%
=======================================
  Files           1        1
  Lines         216      216
=======================================
  Hits          191      191
  Misses         25       25

Continue to review full report at Codecov.

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


Enhancing UI of OSCode's Blog Page

Current Behavior
There is no hover effect for social icons in OSCode's Blog page.
Desired Behavior
There can be beautiful hover effect for social icon and a scrolling bar complementing the page's design would be a better page to visit.
Screenshots / Mockups

I have the required knowledge solve this issue.
Kindly assign this to me under GSSoC 2023

I'm a contributor in GSSoC 2023 . I have all the skills which this issue requires. Kindly assign this issue to me.

Hello buddies , thanks for stepping up!
Actually we are creating the blog page, through hashnode, so we won't be able to give access to everyone. If there is anything else , u would like to work on pls go ahead!


:fire: Delete code that expected react-native/shared to be a symlink …

…on windows
@keybase/react-hackers
@chrisnojima

:+1:


Align service naming

We now reflect the configured service names when listing them in the ocis runtime.
Follow up PRs:

[ ] rename storage-metadata -> just metadata
[ ] rename ocis commands to reflect changed names, eg storageapprovider.go -> approvider.go with the command name storage-app-provider -> app-provider

partly fixes https://github.com/owncloud/ocis/issues/3603

:boom: Acceptance test localApiTests-apiAccountsHashDifficulty-ocis failed. Further test are cancelled...

We should then also rename the respective config in ocis-pkg/config/config.go

@wkloucek like so: https://github.com/owncloud/ocis/pull/3606/commits/c3826ac72dcab6459a4ba4ac3ed46710ec802f80
and what about graph_explorer in extensions/graph-explorer/pkg/config/config.go


Deprecate Google MySQL 5.1 with extreme prejudice.

@alainjobart
As part of removing googleBinlogEvent parsing support, I reworked the
binlog_streamer_test to use fake events instead of real ones. The actual
parsing of real events is already tested in its own unit test. Using
fake events simplifies the binlog_streamer_test, which really is only
meant to test the logic for converting a stream of events into a stream
of transaction objects.

LGTM thanks for doing this... I stopped when I saw the binlog streamer stuff, great to have that independent now.


footer-2 (Sticky Footer) display property

Currently, footer-2's display value is inline-block. Even with html, body { margin: 0; }, this still results in a line at the bottom of the page due to inline-block's whitespace "feature".

So why isn't footer-2's display value simply block?

Granted, if you only change the example footer's display value to block, it collapses, but that's only because the example footer is not assigned the height that is set in the commented out SCSS below.

merged


Add French translation, first write.

Following #324, here is the French translation I offer :) Please tell me if I missed anything.

Reading your comment in #359, I've added my name so as to fullfil step 5. As for step 4, I am not sure where to find the file translation.py. Is anything missing with this PR?