Addon version

Hello,
I just made an addon implementation of your project. I think it's a better way to use the project than putting build folder directly in www folder. Easier for "lambda" user and easy to maintain up to date.
Here is the repo of the addon: https://github.com/anthony2856/hassio-tileboard-addon
Let's have a look on it and tell me what you think ;)

How would the experience of editing the configuration file look like with that?
This project doesn't have any way to configure the settings using a UI so the user needs direct access to configuration file somehow.

The only configuration you have to do with this addon is to set the path to your config folder (located in /www).
Imagine you set configFolder: "tileboard", then you'll have to create the folder <config>/www/tileboard (restart HA if www folder did not exists) and put your config(s) file(s) inside. You could also put an images folder. Everythings in this folder will be copied to the directory of the application.
For now, the addon is based on the latest release 2.0.3, but it could be great if a release of your project could make a release of the addon. This way, users will be automatically warned that there is a new release and could update app from Home Assistant :)
I'm planning to create a "builder" for this project, i really like it, you've made a great job ! The idea of the builder is just having some typescript interfaces to help user to create config file and use rollup to transpile and set everything in a config.js file, what do you think ?

I've just commit an update to use symbolic link instead of copying files. So now, you just have to reload page if you made changes to your config file. But if you had a new file, you'll have to restart the addon.

I think it would be great to have something that would auto-update.
Also, if this solution doesn't compromise on anything that is currently possible, then I'd be open to making it "official" and handling it entirely within this repo.
I'd just need to find some time to play with it and understand exactly how it works first.

I'm planning to create a "builder" for this project, i really like it, you've made a great job ! The idea of the builder is just having some typescript interfaces to help user to create config file and use rollup to transpile and set everything in a config.js file, what do you think ?

That part sounds interesting but I'm don't fully understand how do you envision it working. Would the idea be only to use it to kick-start a config file? And from there the user would update it manually? I'm asking because I think that it would be rather hard to make it handle complex cases that require manually editing of the config.

Yes, for sure ! I also think the addon has to be in this repo to be auto upadted with the new release ;) My idea was first to make a POC and see what was possible to do ;) So, feel free to take my code and use it like you want ;)
For the builder part, the idea is just to provide typescript interface to the user so he can have auto completion when he is creating his config file. The best solution would be if the application was made with Typescript. This way, the build of the application would publish a npm package with interfaces corresponding to the app. Do you better understand what i'm thinking ?

Types can be created manually and included in the project, together with appropriate tsconfig.json configuration. I was meaning to do that anyway.

Yes, it is possible to do that manually but it implies do synchronize interfaces manually with the app, it can be time looser, no ?

For the addon part, would you like me to make a pull request for an implementation on this repo ?

Sure, go ahead. :)

Hello @rchl ,
I'm working on the PR for the addon implementation. I have a constraint and i want your opinion on the best (prefered) solution. The problem is, to be detected by Home Assistant, the addon need a config.json file with a correct tag version. You will understand that is a duplicate with package.json version field. So i was thinking of update onPush github actions to retrieve package.json version and put it in the config.json file, then commit the config.json file. This way you don't have to manually handle this file. But if I do this, you'll have to first push to master, let the github actions run and create the tag on the recently created commit.
The other way to do this is to manually changing version field in config.json..
Not sure i'm really understandble, sorry for my english... :/

I'm sorry for being slight off-topic here, but perhaps we could use this opportunity and use ingress for the add-on? This way we no-longer have to worry about tokens being exposed and other authentication issues?

Hi @resoai ,
Will it be still possible to have TileBoard in a proper tab on your browser or will it be fully integrated into Home Assistant ?

to be detected by Home Assistant, the addon need a config.json file

I assume you are talking about a different config.json than the one that is used for TileBoard configuration?
If that file will live in the repo then the version could be adjusted on releasing which happens manually with yarn release. I think it should be possible to hook into that and do the required modifications. Doing it from CI is a bit "late".

I'm sorry for being slight off-topic here, but perhaps we could use this opportunity and use ingress for the add-on? This way we no-longer have to worry about tokens being exposed and other authentication issues?

As @anthony2856 mentioned, I think it would lose the ability to be loaded separately and be installed as a web app.

I think we would still be able to load it in a separate tab just fine, if I understand correctly but definitely need to investigate it.

I assume you are talking about a different config.json than the one that is used for TileBoard configuration?

Yes it's a config.json used by home assistant to detect version change, which docker image to use, etc. Different from TileBoard one ;)

If that file will live in the repo then the version could be adjusted on releasing which happens manually with yarn release. I think it should be possible to hook into that and do the required modifications. Doing it from CI is a bit "late".

I will have a look on what is done with yarn release, you're right it's a bit late doing it from CI.

I think we would still be able to load it in a separate tab just fine, if I understand correctly but definitely need to investigate it.

If it still possible to open it in a separated tab, no problem with that. I just don't know how it works for now but i will have a look on it ;)

I will have a look on what is done with yarn release, you're right it's a bit late doing it from CI.

The standard-version package that is used for releasing supports various hooks (some are even already used): https://github.com/conventional-changelog/standard-version#lifecycle-scripts

Nice package, i did'nt know it. For the version number in config.json file it will be pretty easy i think.
But I also have to copy README.md + CHANGELOG.md to the addon folder (again to be used in addon description in home assistant)

I think we would still be able to load it in a separate tab just fine, if I understand correctly but definitely need to investigate it.

I don't have any experience creating ingress addons but from my experience using them, you can either open them from the panel which gives you the benefit of auto-login or you can open them using the ports they expose but then you don't get benefits like that.
For example, NodeRed addon will auto-login if you open it from the sidebar but if you go to <ha_ip>:1880 then you have to login manually.

But I also have to copy README.md + CHANGELOG.md to the addon folder (again to be used in addon description in home assistant)

You can even just use shell for that (cp src dst). That won't work on Windows but that's probably OK. There are also cross-platform alternatives of course.

Ok it works like a charm 👍
I used bumpFiles option to set version in addon/config.json and i used the postchangelog hook to copy README.md and CHANGELOG.md to the addon directory ;)
I will have a look on ingress capabilities tomorrow

Hi,
I've just look the NodeRed plugin but it also expose an nginx server but use ingress for the home assistant side bar. From what i understood.
So, for me I don't see any benefits to use ingress for this. Could you explain your needs @resoai ?

I think the benefit could be that the user wouldn't have to login manually.

But only if the user is using the addon inside home assistant right ? For me the big advantage of this project is to be used on wall panel right ?

But only if the user is using the addon inside home assistant right ?

That's the part we are not sure about and wanted to be checked. But I believe so, myself.

For me the big advantage of this project is to be used on wall panel right ?

You can still do that with ingress, I guess. Only that the user would still have access to the rest of the HA by clicking the "hamburger" menu.

You can still do that with ingress, I guess. Only that the user would still have access to the rest of the HA by clicking the "hamburger" menu.

Yes, it's personnal, but i think it will be better not seeing this hamburger menu. And let not the user go away from the panel


Failure with gdal >= 2.3.1

Based on this pull request: https://github.com/albertov/bindings-gdal/pull/18, I setup the following patch: https://github.com/guibou/bindings-gdal/tree/gdal_2_3_1_failure. Theses commands are failing (segmentation fault apparently):

nix-build -A bindings-gdal_2_3_1
nix-build -A bindings-gdal_2_4_0

However nix-build -A bindings-gdal_1_11 and nix-build -A bindings-gdal (without the patch) are building and tests are passing correctly.
I suspect a change in gdal-2.3.1 is responsible for the failure.

Using:
nix-shell -A bindings-gdal_2_4_0
cabal test

I can obtain the following error:
  tests/TestUtils.hs:113:24:
  1) GDAL.Algorithms.contourGenerateVectorIO produces contours if vector has data
       expected: 13
        but got: 8

  To rerun use: --match "/GDAL.Algorithms/contourGenerateVectorIO/produces contours if vector has data/"

This looks like the contour algorithm or the default interval has changed
so it gives different results. Might be a real bug in the bindings though.
I’ll try to take a closer look tomorrow. Thanks!
On Tue, 19 Mar 2019 at 21:02, Guillaume Bouchard<EMAIL_ADDRESS>wrote:

Using:
nix-shell -A bindings-gdal_2_4_0
cabal test
I can obtain the following error:
tests/TestUtils.hs:113:24:

GDAL.Algorithms.contourGenerateVectorIO produces contours if vector has data
expected: 13
but got: 8

To rerun use: --match "/GDAL.Algorithms/contourGenerateVectorIO/produces contours if vector has data/"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/albertov/bindings-gdal/issues/19#issuecomment-474555777,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA00C8FLP-F1TWuU9huS357t44wGLdy8ks5vYUJhgaJpZM4b8-lF
.

@guibou ill take a look during the weekend as im a bit swamped with work now

@albertov Any updates on this?


chicken spawns depend on previous chick positions and can be manipulated

Easy place to see this is during Villa Cube ILs. In a full-game run / if you don't manip it, the first chick behind the warp gate often takes several seconds to go in and for autosave to kick in, preventing you from picking up the other chicks.
But if you grab a chick but reset the IL before you return it to the portal, when you grab the chick behind the warp gate it goes in very quickly and autosaves early, without preventing pickup of other chicks. I do it in my IL run here - https://www.youtube.com/watch?v=Kx5ubw8KMVQ

Fixed by https://github.com/my-opengoal-mods/OG-Jak-The-Chicken-Reborn/tree/rewrite3-3subtest


Release 0.5.0 to the registry

Version 0.5.0 is not available through the registry as seen here:

Can we release this version to the registry?

Done. https://registry.terraform.io/modules/Smartbrood/ec2-iam-role/aws/latest


Fix link to localization article

@jorrit thank you very much for fixing this up, really appreciate it!

:tada: This issue has been resolved in version 0.20.0 :tada:
The release is available on:

GitHub Release
Chocolatey Package

Your GitReleaseManager bot :package::rocket:


Update readme docs

fix typos.

remove duplicates, for example:

text formatting, clarification.

remove unnecessary examples.

add backlinks to some terms.

add pagination examples for all available APIs.

Pagination examples could be placed to oobt/ folder instead to test "out of the box tests" for all APIs. However, I'm not familiar with it and how things currently work so I need a little guidance before making on it 🙂

@ilyazub would love to do that :shipit:


[#1598] fix(server) Fix inaccurate used_direct_memory_size metric

What changes were proposed in this pull request?
Fix the inaccurate used_direct_memory_size metric.
Also used_direct_memory_size_by_netty and used_direct_memory_size_by_grpc_netty metrics are added to provide more detailed indicators for locating and analyzing in production.
Why are the changes needed?
Fix https://github.com/apache/incubator-uniffle/issues/1598.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Tested in our env.

Codecov Report
Attention: Patch coverage is 75.00000% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 54.02%. Comparing base (32d533d) to head (6280ac3).

Files
Patch %
Lines

...pache/uniffle/server/NettyDirectMemoryTracker.java
62.50%
3 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             master    #1599     +/-   ##
===========================================
  Coverage     54.01%   54.02%
+ Complexity     2863     2291    -572
===========================================
  Files           438      360     -78
  Lines         24850    16103   -8747
  Branches       2114     1468    -646
===========================================
- Hits          13423     8699   -4724
+ Misses        10586     6899   -3687
+ Partials        841      505    -336

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Great!

@rickyma
I am interested in is there direct memory problem in your prd ?

@rickyma I am interested in is there direct memory problem in your prd ?

No. I've fixed a lot of serious issues related to off-heap memory when enabling Netty.
There is only one issue https://github.com/apache/incubator-uniffle/issues/1596 left.
And I find out that gRPC does not work very well when the concurrency is above 11200. There is a huge problem when enabling gRPC. The load of CPU will be a lot higher than using Netty. I'll mention this later in another issue. But I might not fix this, because we will use Netty instead of gRPC. gRPC should be deprecated later on.


Replace the control character at position 2 by its escape sequence '\u3000'.

Mentioned in #648
Issues found: https://sonarcloud.io/project/issues?resolved=false&rules=csharpsquid%3AS2479&id=nikcio_lucenenet
This should be marked with a // LUCENENET specific - changed from invisible whitespace character to '\u3000' for readability.

There appears to be a bug in the SonarCloud analyzer report. The '\u3000' character is at position 1, not position 2.
?(int)" 　\t\r\n"[0]
32
?(int)" 　\t\r\n"[1]
12288
?(int)" 　\t\r\n"[2]
9
?(int)" 　\t\r\n"[3]
13
?(int)" 　\t\r\n"[4]
10
?(int)'\u3000'
12288

@NightOwl888 I think that it starts counting at 1 instead of 0 and that's why it says 2.


freeimage: Unbundle dependencies, fix AAarch64 support, and other fixes

This pretty much just adapts https://src.fedoraproject.org/rpms/freeimage into nixpkgs.
All of the patches except the substream one is included, since it's not clear if it's
needed.
It seems to me that freeimage is unfortunately partly abandonware, considering
that there is a patch for a CVE included and that the last release was in 2018.
Fixes #77653
Replaces #77655
Motivation for this change
It was broken on AArch64, and there are apparently also other bugs in the codebase.
Things done
NB: I've only tried compiling it on aarch64.

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

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

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

The fetchpatch function takes a name =  argument - it would be helpful if you used that to label these patches appropriately. Additionally, if you name a patch something like name = "CVE-1234-1234.patch", automated vulnerability scanners like https://broken.sh should be able to pick it up as "fixed".

I'm satisfied that the included tiff patch fixes both CVE-2019-12211 and CVE-2019-12213.
I'm satisfied that unbundling openjpeg resolves CVE-2019-12214
I'm satisfied that unbundling jxrlib resolves CVE-2019-12212

For the tiff patch, naming it CVE-2019-12211.CVE-2019-12213.patch should allow scanners to pick it up.
Maybe shoehorning CVE-2019-12212 and CVE-2019-12214 into the name for the unbundling patch is worth it to get those struck off too.
I don't think we build the docs, so tbh I don't think we should bother with the doxygen patch.
If you do a rebase I'll do a proper review :)

@risicle Done.
I built it, and tested it with imv (which did not work on aarch64 before!), and it works fine.

@ofborg build arrayfire
(local machine hanging on cuda)

One problem with this is it breaks the darwin build, because it adds the jxrlib dependency and nobody's got jxrlib building on darwin yet.

Hmm looks like that was only the first darwin problem. The main problem is that the unbundling patch fixes Makefile.gnu but doesn't make equivalent changes to Makefile.osx.

Ok I've got it working for macos in my branch https://github.com/risicle/nixpkgs/tree/ris-freeimage-unbundled-darwin-fix
Looking at it all now, having this stack of patches, a prePatch phase, a postPatch phase, a preBuild phase, a postBuild phase, it's all starting to look like a complex fragile mess and I'd be really tempted to make the unbundling patch our own because it would allow us to eliminate many of the other things the various phases are trying to do (e.g. the makeFlagsArray trick can be eliminated).
I also realised that there is a slight possibility of breakage of downstream applications that are using the static library. Any such applications will be expecting the static lib to have all necessary code bundled, and won't expect to have to link with e.g. libpng. Don't think there's anything we can do about this though.

I doubt that breakage will be a problem since it seems that most major distros do the unbundling. I'll take a look at doing the unbundling myself and see how easy it is.

It could just be a matter of squashing our modifications down into the patch.

or squashing our changes down into a patch which sits on top of the fedora patch.

This works for me, I've been using it with imv on the pinebook pro. Thanks for doing this @L-as, I look forward to it being merged.

Apparently there is a newer version of freeimage (r1859 / 3.19.0) which fedora uses since 2 months ago. It makes a lot of the patches redundant, which is nice.

@risicle so freeimage requires private headers from libtiff (tiffiop.h) and private headers that should be public from libjpeg-turbo (transupp.h). Fedora just disables the plugin, but I assume that that's due to their build system not being powerful enough and the fact that it's not a monorepo, so coordinating changes across is probably hard. Do you think it's acceptable to make these 2 derivations export these headers? It is a simple change that just adds a line to CMakeLists.txt as so (for libjpeg-turbo):
{
  # ...
  prePatch = ''
    echo 'install(FILES ''${CMAKE_CURRENT_SOURCE_DIR}/transupp.h DESTINATION ''${CMAKE_INSTALL_INCLUDEDIR})' >> CMakeLists.txt
  '';
  # ...
}

It's an interesting one - libjpeg is a pretty central package, and people like to limit weirdness. Seeing as this is a header change, might it be possible to dig into libjpeg.src and extract the required files for just this package's use (perhaps giving it to a runCommand ... "cp include/some_header.h $out/include/"-style derivation)?
Also, with freeimage itself being a library, what do you mean by requires these headers? Does it require these headers just at freeimage build-time, or at build-time of a program using freeimage?

@risicle The headers are only required when building freeimage, not when building derivations that depends on freeimage. As for using the src attribute, that is not possible for libjpeg, since it seems that transupp.c (for transupp.h) isn't actually included in the library either! It works fine if I also include that to be built into libjpeg.so, but because of that obviously just using the header won't work. As for libtiff, one of the headers is built when building libtiff, so that header needs to be somehow exported from the build process. Would using overrideAttrs be preferred?

I pushed my WIP changes so that you can tentatively review them if you so desire.

I fixed the marked problems and additionally also noticed that the link to download from sourceforge isn't actually valid unless some javascript runs when you click the download button on the website... so now it just uses fetchsvn. I also updated the commit to include the "update message" for libjpeg-turbo.

I tested imv again and it works fine with no problems.

Attempting to nixpkgs-review this on macos 10.14 gets me
building '/nix/store/zq5p1l5kyg3ywk7wkznnfbx2zccgvksp-freeimage-svn-r1859-FreeImage-trunk.zip.drv'...
hash mismatch in fixed-output derivation '/nix/store/jcjwmyzrx00mr160phap1lx08pkikh1k-freeimage-svn-r1859-FreeImage-trunk.zip':
  wanted: sha256:0v1fncgyylqibhp1ah9h0z3g4hcjp553p7n6k5nngvwh9rv60br0
  got:    sha256:1hvp2n7vrqvb3qpm2csrl3x5y3j2bsha4dy8cb2hyb5g6lrrqk14

@risicle please try again, I had somehow forgotten to push my previously mentioned fixes. That is exactly the issue I talked about (the hash also changes randomly!)

@risicle actually, I had an issue with pushing which I didn't notice (and fixed now). It is actually pushed properly now.

I split the PR into 4 separate commits for the maintainers, libjpeg-turbo, libtiff, freeimage change.

One of the checks is complaining that your maintainer entry has no name field: https://gist.github.com/GrahamcOfBorg/e3cba7da918b018cd477d8589c030f99

@ofborg build poppler gv graphicsmagick librsvg gnuplot python37Packages.pillow vips

I fixed the name entry.

This also needs to be retargeted to staging, since it's a mass rebuild

Done.
木, 10月 8, 2020 at 07:36, Linus Heckemann<EMAIL_ADDRESS>が送信：

This also needs to be retargeted to staging, since it's a mass rebuild
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@lheckemann is this actually the way it's supposed to be done? Rebasing on staging causes lots of maintainers to be notified, which seems to me unnecessary?

The target branch needs to be changed as well, I've done that. Sorry for the confusion!

bump

I tested it and it still works. I resolved all the remaining issues.

It seems like imv now uses meson and the way it's laid out sort of implies that maybe it supports a non-freeimage backend?

FreeImage uses the headers for some features.
木, 12月 31, 2020 at 08:01, Jörg Thalheim<EMAIL_ADDRESS>が送信：

@Mic92 commented on this pull request.

In pkgs/development/libraries/libtiff/headers.patch:

++  tiffiop.h
++  ${CMAKE_CURRENT_BINARY_DIR}/tif_config.h
++  tif_dir.h

What are these headers used for?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

There doesn't seem to be any remaining unresolved issues.

There doesn't seem to be any remaining unresolved issues.

@L-as So as to the private headers I think we can do a a bit better, though I feel bad saying so as you've jumped through so many hoops already!
Anyways, while freeimage might be abandonware, libjpeg-trubo and libtiff (despite incredible confusions with forks, dead websites, similiarly named other things, etc.!!) are still actively maintained. After some digging, the code is at:

https://gitlab.com/libtiff/libtiff
https://github.com/libjpeg-turbo/libjpeg-turbo

If you could turn the patches into PRs along with an explanation of the issue, that would be much appreciated. We can then fetch the patches from the PR in the meantime. This kicks off process of the issue being resolved one way or the other, as exposing private parts of widely used packages long term is not good.

@L-as So as to the private headers I think we can do a a bit better, though I feel bad saying so as you've jumped through so many hoops already!
Anyways, while freeimage might be abandonware, libjpeg-trubo and libtiff (despite incredible confusions with forks, dead websites, similiarly named other things, etc.!!) are still actively maintained. After some digging, the code is at:

https://gitlab.com/libtiff/libtiff
https://github.com/libjpeg-turbo/libjpeg-turbo

If you could turn the patches into PRs along with an explanation of the issue, that would be much appreciated. We can then fetch the patches from the PR in the meantime. This kicks off process of the issue being resolved one way or the other, as exposing private parts of widely used packages long term is not good.

@L-as So as to the private headers I think we can do a a bit better, though I feel bad saying so as you've jumped through so many hoops already!
Anyways, while freeimage might be abandonware, libjpeg-trubo and libtiff (despite incredible confusions with forks, dead websites, similiarly named other things, etc.!!) are still actively maintained. After some digging, the code is at:
* https://gitlab.com/libtiff/libtiff

* https://github.com/libjpeg-turbo/libjpeg-turbo

If you could turn the patches into PRs along with an explanation of the issue, that would be much appreciated. We can then fetch the patches from the PR in the meantime. This kicks off process of the issue being resolved one way or the other, as exposing private parts of widely used packages long term is not good.

The patch for libjpeg is simple, and might be accepted since it just makes transupp.c part of the shared library, but the patch for libtiff literally exposes all of its internals, which I doubt that they would accept as a PR. The only way I could see this being fixed upstream, is if the parts freeimage uses are made a public API, but that seems impossible looking at PluginG3.cpp (the only file that needs it), since it uses APIs that are not meant to be used. You could integrate the functionality of PluginG3.cpp into libtiff, but that would require someone to put in effort for something which the libtiff maintainers might not want anyway. The most realistic solution seems to me to be either removing the plugin (not too hard, but unfortunate), or leaving it and also the libtiff patch in, meaning that freeimage will be able to handle an image format for fax machines.

@L-as So as to the private headers I think we can do a a bit better, though I feel bad saying so as you've jumped through so many hoops already!
Anyways, while freeimage might be abandonware, libjpeg-trubo and libtiff (despite incredible confusions with forks, dead websites, similiarly named other things, etc.!!) are still actively maintained. After some digging, the code is at:
* https://gitlab.com/libtiff/libtiff

* https://github.com/libjpeg-turbo/libjpeg-turbo

If you could turn the patches into PRs along with an explanation of the issue, that would be much appreciated. We can then fetch the patches from the PR in the meantime. This kicks off process of the issue being resolved one way or the other, as exposing private parts of widely used packages long term is not good.

The patch for libjpeg is simple, and might be accepted since it just makes transupp.c part of the shared library, but the patch for libtiff literally exposes all of its internals, which I doubt that they would accept as a PR. The only way I could see this being fixed upstream, is if the parts freeimage uses are made a public API, but that seems impossible looking at PluginG3.cpp (the only file that needs it), since it uses APIs that are not meant to be used. You could integrate the functionality of PluginG3.cpp into libtiff, but that would require someone to put in effort for something which the libtiff maintainers might not want anyway. The most realistic solution seems to me to be either removing the plugin (not too hard, but unfortunate), or leaving it and also the libtiff patch in, meaning that freeimage will be able to handle an image format for fax machines.

@L-as OK then how about this?

PR and fetch patch for libjpeg-trubo
Move the libtiff private headers to a separate dev-internal output so that programs inadvertently depending on them is avoided.

@L-as OK then how about this?

PR and fetch patch for libjpeg-trubo
Move the libtiff private headers to a separate dev-internal output so that programs inadvertently depending on them is avoided.

@L-as OK then how about this?
* PR and fetch patch for `libjpeg-trubo`

* Move the libtiff private headers to a separate `dev-internal` output so that programs inadvertently depending on them is avoided.

That sounds fine to me, I'll try that.

@L-as OK then how about this?
* PR and fetch patch for `libjpeg-trubo`

* Move the libtiff private headers to a separate `dev-internal` output so that programs inadvertently depending on them is avoided.

That sounds fine to me, I'll try that.

Thanks!

Thanks!

I made the changes, but dev-internal can't actually be used as an output for some reason: The setup script in stdenv will complain at some line which I don't remember.

I made the changes, but dev-internal can't actually be used as an output for some reason: The setup script in stdenv will complain at some line which I don't remember.

The PR: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/487

The PR: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/487

I fixed the indentation issue, somehow I had missed that. Thanks.

I fixed the indentation issue, somehow I had missed that. Thanks.

I think I can compile transupp.c only as part of freeimage with some trickery, so don't merge this just yet.

I think I can compile transupp.c only as part of freeimage with some trickery, so don't merge this just yet.

I pushed my changes, and freeimage compiles fine. transupp.c is included as part of libjpeg-turbo, but the exported symbols are weak and should not cause any issues with anything that links to it and already vendors transupp.c. transupp.h is only available in the dev_internal output.
I tried compiling imv on aarch64, but harfbuzz timed out while testing unfortunately.

I pushed my changes, and freeimage compiles fine. transupp.c is included as part of libjpeg-turbo, but the exported symbols are weak and should not cause any issues with anything that links to it and already vendors transupp.c. transupp.h is only available in the dev_internal output.
I tried compiling imv on aarch64, but harfbuzz timed out while testing unfortunately.

imv works fine.

imv works fine.

I don't think there are any remaining issues.

I don't think there are any remaining issues.

I think that should be it.

I think that should be it.

Should I change the commit message to 3.18.0 -> 2020-07-04?

Should I change the commit message to 3.18.0 -> 2020-07-04?

Should I change the commit message to 3.18.0 -> 2020-07-04?

Would not hurt

Should I change the commit message to 3.18.0 -> 2020-07-04?

Would not hurt

@GrahamcOfBorg eval

@GrahamcOfBorg eval

@GrahamcOfBorg eval

@GrahamcOfBorg eval

Thanks again @L-as for all your hard work with this!

Thanks again @L-as for all your hard work with this!

This might have broken freeimage on macOS: https://hydra.nixos.org/job/nixpkgs/trunk/freeimage.x86_64-darwin/all
Trying to build https://github.com/NixOS/nixpkgs/commit/be94ded77feb048e181d3cda4abddee66fd3d63d locally now.

The error is:
make -f Makefile.osx install
make[1]: Entering directory '/private/tmp/nix-build-freeimage-unstable-2020-07-04.drv-0/svn-r1859/FreeImage/trunk'
install Source/FreeImage.h /usr/local/include
install: cannot create regular file '/usr/local/include': Permission denied
make[1]: *** [Makefile.osx:107: install] Error 1

Damn. I'd also try some of the earlier revisions in this PR as we definitely had it working on darwin eariler in this thread.

https://github.com/NixOS/nixpkgs/commit/be94ded77feb048e181d3cda4abddee66fd3d63d fails on libtiff tests, now trying with the fix from https://github.com/NixOS/nixpkgs/pull/110729.

With the fix the error is the same as the one on hydra, trying some older commits from this PR now.

Unfortunately the branch was force pushed so I can't access the older revisions of the PR. https://github.com/NixOS/nixpkgs/pull/92708/commits/2cc1925c040c7a564079cf187a187031d5f2c0b1 builds correctly but that's before the freeimage version bump. Will open a new issue for this in the meantime.

You're right, I tried checking them out but I didn't have those commits since there's no heads pointing to them, but I can fetch them directly. Trying them now.

Ok, tested all commits in the PR:

commit
error

90736ab6c29963d5f18894228c6dc5b4fb6db0bc
jxrlib incompatible

a3739ba6645bbb73050aac64e600a65f8dd6c4b4
jxrlib incompatible

f6f2092eaacf2b4e99ca4ce867b91890d584c730
jxrlib incompatible

50d6e41c3d2c3400518df85f5e7372e6f6e1f2c9
jxrlib incompatible

61f6e58aaba42430f707f1bafb3fc0e1c48eb175
big sur issue

d88ca144d5027134caa0e6302c8cbc03ce018ae3
big sur issue

d822b8dab3e13927affea71c6a2eae7f973e7c45
big sur issue

19ab108e0d03e4d041e70c1e9a5da29d1feac525
big sur issue

3b612aeaa733b9b659152a90609878a2da7406c6
big sur issue

eeb6728b0374e31df45b9728e7600794a5b2f99e
big sur issue

b152b39c1f4acae404b4959767af604d1a8336c5
probably big sur issue

cb76d0d4803f606c9092c40e4ace17d29ec1909a
404

33bd7b8e2f43ffee2b903ebd6069d7b15ec485de
404

796083ce711059762d9b01feb7a262b9a233b775
404

72fd3e310bdd1d48cd3ed3e75ca4cb2ec9269744
404

bbd45ed9d1df28588788aadeb9aa15c6355abeea
404

364de14d30ee140e626f03789ffaade579bb9dc7
404

c8af9e83d46d47c8ce1c2daa04e83deec52ac314
chmod

8ee3e74e74f6273199d1ab681fe8f8584bfd9ac5
install

9b2628a15e129cefe235dc3bf363a1bdb5ed18fe
install

6f83ffd72302045cfd67a1e3408931396e6bde38
install

27e05af4e9b2f458f0a43bc034aa31ee8d465830
install

9de653e0d9d67031f797e0c1ded1587b129454aa
install

be94ded77feb048e181d3cda4abddee66fd3d63d
install

Explanations of errors:
jxrlib incompatible
error: Package ‘jxrlib-1.1’ in /Users/uri/github/NixOS/nixpkgs/pkgs/development/libraries/jxrlib/default.nix:21 is not supported on ‘x86_64-darwin’, refusing to evaluate.

big sur issue
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /nix/store/gkcr1p2x0psdc31bavmqbfb2nwq0d6jn-clang-wrapper-7.1.0/bin/clang
-- Check for working C compiler: /nix/store/gkcr1p2x0psdc31bavmqbfb2nwq0d6jn-clang-wrapper-7.1.0/bin/clang - broken
CMake Error at /nix/store/z7qvx6wbvmjvs767g06h03pkzr5aqn6i-cmake-3.18.2/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "/nix/store/gkcr1p2x0psdc31bavmqbfb2nwq0d6jn-clang-wrapper-7.1.0/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /tmp/nix-build-libjpeg-turbo-2.0.5.drv-0/source/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/nix/store/c3v8mz19las3k4afgqfjj9h054yv9sbz-gnumake-4.3/bin/make cmTC_a5f98/fast && /nix/store/c3v8mz19las3k4afgqfjj9h054yv9sbz-gnumake-4.3/bin/make  -f CMakeFiles/cmTC_a5f98.dir/build.make CMakeFiles/cmTC_a5f98.dir/build
    make[1]: Entering directory '/private/tmp/nix-build-libjpeg-turbo-2.0.5.drv-0/source/build/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_a5f98.dir/testCCompiler.c.o
    /nix/store/gkcr1p2x0psdc31bavmqbfb2nwq0d6jn-clang-wrapper-7.1.0/bin/clang   -arch x86_64 -o CMakeFiles/cmTC_a5f98.dir/testCCompiler.c.o -c /tmp/nix-build-libjpeg-turbo-2.0.5.drv-0/source/build/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_a5f98
    /nix/store/z7qvx6wbvmjvs767g06h03pkzr5aqn6i-cmake-3.18.2/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a5f98.dir/link.txt --verbose=1
    /nix/store/gkcr1p2x0psdc31bavmqbfb2nwq0d6jn-clang-wrapper-7.1.0/bin/clang  -arch x86_64 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_a5f98.dir/testCCompiler.c.o -o cmTC_a5f98
    ld: warning: passed two min versions (10.12.0, 10.12) for platform macOS. Using 10.12.
    ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64
    clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
    make[1]: *** [CMakeFiles/cmTC_a5f98.dir/build.make:106: cmTC_a5f98] Error 1
    make[1]: Leaving directory '/private/tmp/nix-build-libjpeg-turbo-2.0.5.drv-0/source/build/CMakeFiles/CMakeTmp'
    make: *** [Makefile:140: cmTC_a5f98/fast] Error 2

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:7 (project)

probably big sur issue
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/private/tmp/nix-build-bison-3.7.3.drv-0/bison-3.7.3':
configure: error: C compiler cannot create executables
See `config.log' for more details
builder for '/nix/store/1x46w6dy0al2y4xx8fshc7l4dy9db3v3-bison-3.7.3.drv' failed with exit code 77

404
trying https://sourceforge.net/code-snapshots/svn/f/fr/freeimage/svn/freeimage-svn-r1859.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404
error: cannot download source from any mirror

chmod
unpacking sources
unpacking source archive /nix/store/dpsnbzmcbaqnk1nmhxzfll66vqf5jibs-svn-r1859
source root is FreeImage/trunk
chmod: cannot access 'FreeImage/trunk': No such file or directory

install
make -f Makefile.osx install
make[1]: Entering directory '/private/tmp/nix-build-freeimage-unstable-2020-07-04.drv-0/svn-r1859/FreeImage/trunk'
install Source/FreeImage.h /usr/local/include
install: cannot create regular file '/usr/local/include': Permission denied
make[1]: *** [Makefile.osx:107: install] Error 1

The big sur issues are because I'm building on big sur, and the range of commits that had that issue but not others were all based on master before the fix for it was merged: https://github.com/NixOS/nixpkgs/pull/107013.
So it's possible one of those was working on darwin if you tested them on catalina.

Fixed in https://github.com/NixOS/nixpkgs/pull/120124.

So it's possible one of those was working on darwin if you tested them on catalina.

I probably tested these on macos 10.14 back then

Fixed in #120124.

:clap:

Spoke too soon, it's still broken, now at runtime: https://github.com/NixOS/nixpkgs/issues/121550

This is missing some fixup, the darwin dynamic library referring to dependencies in the temporary build directories rather than their final store paths:
Load command 24
          cmd LC_LOAD_DYLIB
      cmdsize 96
         name /private/tmp/nix-build-jxrlib-1.1.drv-0/source/build/libjpegxr.dylib (offset 24)
   time stamp 2 Thu Jan  1 10:00:02 1970
      current version 0.0.0
compatibility version 0.0.0
Load command 25
          cmd LC_LOAD_DYLIB
      cmdsize 96
         name /private/tmp/nix-build-jxrlib-1.1.drv-0/source/build/libjxrglue.dylib (offset 24)
   time stamp 2 Thu Jan  1 10:00:02 1970
      current version 0.0.0
compatibility version 0.0.0

This is described in https://nixos.org/manual/nixpkgs/stable/#sec-darwin:

On Darwin, libraries are linked using absolute paths, libraries are resolved by their install_name at link time. Sometimes packages won't set this correctly causing the library lookups to fail at runtime. This can be fixed by adding extra linker flags or by running install_name_tool -id during the fixupPhase.

Fix: https://github.com/NixOS/nixpkgs/pull/121646.


Recognize existing point / segment children on network add

See the video here: when I was messing with the datatype (converting RoadNetwork from Node to Spatial), I was running into this issue where the script would try to add new children.
https://user-images.githubusercontent.com/2958461/225183944-feabde7e-8622-4b23-8bec-1c122c30a8aa.mp4
This is low priority and shouldn't really be a problem in practice, generally speaking.

Likely to close this bug in the future, as we are contemplating a future where we don't have any children automatically added (the idea being that, RoadPoints would be direct children of RoadNetworks; and RoadSegments would be children of RoadPoints, etc). Leaving open since this is not a done deal, and this minor edge case can still occur in the meantime.

Closing as no longer relevant.


How to use the Manga DL

Hi, I was just reaching out because I was struggling to use the manga dl. I'm sorry I'm inexperienced but how do I operate this program? Thank you so much and sorry for the inconvenience
I tried to input this:
manga-py https://manganelo.com/manga/read_one_punch_man_manga_online_free3
but I'm constantly getting:
File "/anaconda3/lib/python3.6/site-packages/manga_py/fs.py", line 44, in remove_file_query_params
  file_path = dirname(name)
File "/anaconda3/lib/python3.6/site-packages/manga_py/fs.py", line 67, in dirname
  return str(Path(_path).parent)
File "/anaconda3/lib/python3.6/pathlib.py", line 999, in __new__
  self = cls._from_parts(args, init=False)
File "/anaconda3/lib/python3.6/pathlib.py", line 656, in _from_parts
  drv, root, parts = self._parse_args(args)
File "/anaconda3/lib/python3.6/pathlib.py", line 640, in _parse_args
  a = os.fspath(a)

Tried with the same error:

Component
Value

OS
Ubuntu 16.04.5 LTS

Python version
Python 3.5.2

Pip version
pip 18.0

Manga-py version
<IP_ADDRESS>

URL
https://manganelo.com/manga/read_one_punch_man_manga_online_free3

Oh. Sorry, I did not check it. Now everything should work fine!
Check 1.30.4, please!

Seems OK for me. :+1:
It have the occasional image fail, but OK.
Warning: 0 bit image downloaded, please check for redirection or broken content
Broken url: http://s1.mkklcdnv2.com/mangakakalot/r1/read_one_punch_man_manga_online_free3/chapter_15_fun_and_work/2.jpg
Page idx: 2

Component
Value

OS
Ubuntu 16.04.5 LTS

Python version
Python 3.5.2

Pip version
pip 18.0

Manga-py version
<IP_ADDRESS>

URL
https://manganelo.com/manga/read_one_punch_man_manga_online_free3

You did not check it?
https://github.com/yuru-yuri/manga-dl/issues/118#issuecomment-426169635
If you have suggestions for issue 118/120, I would listen to them.

I close it because there is no feedback from you.
If you have any questions, click the reopen button below.


Better completion short-hand, especially for marcos.

Here is an example code:
`
#define GPIOA_PIN_8 8
#define GPIOA_PIN_A 1
#define FoBaZo7 1
int HAL_GPIO_Set(){return 0;}
int HAL_GPIO_6(){return 0;}
int GPIOAPINB(){return 0;}
int AdBcEf5(){return 0;}
int main()
{
int foo=
return 0;
}
`
There are 2 things will can see:

function completion has better hit, "ABE" for "AdBcEf5" is OK, but fail for any string end with "5" like "ABE5" "A5" "AB5", etc.
"HG9", "H9" is good for HAL_GPIO_9, which is really doing the job well
variable defined by macro generally give worse hits, "FB" is no good for "FoBaZo7", "FBZ" "F7"failed to give any result as well.
As for "GPIO_PIN_A" and "GPIO_PIN_9", "GP" is fine, but no good for "GPA" or "GP9", which make the hits much less convienent. Because when you have "GPIO_PIN_0" "GPIO_PIN_1" "GPIO_PIN_2"..."GPIO_PIN_15" macros were defined, prompt completion hints by everything starts with "GPIO_PIN_" is meaningless... you have to either move a few times "down" key or use your mouse to select each one except for the "GPIO_PIN_0" or whatever the top of the list.

I believe this is a duplicate of #1480.

I believe this is a duplicate of #1480.

It's duplicate about the marco's part, but not the function's hints part.

I believe this is a duplicate of #1480.

It's duplicate about the marco's part, but not the function's hints part.

My bad, I overlooked that, reopening.

function completion has better hit, "ABE" for "AdBcEf5" is OK, but fail for any string end with "5" like "ABE5" "A5" "AB5", etc.

Is the behaviour you'd like to see that a query string (e.g. "AB5") is considered a match for a symbol name (e.g. "AdBcEf5") if the query string is any subsequence of the symbol name?

function completion has better hit, "ABE" for "AdBcEf5" is OK, but fail for any string end with "5" like "ABE5" "A5" "AB5", etc.

Is the behaviour you'd like to see that a query string (e.g. "AB5") is considered a match for a symbol name (e.g. "AdBcEf5") if the query string is any subsequence of the symbol name?

Correct.
If it's about the trade off for better fuzzy pattern matching for speed, I would love to have, if it's possible, to allow user take the option to have a customizable query, for marco too, because I write and view simple C/C++ project, I will not worry about it slow down anything.  And I think one of the reason why Clangd became popular for  it's wonderful user setting options.


BUILD FAILED

i try sample and get this error
my xcode Version 7.2.1 (7C1002)
buidRoot: /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build
logDir: /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Logs/Build

Learnt compile:     /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c -primary-file /Users/binaryboy/Desktop/InjectTest/InjectTest/ViewController.swift /Users/binaryboy/Desktop/InjectTest/InjectTest/AppDelegate.swift -target x86_64-apple-ios9.2 -enable-objc-interop -sdk /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -I /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -F /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -enable-testing -g -module-cache-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/ModuleCache -serialize-debugging-options -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/swift-overrides.hmap -Xcc -iquote -Xcc /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-generated-files.hmap -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-own-target-headers.hmap -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-all-target-headers.hmap -Xcc -iquote -Xcc /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-project-headers.hmap -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator/include -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/DerivedSources/x86_64 -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/DerivedSources -Xcc -DDEBUG=1 -Xcc -working-directory/Users/binaryboy/Desktop/InjectTest -emit-module-doc-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController~partial.swiftdoc -Onone -module-name InjectTest -emit-module-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController~partial.swiftmodule -serialize-diagnostics-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController.dia -emit-dependencies-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController.d -emit-reference-dependencies-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController.swiftdeps -o iOSInjectionProject/x86_64/injecting_class.o

real	0m0.894s
user	0m0.125s
sys	0m0.206s
ls: .framework: No such file or directory

Building iOSInjectionProject/InjectionBundle.xcodeproj
"/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild"  -configuration Debug -arch x86_64 -sdk iphonesimulator

2016-03-13 19:03:04.131 xcodebuild[11360:4209239] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSImageNamed.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 19:03:04.135 xcodebuild[11360:4209239] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CocoaPodUI.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 19:03:04.136 xcodebuild[11360:4209239] Failed to load plugin at: /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CocoaPodUI.xcplugin, skipping.  Reason for failure: *** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]
2016-03-13 19:03:04.151 xcodebuild[11360:4209239] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CATweakerSense.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 19:03:04.154 xcodebuild[11360:4209239] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ACCodeSnippetRepository.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 19:03:04.677 xcodebuild[11360:4209239] ### Failed to load Addressbook class CNContactNameFormatter
objc[11360]: Class VWKProject is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[11360]: Class VWKWorkspaceManager is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[11360]: Class VWKRunOperation is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[11360]: Class VWKShellHandler is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[11360]: Class VWKDocumentationManager is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[11360]: Class VWKXCodeConsole is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
Build settings from command line:
    ARCHS = x86_64
    SDKROOT = iphonesimulator9.2

=== BUILD TARGET InjectionBundle OF PROJECT InjectionBundle WITH CONFIGURATION Debug ===

Check dependencies

CompileC build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.o BundleContents.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject
    export LANG=en_US.US-ASCII
    export PATH="/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fobjc-arc -fmodules -gmodules -fmodules-prune-interval=86400 -fmodules-prune-after=345600 -fbuild-session-file=/var/folders/yv/0hqnb34j6d1dtx56l150y2jh0000gp/C/org.llvm.clang/ModuleCache/Session.modulevalidation -fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module -Werror=non-modular-include-in-framework-module -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wmissing-prototypes -Wno-implicit-atomic-properties -Wno-arc-repeated-use-of-weak -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -DDEBUG=1 -isysroot /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -mios-simulator-version-min=9.2 -g -Wno-sign-conversion -fobjc-abi-version=2 -fobjc-legacy-dispatch -iquote /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-generated-files.hmap -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-own-target-headers.hmap -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-all-target-headers.hmap -iquote /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-project-headers.hmap -iquote.. -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator/include -I/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk/usr/include/libxml2 -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/DerivedSources/x86_64 -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/DerivedSources -F/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -include /var/folders/yv/0hqnb34j6d1dtx56l150y2jh0000gp/C/com.apple.DeveloperTools/7.2.1-7C1002/Xcode/SharedPrecompiledHeaders/InjectionBundle-Prefix-gxzsmsoyfduvciatahmfsfmkaqpe/InjectionBundle-Prefix.pch -MMD -MT dependencies -MF /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.d --serialize-diagnostics /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.dia -c /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/BundleContents.m -o /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.o

Ld build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle normal x86_64
    cd /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject
    export IPHONEOS_DEPLOYMENT_TARGET=9.2
    export PATH="/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -bundle -isysroot /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -L/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -F/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -filelist /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle.LinkFileList -mios-simulator-version-min=9.2 -Xlinker -objc_abi_version -Xlinker 2 x86_64/injecting_class.o -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator/InjectTest.app/Frameworks -undefined dynamic_lookup -fobjc-arc -fobjc-link-runtime -framework UIKit -framework QuartzCore -framework OpenGLES -framework Foundation -framework CoreGraphics -Xlinker -dependency_info -Xlinker /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle_dependency_info.dat -o /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle
ld: warning: directory not found for option '-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator'
ld: library not found for -lswiftFoundation for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

* BUILD FAILED

The following build commands failed:
	Ld build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle normal x86_64
(1 failure)

* Build Failed with status: 65. You may need to open and edit the bundle project to resolve issues with either header include paths or Frameworks the bundle links against.

 at /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/InjectionPlugin.xcplugin/Contents/Resources/common.pm line 57.
	main::error('Build Failed with status: 65. You may need to open and edit t...') called at /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/InjectionPlugin.xcplugin/Contents/Resources/injectSource.pl line 460
 Bundle build failed *

Disconnected from: /Users/binaryboy/Library/Developer/CoreSimulator/Devices/B02AE16A-BAED-4328-A604-1C679C510A71/data/Containers/Data/Application/03B50383-71AD-47D8-8506-9FAF4D342699
Connection from: /Users/binaryboy/Library/Developer/CoreSimulator/Devices/B02AE16A-BAED-4328-A604-1C679C510A71/data/Containers/Data/Application/949A7C34-354B-4909-A350-0C560B8223F1 x86_64 (129)
buidRoot: /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build
logDir: /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Logs/Build

Learnt compile:     /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -c -primary-file /Users/binaryboy/Desktop/InjectTest/InjectTest/ViewController.swift /Users/binaryboy/Desktop/InjectTest/InjectTest/AppDelegate.swift -target x86_64-apple-ios9.2 -enable-objc-interop -sdk /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -I /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -F /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -enable-testing -g -module-cache-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/ModuleCache -serialize-debugging-options -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/swift-overrides.hmap -Xcc -iquote -Xcc /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-generated-files.hmap -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-own-target-headers.hmap -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-all-target-headers.hmap -Xcc -iquote -Xcc /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/InjectTest-project-headers.hmap -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator/include -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/DerivedSources/x86_64 -Xcc -I/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/DerivedSources -Xcc -DDEBUG=1 -Xcc -working-directory/Users/binaryboy/Desktop/InjectTest -emit-module-doc-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController~partial.swiftdoc -Onone -module-name InjectTest -emit-module-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController~partial.swiftmodule -serialize-diagnostics-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController.dia -emit-dependencies-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController.d -emit-reference-dependencies-path /Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Intermediates/InjectTest.build/Debug-iphonesimulator/InjectTest.build/Objects-normal/x86_64/ViewController.swiftdeps -o iOSInjectionProject/x86_64/injecting_class.o

real	0m0.263s
user	0m0.110s
sys	0m0.086s
ls: .framework: No such file or directory

Building iOSInjectionProject/InjectionBundle.xcodeproj
"/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild"  -configuration Debug -arch x86_64 -sdk iphonesimulator

2016-03-13 20:45:42.553 xcodebuild[40107:4360505] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSImageNamed.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 20:45:42.729 xcodebuild[40107:4360505] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CocoaPodUI.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 20:45:42.729 xcodebuild[40107:4360505] Failed to load plugin at: /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CocoaPodUI.xcplugin, skipping.  Reason for failure: *** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]
2016-03-13 20:45:42.817 xcodebuild[40107:4360505] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/CATweakerSense.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 20:45:43.014 xcodebuild[40107:4360505] [MT] PluginLoading: Required plug-in compatibility UUID F41BD31E-2683-44B8-AE7F-5F09E919790E for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ACCodeSnippetRepository.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2016-03-13 20:45:44.125 xcodebuild[40107:4360505] ### Failed to load Addressbook class CNContactNameFormatter
objc[40107]: Class VWKProject is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[40107]: Class VWKWorkspaceManager is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[40107]: Class VWKRunOperation is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[40107]: Class VWKShellHandler is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[40107]: Class VWKDocumentationManager is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
objc[40107]: Class VWKXCodeConsole is implemented in both /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/ObjectGraph.xcplugin/Contents/MacOS/ObjectGraph and /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/KSHObjcUML.xcplugin/Contents/MacOS/KSHObjcUML. One of the two will be used. Which one is undefined.
Build settings from command line:
    ARCHS = x86_64
    SDKROOT = iphonesimulator9.2

=== BUILD TARGET InjectionBundle OF PROJECT InjectionBundle WITH CONFIGURATION Debug ===

Check dependencies

CompileC build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.o BundleContents.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject
    export LANG=en_US.US-ASCII
    export PATH="/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fobjc-arc -fmodules -gmodules -fmodules-prune-interval=86400 -fmodules-prune-after=345600 -fbuild-session-file=/var/folders/yv/0hqnb34j6d1dtx56l150y2jh0000gp/C/org.llvm.clang/ModuleCache/Session.modulevalidation -fmodules-validate-once-per-build-session -Wnon-modular-include-in-framework-module -Werror=non-modular-include-in-framework-module -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wmissing-prototypes -Wno-implicit-atomic-properties -Wno-arc-repeated-use-of-weak -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -Wno-deprecated-implementations -DDEBUG=1 -isysroot /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -mios-simulator-version-min=9.2 -g -Wno-sign-conversion -fobjc-abi-version=2 -fobjc-legacy-dispatch -iquote /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-generated-files.hmap -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-own-target-headers.hmap -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-all-target-headers.hmap -iquote /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/InjectionBundle-project-headers.hmap -iquote.. -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator/include -I/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk/usr/include/libxml2 -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/DerivedSources/x86_64 -I/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/DerivedSources -F/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -include /var/folders/yv/0hqnb34j6d1dtx56l150y2jh0000gp/C/com.apple.DeveloperTools/7.2.1-7C1002/Xcode/SharedPrecompiledHeaders/InjectionBundle-Prefix-gxzsmsoyfduvciatahmfsfmkaqpe/InjectionBundle-Prefix.pch -MMD -MT dependencies -MF /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.d --serialize-diagnostics /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.dia -c /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/BundleContents.m -o /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/BundleContents.o

Ld build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle normal x86_64
    cd /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject
    export IPHONEOS_DEPLOYMENT_TARGET=9.2
    export PATH="/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -bundle -isysroot /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -L/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -F/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -filelist /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle.LinkFileList -mios-simulator-version-min=9.2 -Xlinker -objc_abi_version -Xlinker 2 x86_64/injecting_class.o -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator/InjectTest.app/Frameworks -undefined dynamic_lookup -fobjc-arc -fobjc-link-runtime -framework UIKit -framework QuartzCore -framework OpenGLES -framework Foundation -framework CoreGraphics -Xlinker -dependency_info -Xlinker /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle_dependency_info.dat -o /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle
ld: warning: directory not found for option '-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator'
ld: library not found for -lswiftFoundation for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

 BUILD FAILED

The following build commands failed:
	Ld build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle normal x86_64
(1 failure)

 Build Failed with status: 65. You may need to open and edit the bundle project to resolve issues with either header include paths or Frameworks the bundle links against.

 at /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/InjectionPlugin.xcplugin/Contents/Resources/common.pm line 57.
	main::error('Build Failed with status: 65. You may need to open and edit t...') called at /Users/binaryboy/Library/Application Support/Developer/Shared/Xcode/Plug-ins/InjectionPlugin.xcplugin/Contents/Resources/injectSource.pl line 460
 Bundle build failed ***

I need just a little more of the console output to tell you why this failed.

@johnno1962  i update issue

Thanks, The error is due to the following:
ld: warning: directory not found for option '-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator'
ld: library not found for -lswiftFoundation for architecture x86_64
clang: error: linker command failed with exit code 1
That driectory is present on my machine, can you check?

i found the directory

@johnno1962  can you help me ?

The problem is the linker command is not working:
/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -bundle -isysroot /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -L/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -F/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -filelist /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle.LinkFileList -mios-simulator-version-min=9.2 -Xlinker -objc_abi_version -Xlinker 2 x86_64/injecting_class.o -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator/InjectTest.app/Frameworks -undefined dynamic_lookup -fobjc-arc -fobjc-link-runtime -framework UIKit -framework QuartzCore -framework OpenGLES -framework Foundation -framework CoreGraphics -Xlinker -dependency_info -Xlinker /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle_dependency_info.dat -o /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle
Without access to your machine, I can’t say more.
It is due to the following which I can’t understand:
ld: warning: directory not found for option '-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator'

can you upload your example project

There is no example project to speak of. My sugestion is you start with a far simpler project and see if you can get injection to work then work you way up to trying to get this project to work.

it's very simple app i want to change backgroundcolor of viewcontroller, can you tell me the permission of XCode

The way to track this down is to past the link command into terminal and see if you can get it working:
/Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -bundle -isysroot /Volumes/MAC2/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator9.2.sdk -L/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -F/Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator -filelist /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle.LinkFileList -mios-simulator-version-min=9.2 -Xlinker -objc_abi_version -Xlinker 2 x86_64/injecting_class.o -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator -F/Users/binaryboy/Library/Developer/Xcode/DerivedData/InjectTest-gitdwimdtpewpoalhymgncrpjydw/Build/Products/Debug-iphonesimulator/InjectTest.app/Frameworks -undefined dynamic_lookup -fobjc-arc -fobjc-link-runtime -framework UIKit -framework QuartzCore -framework OpenGLES -framework Foundation -framework CoreGraphics -Xlinker -dependency_info -Xlinker /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/InjectionBundle.build/Debug-iphonesimulator/InjectionBundle.build/Objects-normal/x86_64/InjectionBundle_dependency_info.dat -o /Users/binaryboy/Desktop/InjectTest/iOSInjectionProject/build/Debug-iphonesimulator/InjectionBundle.bundle/InjectionBundle
ld: warning: directory not found for option '-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator
But I think I can see the problem now. You have a non-standard Xcode path:
/Volumes/MAC2/Applications/Xcode.app
Would you be able to move your Xcode and see if that makes a difference?

i will check it

Problem is here in the script:
#if ( $isSwift ) {
my ($toolchain) = $learnt =~ m@(/Applications/Xcode.*?/XcodeDefault.xctoolchain)/@;
my $sdk = ($config =~ /-sdk (\w+)/)[0] || 'macosx';
$obj .= "", "-L'$toolchain'/usr/lib/swift/$sdk";
$obj .= "", "-F$buildRoot/Products/Debug-$sdk" if $buildRoot;
#}

you could change it to (injectSource.pl in plugin):
my ($toolchain) = $learnt =~ m@(\S*/Applications/Xcode.*?/XcodeDefault.xctoolchain)/@;

yes
i must change this path
"/Applications/Xcode.*?/XcodeDefault.xctoolchain
"

\S represent the current path of xcode

or better:
my ($toolchain) = $learnt =~ m@($xcodeApp.*?/XcodeDefault.xctoolchain)/@;

\S+ in regexp for any non-spaces

Or better still:
my ($toolchain) = $learnt =~ m@(@{[$xcodeApp||'/Applications/Xcode']}.*?/XcodeDefault.xctoolchain)/@;

thanks this fix my problem please update the script ,but i have other problem
Ignore any warning, Swizzled InjectTest.ViewController 0x1145cf3d0 -> 0x108e87f10
and the inject not work

Good luck

@johnno1962  can you update script in master

done


Implemented complimentary tolerances for classic search

Changes to unit tests are due to changes in intensity calculation.

Besides Codacy not understanding what the named tuples are, I think it's good to go.

What's the motivation for removing ReplaceObservedWithComplementaryPeaks, and instead duplicating the match ions code for the addComp case?

Tolerances must be recalculated for complementary ions. To do this for observed ions will increase search time for classic searches, so there is some duplication in code to prevent that.


Add daily project info caching

Duplicate of #9, which GitHub won't let me re-open now that we renamed the master branch.
There are notes in there that need to be acted on.

Update the original PR with some refactors and additions. Should have addressed all of the original feedback with some improvements as I saw fit.
The command now contains a -f flag as well to force an updated snapshot for the current day (updating existing records).

Changes

Rebase original branch on latest main
Added "@babel/preset-env": "^7.9.0" to dev dependencies to address npm build error "Cannot find module '@babel/compat-data/corejs3-shipped-proposals'". More info in this thread: https://github.com/JeffreyWay/laravel-mix/issues/2383
Update current readme to include caching info
Add Snapshot model
Update snapshot command to use eloquent model with some better formatting/comments
Add progress bar and more verbose output to command
Add git ignore rule to exclude settings in .vscode/*
Added snapshot_date field to snapshots table
Changed debt_score field from decimal to string to avoid a weird issue where the updateOrCreate would touch the updated_at field without changing any other values in the record
Change to use both timestamps() in the snapshots table migration, since the snapshot_date field is the one that we'll use for tracking anyway
Add -f|--force flag to snapshot:today command to perform an update on all projects, updating existing snapshots as needed

@mattstauffer Since you created this PR I can't tag you for review, but it's ready to look at again.

Great work, @jakebathman, thank you so much!!!

Thank you so much for finishing this up @jakebathman!


AWS Security Hub Findings integration

This is a feature request:
With the AWS Security Hub aggregating security findings from plethora of AWS tools and external providers it'd be great if you had "AWS Security Hub Findings integration".
Is this on the roadmap/eta?

Haven't used that feature.
Open to a PR!


Allow additional configuration of etcd

We want to use the election_timeout_in_milliseconds parameter for etcd, but the templates don't support this yet. This change should allow use of any config parameters.

Hi @nickwei84
We generally don't want to support arbitrary parameter configuration in the spiff templates.  The spiff flow would ideally be simple, explicity, and easy to understand.  This is unfortunately not currently the case, but we don't want to exacerbate the problem.
In this case, a preferable option would be:
election_timeout_in_milliseconds: (( merge || nil ))

Similar to the DEA configuration below in that same file.

Cool I will look into the alternative option. Thanks!


Exec format error when running container on Raspberry Pi 3B

I'm getting the exec format error in the logs when attempting to run the latest tag on my Raspberry Pi 3B.
$ uname -a
Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

latest tag runs fine on my Atomic Pi (x86_64), so there seems to be something amiss with the way the arch gets detected.
I was able to build the image myself on the Pi 3B and it works great.

Seeing this for the following images too:

planefinder
flightradar24
radarbox

Acknowledging this. Please accept my apologies - something has gone awry in my build farm. I'm actively troubleshooting this and hope to have it resolved shortly.

No worries. Thanks for maintaining this! Just thought you'd like to know!

Appreciate the heads up! :-)

@echoz @seanauff all images should be fixed now!

Tested and working, thanks!


Testing coqhammer for coq 8.16 to 8.19

I guess this was subsumed by https://github.com/coq-community/coq-nix-toolbox/pull/228


Support changing stakers at runtime

We always start proposing now and with a set of keypairs. If the set is
empty it's effectively the same thing as not proposing. Proposing is not
interrupted by a change in staking keypairs, but it is woken up by this
change. If we are in the middle of staking with different keypairs, that
action is finished before the new keys kick in.
Local_state is now a table from public keys to delegation info and we
check vrfs for all the keypairs that we wish to stake.
I've included a handler in Ledger.ml as it may be useful later even
though I ended up not using it in this PR.
Tests pass, thorough testing of swapping proposers is todo

I'm not moving the delegators out of the Snapshot in this PR as it's too big of a control flow change at the last minute. See #2582 for note on this.


Traffic between traefik and app over IPv6

Welcome!

[x] Yes, I've searched similar issues on GitHub and didn't find any.
[x] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?
As documented in https://doc.traefik.io/traefik/providers/docker/#ipv4-ipv6  Traefik prefers IPv4 before IPv6, when my docker-setup is dualstack.
Since there are Applications, which binds only to IPv6, but the container nevertheless have both IPv4 and IPv6-Addresses, it would be nice if there were an option to change this behavior and prefer IPv6 before IPv4.

Hey @fzenger7,
Thanks for your suggestion.
We are interested in this issue, but we’re unsure about the use case and the traction it will receive. We are going to leave the status as kind/proposal to give the community time to let us know if they would like this idea.
We will reevaluate as people respond.
Conversation is time-boxed to 6 months.


Rename status to measures

Rename status to measures

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (02917d7) to head (b3134d9).
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##              main        #8   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines           71        72    +1
  Branches         6         6
=========================================
+ Hits            71        72    +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Track expense - Incorrect amount in paid message in LHN when there is tracking and request

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.62-0
Reproducible in staging?: y
Reproducible in production?: no  new feature
If this was caught during regression testing, add the test name, ID and link from TestRail: n/a
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause internal team
Slack conversation:
Action Performed:

Go to staging.new.expensify.com
Go to workspace chat with no request history.
Create a track manual expense ($10) with merchant A.
Create a $5 manual request (not track expense) with merchant B.
Go to expense report.
Submit and approve the report
Pay elsewhere the report.

Expected Result:
In Step 6, the approval message should show the correct amount.
In Step 7, the system message for payment should show the correct amount in LHN preview.
Actual Result:
In Step 6, the approval message shows the total amount first ($15), then changes to the correct amount ($5).
In Step 7, the system message for payment should $15 in LHN, while it shows $5 in the expense report.
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/38435837/6fe3716d-4f86-4cce-8865-00d3ad3d01ea

View all open jobs on GitHub

@cead22 FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

We think this bug might be related to #wave-collect - Release 1

Not a blocker, requires a BE change to ensure we send back the total not just the reimbursable total

Track expense is a #vip-vsb project, moving it over.

@thienlnam are you taking on this issue as the BE engineer?

Yup, taking this on

Tying together with https://github.com/Expensify/App/issues/40266

Held on https://github.com/Expensify/App/issues/40266

Still held on https://github.com/Expensify/App/issues/40266 - if we could find an internal engineer to take that, that would be great

is this still held if #40266 is no longer reproducible?

Should be resolved now


Book covers with metadata

I think it would be neat to have covers for the book as metadata like in the image attached.
Could be a toggle in obsidian settings too.
Images would not need to be stored in obsidian itself since there are plenty book cover APIs.

Is anyone else interested in this? Might just do it myself tommorow

@ceselder this is something that you can easily do by modifying your notes template

Simply add the following:
![]({{imageUrl}})

If you want more control with the image size, then your next best bet is to use an HTML image tag <img src="{{imageUrl}}" width="200px"/>.

Oh my bad!

I would love to have the covers.
I tried '  ' and it did not work for me.

@jimclay75051 what the output of that markup?

I'm quite possible not doing it correctly.

Basically, it doesn't do anything.

@jimclay75051 You need to add ![]({{imageUrl}}) to your "template" and not an existing note that has already been generated.
You need to go to Kindle Highlight's settings -> Manage Template and then modify the Content template.
After that is done, you will need to regenerate your existing notes. Best way is to delete your existing notes and sync again.
If you do not want to delete your existing notes, you will need to manually add the image link yourself. You should see the book image link available in the frontmatter.

You are correct. That worked. Thank you.


Fix #242 - Add template field to CustomForm model

Purpose
User wants to create templates from a form. So, they can share this templates with their organizations and create a new from.
Approach
is_template field added to CutomForm model in order to seperate templates from Forms.
_Related ticket: Humanitec/ActivityAPI#242

@yilmazbekdemir

You should rebase instead of merging. You need to remove the commit  @jefmoura Merge pull request #1092 from jefmoura/234-add-indicator-disaggregati
You mustn't change a migration script manually, only in some specific cases like issues with UUID and when you need to run a custom script.

0 used for other models, also for is_public and default_global fields in this CustomForm model. I didn't want to change structure.


feat: Allow disabling CRDs for specific controllers

Currently, installCRDs is a global flag and there's no way to only install CRDs for certain controllers
This PR adds another level (true by default for retrocompatibility) that can be used to disable CRD installation for a specific controller
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] helm-docs are updated
[x] Helm chart is tested
[x] Update artifacthub.io/changes in Chart.yaml
[x] Run make reviewable

@julienduchesne what is the use-case for this? Why would you install a controller without its CRDs, it will just crash loop.

@julienduchesne what is the use-case for this? Why would you install a controller without its CRDs, it will just crash loop.

I want to use it in combination with create=false

I want to use it in combination with create=false

So then we don't need to add a new flag for this, each CRD should check controller.create

I want to use it in combination with create=false

So then we don't need to add a new flag for this, each CRD should check controller.create

The new flag is meant to maintain retro-compatibility. If this is now controlled by the create flag, then CRDs will disappear unexpectedly for a minor bump 🤔

If this is now controlled by the create flag, then CRDs will disappear unexpectedly for a minor bump

I don't think this should affect anyone, if there is no controller to act on the CRs then no harm in removing the CRDs.

If this is now controlled by the create flag, then CRDs will disappear unexpectedly for a minor bump

I don't think this should affect anyone, if there is no controller to act on the CRs then no harm in removing the CRDs.

Makes sense! Done!

I don't think this should affect anyone, if there is no controller to act on the CRs then no harm in removing the CRDs.

Having just been bitten by this (it affects people who use the chart to only install the CRDs). It would be great to tag changes like this as changes, even if the chance of them actually occurring seems small.