update @ngtools/webpack issuse

Versions.
nodejs 6.9.2
os win10x 64
Repro steps.
when i update  @ngtools/webpack from 1.2.8 to 1.2.14,webpack build no error output,but nothing generate.i never change any config file before update.
The log given by the failure.
no error output
Desired functionality.
i want generate bundle js file
Mention any other details that might be useful.
webpack.aot.config.js
var webpack = require('webpack');
const HtmlWebpackPlugin = require('html-webpack-plugin');
var webpackMerge = require('webpack-merge');
var ExtractTextPlugin = require('extract-text-webpack-plugin');
var commonConfig = require('./webpack.common.js');
var helpers = require('./helpers');
const AotPlugin = require('@ngtools/webpack').AotPlugin;

const ENV = process.env.NODE_ENV = process.env.ENV = 'production';

module.exports = webpackMerge(commonConfig, {
  entry: {
    'app': helpers.rootAngular('app/main.ts')
  },
  output: {
    path: helpers.outputBuild(),
    filename: '[name].[hash].bundle.js',
    chunkFilename: '[id].[chunkhash].chunk.js'
  },

  module: {
    loaders: [
      { test: /\.ts$/, loaders: ['@ngtools/webpack'] },
      {
        test: /\.css$/,
        exclude: helpers.rootAngular('app'),
        loader: ExtractTextPlugin.extract({ fallbackLoader: 'style-loader', loader: 'css-loader' })
      },
    ]
  },
  plugins: [
    // new OptimizeJsPlugin({
    //   sourceMap: false
    // }),
    new AotPlugin({
        tsConfigPath: helpers.root('tsconfig.aot.json'),
        entryModule: helpers.rootAngular('app/app.module#AppModule')
    }),
    new webpack.NoEmitOnErrorsPlugin(),
    new webpack.optimize.UglifyJsPlugin({
            beautify: false,
            mangle: {
                screw_ie8: true,
                keep_fnames: true
            },
            compress: {
                warnings: false,
                screw_ie8: true
            },
            comments: false
    }),
    new HtmlWebpackPlugin({
      template: helpers.rootAngular('index.html'),
      minify:{
        removeComments:true,
        collapseWhitespace: true
      }
    }),
    new ExtractTextPlugin('[name].[hash].css'),
    new webpack.DefinePlugin({
      'process.env': {
        'ENV': JSON.stringify(ENV)
      }
    })
  ]
});

I back to 1.2.8, all work fine,so 1.2.14 has bug? or has new config method?or dependence other module?

Same problem here. When we upgrade from 1.2.3 to 1.2.14 and then running in aot mode does not work. Same problem on 1.3.0. It seems that the modules for lazy loading are not generated properly. The error we got is (products is one of our modules that we lazy load):
EXCEPTION: Uncaught (in promise): Error: Cannot find module './products/products.module.ngfactory'.
Error: Cannot find module './products/products.module.ngfactory'.
    at webpackEmptyContext (http://localhost:9003/js/app.js:46913:8) [angular]
    at SystemJsNgModuleLoader.loadFactory (http://localhost:9003/js/app.js:47017:40) [angular]
    at SystemJsNgModuleLoader.load (http://localhost:9003/js/app.js:46989:35) [angular]
    at RouterConfigLoader.loadModuleFactory (http://localhost:9003/js/app.js:17837:128) [angular]
    at RouterConfigLoader.load (http://localhost:9003/js/app.js:17824:81) [angular]
    at MergeMapSubscriber.project (http://localhost:9003/js/app.js:70592:111) [angular]
    at MergeMapSubscriber._tryNext (http://localhost:9003/js/vendor.js:1669:27) [angular]
    at MergeMapSubscriber._next (http://localhost:9003/js/vendor.js:1659:18) [angular]
    at MergeMapSubscriber.Subscriber.next (http://localhost:9003/js/vendor.js:230:18) [angular]
    at ScalarObservable._subscribe (http://localhost:9003/js/vendor.js:2899:24) [angular]
    at ScalarObservable.Observable.subscribe (http://localhost:9003/js/vendor.js:51:27) [angular]
    at MergeMapOperator.call (http://localhost:9003/js/vendor.js:1634:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MergeMapOperator.call (http://localhost:9003/js/vendor.js:1634:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at CatchOperator.call (http://localhost:9003/js/vendor.js:2945:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at Object.subscribeToResult (http://localhost:9003/js/vendor.js:457:27) [angular]
    at MergeAllSubscriber._next (http://localhost:9003/js/vendor.js:1517:42) [angular]
    at MergeAllSubscriber.Subscriber.next (http://localhost:9003/js/vendor.js:230:18) [angular]
    at MapSubscriber._next (http://localhost:9003/js/vendor.js:1388:26) [angular]
    at MapSubscriber.Subscriber.next (http://localhost:9003/js/vendor.js:230:18) [angular]
    at ArrayObservable._subscribe (http://localhost:9003/js/vendor.js:1096:28) [angular]
    at ArrayObservable.Observable.subscribe (http://localhost:9003/js/vendor.js:51:27) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MergeAllOperator.call (http://localhost:9003/js/vendor.js:1495:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at FirstOperator.call (http://localhost:9003/js/vendor.js:3661:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at CatchOperator.call (http://localhost:9003/js/vendor.js:2945:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at Object.subscribeToResult (http://localhost:9003/js/vendor.js:457:27) [angular]
    at MergeAllSubscriber._next (http://localhost:9003/js/vendor.js:1517:42) [angular]
    at MergeAllSubscriber.Subscriber.next (http://localhost:9003/js/vendor.js:230:18) [angular]
    at ScalarObservable._subscribe (http://localhost:9003/js/vendor.js:2899:24) [angular]
    at ScalarObservable.Observable.subscribe (http://localhost:9003/js/vendor.js:51:27) [angular]
    at MergeAllOperator.call (http://localhost:9003/js/vendor.js:1495:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at LastOperator.call (http://localhost:9003/js/vendor.js:5713:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at CatchOperator.call (http://localhost:9003/js/vendor.js:2945:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at Object.subscribeToResult (http://localhost:9003/js/vendor.js:457:27) [angular]
    at CatchSubscriber.error (http://localhost:9003/js/vendor.js:2975:33) [angular]
    at MapSubscriber.Subscriber._error (http://localhost:9003/js/vendor.js:269:26) [angular]
    at MapSubscriber.Subscriber.error (http://localhost:9003/js/vendor.js:243:18) [angular]
    at CatchSubscriber.error (http://localhost:9003/js/vendor.js:2970:34) [angular]
    at FirstSubscriber.Subscriber._error (http://localhost:9003/js/vendor.js:269:26) [angular]
    at FirstSubscriber.Subscriber.error (http://localhost:9003/js/vendor.js:243:18) [angular]
    at MergeAllSubscriber.OuterSubscriber.notifyError (http://localhost:9003/js/vendor.js:421:26) [angular]
    at InnerSubscriber._error (http://localhost:9003/js/vendor.js:11489:21) [angular]
    at InnerSubscriber.Subscriber.error (http://localhost:9003/js/vendor.js:243:18) [angular]
    at CatchSubscriber.error (http://localhost:9003/js/vendor.js:2970:34) [angular]
    at Observable._subscribe (http://localhost:9003/js/app.js:70273:104) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:51:27) [angular]
    at CatchOperator.call (http://localhost:9003/js/vendor.js:2945:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at Object.subscribeToResult (http://localhost:9003/js/vendor.js:457:27) [angular]
    at MergeAllSubscriber._next (http://localhost:9003/js/vendor.js:1517:42) [angular]
    at MergeAllSubscriber.Subscriber.next (http://localhost:9003/js/vendor.js:230:18) [angular]
    at MapSubscriber._next (http://localhost:9003/js/vendor.js:1388:26) [angular]
    at MapSubscriber.Subscriber.next (http://localhost:9003/js/vendor.js:230:18) [angular]
    at ArrayObservable._subscribe (http://localhost:9003/js/vendor.js:1096:28) [angular]
    at ArrayObservable.Observable.subscribe (http://localhost:9003/js/vendor.js:51:27) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MergeAllOperator.call (http://localhost:9003/js/vendor.js:1495:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at FirstOperator.call (http://localhost:9003/js/vendor.js:3661:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at CatchOperator.call (http://localhost:9003/js/vendor.js:2945:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at CatchOperator.call (http://localhost:9003/js/vendor.js:2945:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MergeMapOperator.call (http://localhost:9003/js/vendor.js:1634:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MergeMapOperator.call (http://localhost:9003/js/vendor.js:1634:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MergeMapOperator.call (http://localhost:9003/js/vendor.js:1634:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at MapOperator.call (http://localhost:9003/js/vendor.js:1359:23) [angular]
    at Observable.subscribe (http://localhost:9003/js/vendor.js:48:22) [angular]
    at http://localhost:9003/js/vendor.js:82:38 [angular]
    at new ZoneAwarePromise (http://localhost:9003/js/polyfills.js:4433:29) [angular]
    at Observable.forEach (http://localhost:9003/js/vendor.js:81:16) [angular]
    at http://localhost:9003/js/app.js:10086:18 [angular]
    at new ZoneAwarePromise (http://localhost:9003/js/polyfills.js:4433:29) [angular]
    at Router.runNavigate (http://localhost:9003/js/app.js:10025:16) [angular]
    at http://localhost:9003/js/app.js:9994:51 [angular]
    at Object.onInvoke (http://localhost:9003/js/app.js:4990:37) [angular]
    at Zone.1062.Zone.run (http://localhost:9003/js/polyfills.js:3830:43) [angular => angular]
    at http://localhost:9003/js/polyfills.js:4417:57 [angular]
    at Object.onInvokeTask (http://localhost:9003/js/app.js:4981:37) [angular]
    at ZoneDelegate.1062.ZoneDelegate.invokeTask (http://localhost:9003/js/polyfills.js:4070:36) [angular]
    at Zone.1062.Zone.runTask (http://localhost:9003/js/polyfills.js:3870:47) [<root> => angular]
    at drainMicroTaskQueue (http://localhost:9003/js/polyfills.js:4250:35) [<root>]
    at HTMLDocument.ZoneTask.invoke (http://localhost:9003/js/polyfills.js:4128:25) [<root>]

@keyiis @jruef is this still a problem for you? Can you upload a repository where we can see this problem?

After I update angular2 to angular4 and modify many code to adapt angular4,all work fine,But I still don't know why.

@filipesilva The issue vanished after upgrading to angular 4.

I'm glad to hear this isn't an issue anymore for you 👍


feat: iterate all repositories

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


Basically no activity in the last 4 months =(

1 commit in the last 4 months for a library with almost 2000 commits in the previous 3 and a half years... A betting man would have to bet that redux-form is stuck, and that basically none of the open issues will be addressed, much less fixed.
I think I can speak for thousands of people when I say it'd be nice to have some visibility into plans for this project. Do the maintainers plan to continue development?

Uh, there were quite a few commits in the last 4 months...

yay, including christmas commits! 🎄
But yeah. The library is quite dead yes. Erik's focus is definitely on Final Form these days.
I have been a contributor since 2016 and I never really got to do code changes.
Redux Form is just too complex, and nearly everyone who wants to take a stab gets/will get frustrated by the codebase.
There was a trend some time ago that everything should be kept in the Redux store,  but nowadays this trend seems to be dying (well, not that I have done much work with Redux since then) -- and form status definitely shouldn't.
I'll leave it to @erikras to add more insights.

It is easy to migrate to Final Form, probably it is what we should be focusing on.

@gustavohenke
Thanks for the info Gustavo! You're right about there being more commits in the last 4 months -- I meant to say one new commit in 2019 =P
I don't mind being downvoted if it means there's more info about rxf's future. Dead is a strong word, and that's a very compelling reason not to use rxf for a new project, which is useful info for anyone that sees this issue.
I think it's a shame, because rxf is a great library with a comprehensive API. It takes a while to get the hang of it, but it's very powerful. It would be great to see continued improvements, and IMO would continue to make rxf a great option for managing form state, even if the pace of development really slows down.
It looks like React Final Form never quite caught on the way rxf did. I guess I'll be trying Formik, which seems like it borrows heavily from rxf, but has a more active community and gets more love from its maintainers, at least as of April 2019.

It is easy to migrate to Final Form, probably it is what we should be focusing on.

Not if you use immutable, which Final Form doesn't support. :(

I've just started a new project and I was in the process of integrating redux-form and reading your ticket @kylebebak I heard about React Final Form, I guess is time to move and say goodbye to redux-form for future projects, so upvote for you to compensate the downvotes.

It is easy to migrate to Final Form, probably it is what we should be focusing on.

Unless you actually want to keep your form state in the store, which is an entirely reasonable thing to want.
Seems we need some sort of outreach to recruit some maintainers for this project that can handle it, as it's clearly still wanted:

As you're experienced in the matter, @gustavohenke - do you have any ideas?

Maintainers Wanted
Hi, guys. I'm the original author, and I no longer use Redux-Form in my own projects, because I've written a similar solution that I consider to be better in almost every way, React Final Form. I would love for Redux Form to live on (as I recently added to the readme), but I just don't have the time or desire to shepherd it into the future. #4431 is a rather large boulder on the path to the future, which I put quite a bit of effort into, but I can't spare any more.
If anyone would like to step up to lead Redux Form into the future, I'd be happy to hand over the reigns.

I sure would love to see the call for maintainers in the readme, too, Erik.  :)

Thanks for the update @erikras , and I think I'll be trying React Final Form in my next project.
For those that are interested in migration guides, I've heard this video is helpful.

@kylebebak I was all like, "Ooh! Someone made a migration video!" 🤣🤣🤣 Yes, that's the most useful video I've made.
@Asday Not a bad idea.

@erikras I would like to join as maintainer. I worked for the last few years with ReduxForm and helped the project in a few opportunities.

Hi there,
As a lover of redux-form (I learn so much with you @erikras - selectors, actions, ducks, renderProps, decoupling app, documentation, create a nice public api... - thx for that !!) - I really want to help to maintain the repo, but I'm a little bit a noob, sorry.
Even so, can I suggest a re-write of redux-form by using React-Final-Form (that seems to be the right way) behind the scene ? Including a tiny 'conf/adaptater' file to tell to React-Final-Form what to sync in the redux store and what to let in the local state.
Moreover, the base code is huge (and awesome !). I want to help on it, but my little brain is not ready. (someday...) . I think I am not alone in this case, and this is why I suggest a re-write.
If so, I wonder if can i take a part of this 're-write'.
What do you think  ?
Thx for reading,
Cheers :beers: - zazapeta

If that's a possibility, then perhaps its a good idea going forwards, but I'm not going to go back and rewrite my old projects to use an entirely different form framework, and my employer sure as heck won't pay me to do the same, either.
There's nothing actually wrong with redux-form, save a couple little bugs, and being a little behind react-redux.  All it needs is a couple maintainers like @renatoagds, who's already doing good work on the bugs.

Hi all, I step up as maintainer and I expect to change the scenario presented in this issue, based in that, we'll start:

A weekly patch/minor release, probably on Wednesdays.
Roadmap for v9, I opened an issue, to get ideas and feedback for the new major release. I ask help for everyone that's in this thread, to get involved in the plan for next version -> #4467

Based on that, I'll close this issue since we have plans to return our activity.

@erikras I want to step in! We are using redux-form in production. And increasing number of issues and unmerged PR's makes me sad.


Using sap.m.UploadCollection.setUploadUrl() not possible if instantUpload=false

OpenUI5 version: 1.32.9
Browser/version (+device/version): all
Any other tested browsers/devices(OK/FAIL): not browser related
According to the source code, it is not possible to change the upload URL of an UploadCollection if instantUpload is disabled.
UploadCollection.prototype.setUploadUrl = function(sUploadUrl) {
        if (!this.getInstantUpload()) {
            jQuery.sap.log.info("As property instantUpload is false it is not allowed to change uploadUrl at runtime.");
        }

Please explain the reasons, maybe enhance the documentation of setUploadUrl, or better, make it work.
How would you recommend to solve this?
I have a page with a NavContainer. On several pages within this container information is entered and as last step files can be selected in the UploadCollection. When I finally click "save" a new entity is created on the server by using the create method of v2.ODataModel. Now that I know the entity key which is generated on the server side I set the upload url of the UploadCollection according to the entity path .....sap/opu/odata/ZMYSVC/MyEntity('newKeyValue')/Attachments?$value
Since I can't change the upload Url after the control has been created, I can't make this approach work.

Thanks for reporting. I totally get your point and will forward to the dev-team. Internal reference is<PHONE_NUMBER>

Since you added the "documentation" label, does it mean you're only gonna mention that it doesn't work in the documentation or are you gonna do something to make it work?
I know, it's private members, and that my code could break with future versions, but since I need it, I just did this and it seems to work.
for (var i = 0; i < oUplCol._aFileUploadersForPendingUpload.length; i++) {
    oUplCol._aFileUploadersForPendingUpload[i].setUploadUrl(sUploadUrl);
}

We have to look into it.
In the end the labels are only a first classification.

Hello Frank683,
I'm Oli from the SAP dev team which is responsible for the UploadCollection. I got your point and for now I could not confirm that we will adapt the code to enable your use case. I will address your use case to our product team. Nevertheless I want to help you. First some explanation to the use case we build that flag instantUpload for. The use case is close to yours, but the possibility to upload files and attach these files to just created business object is done in a next step of the creation. In other words, the user enter all business object related information and clicks on a “next” button. Now the application creates the business object and the UI changes to the next step (like a wizard). On this step page the UploadCollection is used and instantiated related to the new business object like you do. We also saw the use case that instead of the step page a Popover was used.
And the beginning of the development we got the feedback from the requirement owner that changing the uploadUrl at runtime is not needed. In our team we decided to suppress the possibility. The reason was, to prevent applications to get in trouble. Now I see your use case or a different way to do, so we will rethink about it.
As I saw in the threat you already find a way but of course this could break. I would like to make you a suggestion which is more stable. You can create your own UploadCollection as an extension.
How to extend an existing control: https://openui5.hana.ondemand.com/#docs/guide/d5b756bf4e9a4d67961fa21e1ba12c9e.html
Here you can easily override the setUploadUrl method and make your modification without using internal variables. From a static code point of view, this should work. Feedback is very welcome.
sap.m.UploadCollection.extend("NewUploadCollection", {
metadata: {
},
setUploadUrl : function (value) {
this.setProperty("instantUpload", true, true);								// disables the default check
if (sap.m.UploadCollection.prototype.setUploadUrl) {
sap.m.UploadCollection.prototype.setUploadUrl.apply(this, arguments);	// ensure that the default setter is called. Doing so ensures that every extension or change will be executed as well.
// Because before we call the original function we override the instantUpload property for short time, to disable the check
}
this.setProperty("instantUpload", false, true);								// Afterwords we set back the instantUpload property to be back in a save and consistent state
},
renderer : "sap.m.UploadCollectionRenderer"
});
var oUC = new NewUploadCollection({
instantUpload : false,
uploadUrl : "MyCoolDomain/MyService/$value",
change : function () {
oUC.setUploadUrl("MyCoolerDomain/MyService/MyNewBusinessObject/$value");
}
}).placeAt("MyUploadCollection");
oUC.setUploadUrl("MyCoolerDomain/MyService/MyNewBusinessObject/$value");
var oLabel = new sap.m.Label({
text : oUC.getUploadUrl()
}).placeAt("Label");
Best regards,
Oli..

Hi Oli..
I tried like as you suggested, Now am able to set the uploadUrl  value in runtime. But the problem is, the am getting Url in runtime for upload, after adding attachment to uploadcollectionitems only.
Because of this, setUploadurl is not setting the uploadurl to the already added items which are pending for upload(i.e.,_aFileUploadersForPendingUpload--> uploadUrl:"/../../upoad"). Is there any other way to achieve the same. can u pls suggest?
regards,
Mahi

Hey Mahi,
I see the issue and hopefully got your execution flow. Sorry, but I see no way to archiev what you need without using internal variables. You can override the upload function on your own control and set the uploadUrl on all FileUploader instances inside the _aFileUploadersForPendingUpload array. You should hollow the same approach as before.
Best regards,
Oli..

Hi Oli,
Thanks for the reply, I achieved by overriding the upload function... I expected there will be some other way to reach same solution.
If there is option for setting upload url for _aFileUploadersForPendingUpload array with out overriding, will be nice :)

Hey Mahi,
I adressed the issue to our Product Owner and it is ranked. So we will invest here. Please be aware of that we do no feature downport and in this case I guess we will handle it as a feature.
Best regards, Oli..

Hi Oli,
While working on UploadCollection, I found another issue if instantUpload="false" is set  then UploadCollectionItem is not getting listed...
-Mahi

Hey Mahi,
not sure if I got your point correct. In case of instandUpload = false we expect no UploadCollectionItems via Binding and also no UploadCollectioItem template. So both use cases are not supported in on instance. Did I got you?
Best regards,
Oli..

Hi,
My requirement is,
In app for update mode, we are listing the existing request and we are listing existing attachments and also providing option to attach new files not by instandUpload option. Based on submit button action in the app.
In this case,I am trying to use UploadCollection and same time I wanted to list the already attached files against that request.
Problem is, UploadCollectionItem is not getting listed if we set instandUpload = false.

Hey Mahi,
thanks for the details. I talked to our Product Owner and User Interaction Designer. The outcome was, that we will not enhance the UploadCollection in this direction because it could end in a unclear user interaction and system behavior. Sorry for that.
Best regards,
Oli..

Hi Oli,
Thanks for your time to go through my points. If uploadcollection is not going to be enhanced further in this way,  what will be the best option for listing & uploading attachments in update mode kind of operations(Note:if instantupload = false). Do we need to use diff. UI for this functionalities.

Hey Mahi,
You’re welcome :-)
From UX perspective it would be better to have a different UI'S for read / create or update. Nevertheless you can have one UploadCollection to show all existing Attachments with a nice title and one for upload new attachments. If you do so, the user knows where what is :-)
With regards to the second point. We had a regression within the FileUploader control which we are reusing. It should work again with the next patch.
Best regards,
Oli..

Hi,
Can you suggest if getting Url in runtime for upload, after adding attachment to uploadcollectionitems has been fixed.
We have a requirement of adding multiple Attachments, after notes have been created, against the noteGuid created.
For single attachments, we were using File uploader(Working Perfectly).
For Multiple Attachment, we are changing UI5 Control to upload Collection(pending Upload) .
Thanks in Advance

Hello TANYBOSE,
In 1.63 a new control called UploadSet is being introduced and UploadCollection will be deprecated. UploadSet is a completely refactored UploadCollection that contains also long required features such as this one. API is not 100% backwards compatible with the old UploadCollection, hence the new name.
Cheers,
Jan

Hi Jan,
We have recently upgraded to 1.52.17.
I dont think, it will be easy to get upgraded to 1.63.
Can you please suggest a workaround for this issue.
Best Regards;
Tany

Hi Tany,
I've discussed with the team and unfortunately, there is no workaround as the feature was implemented as part of this newly written control. I am really sorry about that.
Regards,
Jan


Request field validation failed for favourites

DA module currently fails with return value "invalid_request (Request field validation failed.)" for parsing collections of favourites

fixed with updated console exploit


LSPS0 Unified Version Negotiation

As agreed in the latest meeting (13th of September), this PR standardizes and unifies the version negotiation for all LSPS.
Why
Every LSPS includes it's own versioning mechanism anyway so we might as well standardize it. A unified mechanism reduces error sources and complexity. It removes the need for version handling in the LSPS itself. It reduces the number of method calls from one for each LSPS to a single call.
PR Content

Adds the method lsps0.select_versions to select versions for all LSPS.
Updates lsps0.list_protocols to make it similar to lsps0.select_versions.
Adds a version number to LSPS0 itself. This adds a clear upgrade mechanism in case we need to change anything here. Think of max MTU increase, compression/TLV, or even a complete change in protocol.
Removes all versioning from the existing LSPS.

I support the idea of having a unified method of handling versions across all LSPS.
However, the lsps0.select_versions introduces some kind of connection state.
A key-feature of JSON-RPC 2.0 is statelessness and it feels wrong to throw it away on the first call.
The state introduces some extra complexity here. The client and server must store the version-state somewhere and implement hooks to forget the state on connect/disconnect.
It complicates debugging in some way. Connections on my node are usually long-lived. When debugging I don't want to have to browser through old logs to see on what version I am.
To my understanding switching versions would require nodes to fully disconnect. This might affect gossip, payment routing, etc...
I would prefer a solution in which the client asks the server what versions they support. The client could include the api_version in every call.

The state introduces some extra complexity here. The client and server must store the version-state somewhere and implement hooks to forget the state on connect/disconnect.

I assume you are looking at this from a CLN point of view to develop each LSPS as an individual plugin, correct?

To my understanding switching versions would require nodes to fully disconnect. This might affect gossip, payment routing, etc...

Good point

I argued the exact same thing on Telegram the other day.
It's unclear to me why the LSP needs to know the version before the first request comes in.

Since we are completely refactoring versioning anyway I'm wondering if we also need to discuss feature bits. I haven't looked into anything other then LSPS1. Feature bits are not needed for that one.

If both apps have a version-conflict the LSP-server can only see a single misbehaving node.

I do not understand this issue

I might have worded that poorly.
The core issue is that the LSP-client might not even run on the lightning-node itself.
Suppose I would be using 2 wallet apps and connect them to my own node.
Wallet A might implement LSPS2 v1 and the Wallet B implements LSPS2 v2.
Wallet A might have negotiated a channel with an LSP and keep the connection open.
A few days later Wallet B tries to acquire a channel with the same LSP.
The negotiation fails and Wallet B closes the connection and negotiates the usage of LSPS2 v2.
This where things get dangerous. Wallet A might falsely believe he has negotiated the version correctly and might speak LSPS2 v1 to a server that expect LSPS v2.
The tricky part here is that from a protocol view the node represents a single client.
In practice, multiple LSP-client apps might run on top of a single node.

What about:
{
  "protocols": {
    "lsps0": [
      {
        "number": 1,
        "scope": "request",
       }
     ]
    "lsps1": [
      {
        "number": 1,
        "scope": "request",
       },
      {
        "number": 2,
        "scope": "request",
       }
     ]
    "lsps2": [
      {
        "number": 2,
        "scope": "request",
       },
      {
        "number": 3,
        "scope": "session",
       }
     ]
  }
}

only when the scope is session you need a secondary call lsps0.start_session
You could potentially add a concept of a session_id where the client provides a session_id so there is the option to mix different sessions with different versions ?
In that case when scope is request then version number is always added to every request
In case of scope session you provide session_id in every request
I can be way off here since I've only been reading and implementing LSPS1 ;-)

Added ability to switch versions without closing the peer connection.
Added section about versioning switching/migration behaviour.

I'll use this comment as a draft for an alternative proposal.  I'm not fully familiar with LSPS4 yet so I might be missing some requirements or include inaccuracies. Please point them out so we can improve the proposal.
In WEB-API's it common to include a version indicator on every request. Usually, the path of an API endpoint starts with /api/v1 to indicate the version number. Once /api/v2 is released, clients can freely pick what version they use. There is no requirement that a client uses the same version consistently. I believe this pattern has been proven to be effective.
What changes in lsps0?
We implement the proposed changes lsps0.list_protocols. The method will return supported version of each protocol.
We will not implement a lsps0.select_version call
What changes in lsps1?
The client includes the version number on every request.
We will only need to modify lsps1.get_info.
What changes in lsps2 (aka lsps2 v1) and lsps4 (aka lsps2 v2)?
We will include the version number on every request.
Lsps v1 and lsps2 v2 would be two separate API's that don't interfere with each other (except for maybe some clean-up calls)?
If a client wants to upgrade from LSPS2 v1 to LSPS2 v2 they just start using LSPS2 v2.

The client can reserve an lsps2 v2 scid and start using it
All lsps2 v1 jit_channel_scid's will be treated as such.

The negotiated fee-rates will apply
The server will not send any lsps4.you_have_new_ppp-notifications
...

After some time all jit_channel_scid's will either be expired or used.

The client can forget about jit_channel_scid's if they are expired
If jit_channel_scid is used it becomes just a normal lightning channel with an alias. The client doesn't need to remember that it is a lsps2 v1 channel.

Once the client has forgotten about all LSPS2 v1 channels it has been successfully updated.
Why I like this proposal better?

lsps0 doesn't force specific semantics: We do not know yet which requirements future upgrades might have.  For other a mechanism described above might be suited better. We can leave this up to the LSPS.

No unexpected version-changes: After network outage a client might be required to call select_versions again. This might result in unexpected up- or downgrades in the middle of the night. Sometimes upgrades go bad and require attention. The operational burden of maintaining an LSP-client should be minimized. Giving clients the opportunity to plan upgrades is an improvement. Some upgrades might require user-approval such as the acceptance of new fee-rates. The current proposal wouldn't allow this.

No need to define up- or downgrade paths: A downgrade from LSPS4 (LSPS2 v2) to LSPS2 v1 looks very hard and probably requires user input. The user might want to accept the LSPS2 v2 fee-rates. This might happen unexpectedly.

Allows separate implementations for different parts of the spec : I understand having a single node that powers multiple apps with multiple signers is controversial. However, that is not the point of this comment. In core-lightning we might want to implement an lsps1-plugin and an lsps2-plugin. They can both negotiate different parts of the spec.

Allow upgrading without altering existing agreements : Each lsps represents an agreement between the client and server. Changing the version alters the semantics of the agreement and might result in new rates. In some cases the client might have negotiated a very good rate. This rate might not be available anymore because of chasing market-conditions. There is a risk that clients refuse to upgrade to keep their agreement. To my understanding this risk isn't present in the current spec. But I think it is likely that future enhancements or versions might suffer from it.

This proposal handles request/response messages, and fixes the versioning issue for us there.
I have a proposal for notifications too:
For notifications, a client always registers for a "notification session". The client does this by sending a request to the LSP: lspsx.subscribe_x, containing the version it wants to use. The LSP will respond with an object containing a session identifier. For the duration of the session, the LSP will broadcast notifications to the client, using the version the client specified in the request.
A session ends when the client requests to stop notifications for that session id, or when the peer connection is dropped. If there are multiple sessions at the same time, the LSP will broadcast notifications to all currently active sessions.
This will solve the situation where there's multiple software packages handling client-LSP related things, which may be using different versions of an LSPSx protocol.

multiple software packages handling client-LSP related things

This is the bit I would like to strongly object to.
As I understand it, the intent of greenlight is:

Ensure that the greenlight node does not have direct access to private keys, thus requiring that apps handle private keys.

As node private key is needed to even establish a connection, this implies that if no individual apps are currently running, the greenlight node MUST drop all connections as well, as it can do nothing anyway if the connections are dropped "naturally" by normal network-being-unreliable reality.  It is better to consistently say "once all apps have disconnected from the greenlight node the greenkight node disconnects all LN connections" than to say "99.9% of the time the greenlight node remains connected but in the 0.1% chance it drops accidentally we cannot make or accept new connections because mmmmmmmm internal detail about how apps hold the private key".
If the node private key (used for LN BOLT8 comms) is held by greenlight and only channel signing keys are held by apps... that kinda breaks the assumption inherent in the BOLT 8 spec that the node keypair is ultimately held by the same entity that has access to channel signing keys.  Yes, the greenlight node cannot move funds in the channels, but it can still talk on behalf of the node and do things like spam LSPs with requests that it ultimately cannot handle, which makes me suspicious of greenlight.  Yes, you might open-source the greenlight code and show that the open-source greenlight does not do that --- but that does not mean you guys run the open source version.  There is a reason why "Do not trust, verify" is a thing, and why we do not just do something like "oh is the other side running LND? okay we trust that and never verify their messages because they are running LND which is 100% open-source and we can save CPU cycles by having us human developers validate the LND code instead of having our program validate every message".

The intent is that the greenlight node liquidity is shared among apps.

LSPS protocols are all about managing liquidity of the client with the LSP. If you intend to share liquidity among apps in a greenlight node, then you should really also manage that liquidity across all apps, not have each app manage liquidity.
Having the apps handle communication with the LSP and manage the liquidity directly seems broken to me.  It is like: "okay now we run each plugin in the same memory space because we want to share memory resources among them, however each plugin needs to write its own malloc, here is the interface to sbrk, have fun".  If you want to share resources among various components, you need a component that actually manages those centrally, not expose LSPS1 directly to your apps.
As to exposing LSPS directly to apps, which do you think an app developer would prefer?

Oh you have to talk to LSP directly, here is an interface to check if the greenlight node has enough inbound liquidity, here is an interface to the LSPS endpoint, have fun.
 Here is an interface where you say how much inbound you are expecting, and the greenlight node will automatically get liquidity from somewhere magical so you only need to issue an invoice with these things we will give you but you fill in the hash+secret+metadata.

In short: architecture issue, NACK.

@JssDWt Session management on the LSP side brings a TON of complexity that I seriously want to avoid. NACK from me.
@ErikDeSmedt An easy way to make your proposal work: Add the version to the method/notification name. Example: lsps1.v1.get_info or lsps4.v1.you_have_new_ppp. This basically makes each version independent of each other. There would be no difference between having independent specs like lsps2 and lsps4 or independent versions lsps2.v1 and lsps2.v2. Versions and specs can be used independently and simultaneously.
I am still neutral on what we should do but this would be at least an easy alternative.

In short: architecture issue, NACK.

You haven't posed anything in this rant that discusses version management. The same problem occurs if there are 2 software packages running on top of a lightning node that use the node's api to communicate. It has nothing to do with key management. People run software on top of their nodes where protocols like the LSP spec are implemented. It seems logical to me that some of these packages use other versions than others.

Session management on the LSP side brings a TON of complexity that I seriously want to avoid. NACK from me.

I don't see how session management can make things more complex. You're already managing this information as an LSP if you want to do a version session per peer connection. It makes sense for a client to request a specific notification stream for a specific version upon connection.

I agree with @JssDWt.
LSP client implementations are implemented on top of the lightning node which is only used as a transport layer. Allowing it to be used by multiple lsp clients sounds to me like something we want to achieve, it is impossible to force all of them to use the same protocol version.
This proposal assumes there is only one lsp client per node which is a big limitation in the spec IMO.
Allowing registering for notifications with a registration/session id is something very simple to implement, resulting in a lot cleaner spec with unnecessary limitations.

@ZmnSCPxj-jr I don't understand your response tbh. This isn't a race condition. Greenlight is just an example on why this proposed architecture doesn't hold water. You can have the same node used multiple clients with different versions.

I don't see how session management can make things more complex. You're already managing this information as an LSP if you want to do a version session per peer connection. It makes sense for a client to request a specific notification stream for a specific version upon connection.

@JssDWt Let me know if I misunderstand you but with my lsps.version proposal, you have ALL supported versions running at the same time. Therefore you don't need any sessions or so. The LSP can send a notification whenever it wants and it's the responsibility of the node/app to process it.
Adding notification subscriptions to the LSPSpec does make the spec more complex?

@JssDWt Let me know if I misunderstand you but with my lsps.version proposal, you have ALL supported versions running at the same time. Therefore you don't need any sessions or so. The LSP can send a notification whenever it wants and it's the responsibility of the node/app to process it.

@SeverinAlexB As far as I understand @JssDWt proposed sessions only to bind a specific session to a version, so notifications can be sent to multiple clients that support different versions simultaneously.
If you mean that the LSP would send notifications for all its supported versions then I agree that there is no need for sessions as every client should filter its relevant notifications.
In fact this combined with sending the version on a request basis keeps the lsp protocol stateless without the need for reestablishing connection.
In mobile there are some issues when implementing this spec as:

If the node is running on the device,  the node frequently loose connection to its peer resulting in the need to re-establish the version negotiation almost on a request basis.
If the node is controlled by the mobile app remotely the app, when goes to foreground, never knows if the peer has been disconnected since last time the version was established which resulting again in version negotiation to ensure the version is set.

So my question is if anyway we need to negotiate the version on a request basis, why not just sending it as part of the request, saving this stateful negotiation phase.

There is no versioning negotiation in my lsps.version proposal. All versions are always running and can be used.

Sounds good. I think I missed this proposal. Do you have a link?

There is no versioning negotiation in my lsps.version proposal. All versions are always running and can be used.

Sounds good. I think I missed this proposal. Do you have a link?

It's higher in the comments.
https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/56#issuecomment-1742864915

@ErikDeSmedt An easy way to make your proposal work: Add the version to the method/notification name. Example: lsps1.v1.get_info or lsps4.v1.you_have_new_ppp. This basically makes each version independent of each other. There is no difference between having independent specs like lsps2 and lsps4 or independent versions lsps2.v1 and lsps2.v2. Versions and specs can be used independently and simultaneously.

So we would have a spec that introduces backward compatible changes by default. When changes are made to a spec, they are made backward compatible with previous implementations of the spec. If backward incompatible changes are needed, a new spec (e.g. lsps2.v2) is created. Needing only the list_protocols call, and no version negotiation, because the versions are basically embedded in the jsonrpc method.

Let me know if I misunderstand you but with my lsps.version proposal, you have ALL supported versions running at the same time. Therefore you don't need any sessions or so. The LSP can send a notification whenever it wants and it's the responsibility of the node/app to process it.

I think this indeed covers all versioning issues, and there would be no need for 'version sessions'. I understand that comment now.


Slow Loading Speed Issue

Summary:
This ticket addresses the slow loading speed issue in the app, which requires immediate attention and resolution. The purpose of this ticket is to provide a comprehensive understanding of the problem, its background, potential use cases, and the benefits/impact of resolving this issue.
Background/Reason:
The app currently experiences significant delays in loading, negatively impacting user experience and overall satisfaction. This issue has been reported by multiple customers, indicating a widespread problem that needs to be addressed urgently. The slow loading speed hampers the app's functionality and efficiency, hindering users from accessing desired features and content promptly.
Use Cases:

User Scenario: When a user opens the app, it takes an unusually long time to load the main interface, causing frustration and impeding their ability to perform desired actions.
Content Loading: Loading specific content within the app, such as images, videos, or articles, takes an excessive amount of time, leading to a poor user experience.
Navigation Delay: Moving between different sections or screens within the app is slow, resulting in a cumbersome and frustrating user journey.

Benefits/Impact:

Enhanced User Experience: Resolving the slow loading speed issue will significantly improve the overall user experience, ensuring faster and more efficient app usage.
Increased User Engagement: With improved loading speed, users will be more likely to engage with the app, explore its features, and spend more time utilizing its functionalities.
Customer Satisfaction: Addressing this issue promptly will demonstrate the app's commitment to customer satisfaction, leading to increased loyalty and positive word-of-mouth recommendations.
Improved App Performance: By optimizing loading speed, the app's performance will be enhanced, resulting in smoother navigation, quicker content access, and reduced frustration for users.
Competitive Advantage: A fast-loading app will give the company a competitive edge over similar apps in the market, attracting more users and potentially increasing revenue.

Please prioritize this ticket to ensure a swift resolution of the slow loading speed issue, as it directly impacts the app's usability and customer satisfaction.

Summarized feedback from<EMAIL_ADDRESS>:

The app has slow loading speed, which needs to be fixed.


Unable to install Cilium: timeout while waiting for status to become successful

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
I was trying to install cilium on Ubuntu20.04 / amd64 in procedure aligned with https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli.
It eventually failed with Error: Unable to install Cilium: timeout while waiting for status to become successful: context deadline exceeded message, and never be succeeded.
Cilium Version
root@edgemaster:~# cilium version
cilium-cli: v0.12.11 compiled with go1.19.3 on linux/amd64
cilium image (default): v1.12.2
cilium image (stable): v1.12.5
cilium image (running): unknown. Unable to obtain cilium version, no cilium pods found in namespace "kube-system"

Kernel Version
root@edgemaster:~# uname -a
Linux edgemaster 5.15.0-56-generic #62~20.04.1-Ubuntu SMP Tue Nov 22 21:24:20 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Kubernetes Version
root@edgemaster:~# kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.13", GitCommit:"a43c0904d0de10f92aa3956c74489c45e6453d6e", GitTreeState:"clean", BuildDate:"2022-08-17T18:28:56Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.17", GitCommit:"a7736eaf34d823d7652415337ac0ad06db9167fc", GitTreeState:"clean", BuildDate:"2022-12-08T11:42:04Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}

Sysdump
root@edgemaster:~# cilium sysdump
🔍 Collecting sysdump with cilium-cli version: v0.12.11, args: [sysdump]
failed to create sysdump collector: failed to detect Cilium namespace, could not find Cilium installation in namespaces: [kube-system cilium]

Relevant log output
root@edgemaster:~# cilium install
ℹ  Using Cilium version 1.12.2
🔮 Auto-detected cluster name: kubernetes
🔮 Auto-detected datapath mode: tunnel
🔮 Auto-detected kube-proxy has been installed
ℹ  helm template --namespace kube-system cilium cilium/cilium --version 1.12.2 --set cluster.id=0,cluster.name=kubernetes,encryption.nodeEncryption=false,kubeProxyReplacement=disabled,operator.replicas=1,serviceAccounts.cilium.name=cilium,serviceAccounts.operator.name=cilium-operator,tunnel=vxlan
ℹ  Storing helm values file in kube-system/cilium-cli-helm-values Secret
🔑 Found CA in secret cilium-ca
🔑 Generating certificates for Hubble...
🚀 Creating Service accounts...
🚀 Creating Cluster roles...
🚀 Creating ConfigMap for Cilium version 1.12.2...
🚀 Creating Agent DaemonSet...
🚀 Creating Operator Deployment...
⌛ Waiting for Cilium to be installed and ready...
    /¯¯\
 /¯¯\__/¯¯\    Cilium:         1 errors, 1 warnings
 \__/¯¯\__/    Operator:       OK
 /¯¯\__/¯¯\    Hubble:         disabled
 \__/¯¯\__/    ClusterMesh:    disabled
    \__/

Deployment        cilium-operator    Desired: 1, Ready: 1/1, Available: 1/1
DaemonSet         cilium             Desired: 1, Unavailable: 1/1
Containers:       cilium             Pending: 1
                  cilium-operator    Running: 1
Cluster Pods:     0/2 managed by Cilium
Image versions    cilium             quay.io/cilium/cilium:v1.12.2@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36: 1
                  cilium-operator    quay.io/cilium/operator-generic:v1.12.2@sha256:00508f78dae5412161fa40ee30069c2802aef20f7bdd20e91423103ba8c0df6e: 1
Errors:           cilium             cilium          1 pods of DaemonSet cilium are not ready
Warnings:         cilium             cilium-lf6zz    pod is pending
↩ Rolling back installation...

Error: Unable to install Cilium: timeout while waiting for status to become successful: context deadline exceeded

Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Without a sysdump which failed to collect any data or any Cilium logs as to what could have happened, we cannot debug this. Please attach the Cilium logs or ensure that the correct namespace is used when taking a sysdump.

@christarazi thanks for the reply.
I think namespace kube-system default and cluster working okay.
root@edgemaster:~# kubectl get pods -A
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-78fcd69978-cln92             1/1     Running   0          70s
kube-system   coredns-78fcd69978-hrx7d             1/1     Running   0          55s
kube-system   etcd-edgemaster                      1/1     Running   3          7m49s
kube-system   kube-apiserver-edgemaster            1/1     Running   1          7m49s
kube-system   kube-controller-manager-edgemaster   1/1     Running   0          7m49s
kube-system   kube-proxy-ql2xz                     1/1     Running   0          7m36s
kube-system   kube-scheduler-edgemaster            1/1     Running   1          7m49s
root@edgemaster:~# kubectl get namespace
NAME              STATUS   AGE
default           Active   8m8s
kube-node-lease   Active   8m9s
kube-public       Active   8m9s
kube-system       Active   8m9s

Cilium logs as to what could have happened

where this log file located? or any option i should add via install command?

kubectl logs <cilium-pod> ...

sorry i am not really following your procedure, since cilium install failed, we do not have cilium-pod running on the cluster?
root@edgemaster:~# kubectl get pods -A
NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE
kube-system   coredns-78fcd69978-cln92             1/1     Running   0          24h
kube-system   coredns-78fcd69978-hrx7d             1/1     Running   0          24h
kube-system   etcd-edgemaster                      1/1     Running   3          24h
kube-system   kube-apiserver-edgemaster            1/1     Running   1          24h
kube-system   kube-controller-manager-edgemaster   1/1     Running   0          24h
kube-system   kube-proxy-ql2xz                     1/1     Running   0          24h
kube-system   kube-scheduler-edgemaster            1/1     Running   1          24h

that is why i was asking where the cilium installation log locates... i might be mistaken

Can you run the installation with --rollback=false?

okay, thanks i will try that out right away!

since cilium pod is not running, kubectl logs does not work. I used docker logs instead on that host, that just says cp: failed to access '/hostbin/cilium-mount': Permission denied.
root@edgemaster:~# kubectl get pods -A
NAMESPACE     NAME                                 READY   STATUS                  RESTARTS      AGE
kube-system   cilium-operator-7ff4c7474-68sqb      1/1     Running                 0             16m
kube-system   cilium-xbq2k                         0/1     Init:CrashLoopBackOff   8 (40s ago)   16m

root@edgemaster:~# kubectl logs cilium-xbq2k  -n kube-system
Error from server (BadRequest): container "cilium-agent" in pod "cilium-xbq2k" is waiting to start: PodInitializing

root@edgemaster:~# docker ps -a | grep cilium
f24747f28df7   743cf6b60787           "sh -ec 'cp /usr/bin…"   58 seconds ago   Exited (1) 57 seconds ago                     k8s_mount-cgroup_cilium-xbq2k_kube-system_eea799dc-2519-409a-b7ad-bac9bf242811_9
6d8c9ee442c7   1f3c9d687645           "cilium-operator-gen…"   22 minutes ago   Up 22 minutes                                 k8s_cilium-operator_cilium-operator-7ff4c7474-68sqb_kube-system_f7d9db5f-9005-4653-978b-0f09d05352e9_0
fbb106ac3064   k8s.gcr.io/pause:3.5   "/pause"                 22 minutes ago   Up 22 minutes                                 k8s_POD_cilium-operator-7ff4c7474-68sqb_kube-system_f7d9db5f-9005-4653-978b-0f09d05352e9_0
64af80fbe5d3   k8s.gcr.io/pause:3.5   "/pause"                 22 minutes ago   Up 22 minutes                                 k8s_POD_cilium-xbq2k_kube-system_eea799dc-2519-409a-b7ad-bac9bf242811_0

root@edgemaster:~# docker logs f24747f28df7
cp: failed to access '/hostbin/cilium-mount': Permission denied

Did you try running kubectl logs <cilium-pod>  -n kube-system --previous?

actually not, but here is the output.
root@edgemaster:~# kubectl logs -n kube-system cilium-xbq2k --previous
Error from server (BadRequest): previous terminated container "cilium-agent" in pod "cilium-xbq2k" not found

Can you do kubectl describe <cilium-pod>...?

root@edgemaster:~# kubectl describe cilium-xbq2k -n kube-system
error: the server doesn't have a resource type "cilium-xbq2k"

since pod has not been initialized, it fails also.

kubectl describe pod <cilium-pod>

Ah, sorry i missed it, my bad.
Name:                 cilium-xbq2k
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Node:                 edgemaster/<IP_ADDRESS>
Start Time:           Fri, 06 Jan 2023 14:17:02 -0800
Labels:               controller-revision-hash=fd8495fc9
                      k8s-app=cilium
                      pod-template-generation=1
Annotations:          container.apparmor.security.beta.kubernetes.io/apply-sysctl-overwrites: unconfined
                      container.apparmor.security.beta.kubernetes.io/cilium-agent: unconfined
                      container.apparmor.security.beta.kubernetes.io/clean-cilium-state: unconfined
                      container.apparmor.security.beta.kubernetes.io/mount-cgroup: unconfined
Status:               Pending
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  DaemonSet/cilium
Init Containers:
  mount-cgroup:
    Container ID:  docker://ffd454b1c841cd61f8b7b1c1e5d2bde174707e310e9012df5cef07f00d09f4a2
    Image:         quay.io/cilium/cilium:v1.12.2@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36
    Image ID:      docker-pullable://quay.io/cilium/cilium@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -ec
      cp /usr/bin/cilium-mount /hostbin/cilium-mount;
      nsenter --cgroup=/hostproc/1/ns/cgroup --mount=/hostproc/1/ns/mnt "${BIN_PATH}/cilium-mount" $CGROUP_ROOT;
      rm /hostbin/cilium-mount

    State:       Waiting
      Reason:    CrashLoopBackOff
    Last State:  Terminated
      Reason:    Error
      Message:   cp: failed to access '/hostbin/cilium-mount': Permission denied

      Exit Code:    1
      Started:      Sat, 07 Jan 2023 15:34:56 -0800
      Finished:     Sat, 07 Jan 2023 15:34:56 -0800
    Ready:          False
    Restart Count:  301
    Environment:
      CGROUP_ROOT:  /run/cilium/cgroupv2
      BIN_PATH:     /opt/cni/bin
    Mounts:
      /hostbin from cni-path (rw)
      /hostproc from hostproc (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sdhfd (ro)
  apply-sysctl-overwrites:
    Container ID:
    Image:         quay.io/cilium/cilium:v1.12.2@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36
    Image ID:
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -ec
      cp /usr/bin/cilium-sysctlfix /hostbin/cilium-sysctlfix;
      nsenter --mount=/hostproc/1/ns/mnt "${BIN_PATH}/cilium-sysctlfix";
      rm /hostbin/cilium-sysctlfix

    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Environment:
      BIN_PATH:  /opt/cni/bin
    Mounts:
      /hostbin from cni-path (rw)
      /hostproc from hostproc (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sdhfd (ro)
  mount-bpf-fs:
    Container ID:
    Image:         quay.io/cilium/cilium:v1.12.2@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36
    Image ID:
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/bash
      -c
      --
    Args:
      mount | grep "/sys/fs/bpf type bpf" || mount -t bpf bpf /sys/fs/bpf
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /sys/fs/bpf from bpf-maps (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sdhfd (ro)
  clean-cilium-state:
    Container ID:
    Image:         quay.io/cilium/cilium:v1.12.2@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36
    Image ID:
    Port:          <none>
    Host Port:     <none>
    Command:
      /init-container.sh
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:     100m
      memory:  100Mi
    Environment:
      CILIUM_ALL_STATE:  <set to the key 'clean-cilium-state' of config map 'cilium-config'>      Optional: true
      CILIUM_BPF_STATE:  <set to the key 'clean-cilium-bpf-state' of config map 'cilium-config'>  Optional: true
    Mounts:
      /run/cilium/cgroupv2 from cilium-cgroup (rw)
      /sys/fs/bpf from bpf-maps (rw)
      /var/run/cilium from cilium-run (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sdhfd (ro)
Containers:
  cilium-agent:
    Container ID:
    Image:         quay.io/cilium/cilium:v1.12.2@sha256:986f8b04cfdb35cf714701e58e35da0ee63da2b8a048ab596ccb49de58d5ba36
    Image ID:
    Port:          <none>
    Host Port:     <none>
    Command:
      cilium-agent
    Args:
      --config-dir=/tmp/cilium/config-map
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Liveness:       http-get http://<IP_ADDRESS>:9879/healthz delay=0s timeout=5s period=30s #success=1 #failure=10
    Readiness:      http-get http://<IP_ADDRESS>:9879/healthz delay=0s timeout=5s period=30s #success=1 #failure=3
    Startup:        http-get http://<IP_ADDRESS>:9879/healthz delay=0s timeout=1s period=2s #success=1 #failure=105
    Environment:
      K8S_NODE_NAME:               (v1:spec.nodeName)
      CILIUM_K8S_NAMESPACE:       kube-system (v1:metadata.namespace)
      CILIUM_CLUSTERMESH_CONFIG:  /var/lib/cilium/clustermesh/
      CILIUM_CNI_CHAINING_MODE:   <set to the key 'cni-chaining-mode' of config map 'cilium-config'>  Optional: true
      CILIUM_CUSTOM_CNI_CONF:     <set to the key 'custom-cni-conf' of config map 'cilium-config'>    Optional: true
    Mounts:
      /host/etc/cni/net.d from etc-cni-netd (rw)
      /host/opt/cni/bin from cni-path (rw)
      /host/proc/sys/kernel from host-proc-sys-kernel (rw)
      /host/proc/sys/net from host-proc-sys-net (rw)
      /lib/modules from lib-modules (ro)
      /run/xtables.lock from xtables-lock (rw)
      /sys/fs/bpf from bpf-maps (rw)
      /tmp/cilium/config-map from cilium-config-path (ro)
      /var/lib/cilium/clustermesh from clustermesh-secrets (ro)
      /var/lib/cilium/tls/hubble from hubble-tls (ro)
      /var/run/cilium from cilium-run (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-sdhfd (ro)
Conditions:
  Type              Status
  Initialized       False
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  cilium-run:
    Type:          HostPath (bare host directory volume)
    Path:          /var/run/cilium
    HostPathType:  DirectoryOrCreate
  bpf-maps:
    Type:          HostPath (bare host directory volume)
    Path:          /sys/fs/bpf
    HostPathType:  DirectoryOrCreate
  hostproc:
    Type:          HostPath (bare host directory volume)
    Path:          /proc
    HostPathType:  Directory
  cilium-cgroup:
    Type:          HostPath (bare host directory volume)
    Path:          /run/cilium/cgroupv2
    HostPathType:  DirectoryOrCreate
  cni-path:
    Type:          HostPath (bare host directory volume)
    Path:          /opt/cni/bin
    HostPathType:  DirectoryOrCreate
  etc-cni-netd:
    Type:          HostPath (bare host directory volume)
    Path:          /etc/cni/net.d
    HostPathType:  DirectoryOrCreate
  lib-modules:
    Type:          HostPath (bare host directory volume)
    Path:          /lib/modules
    HostPathType:
  xtables-lock:
    Type:          HostPath (bare host directory volume)
    Path:          /run/xtables.lock
    HostPathType:  FileOrCreate
  clustermesh-secrets:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  cilium-clustermesh
    Optional:    true
  cilium-config-path:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      cilium-config
    Optional:  false
  host-proc-sys-net:
    Type:          HostPath (bare host directory volume)
    Path:          /proc/sys/net
    HostPathType:  Directory
  host-proc-sys-kernel:
    Type:          HostPath (bare host directory volume)
    Path:          /proc/sys/kernel
    HostPathType:  Directory
  hubble-tls:
    Type:                Projected (a volume that contains injected data from multiple sources)
    SecretName:          hubble-server-certs
    SecretOptionalName:  0xc000c1d43a
  kube-api-access-sdhfd:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              kubernetes.io/os=linux
Tolerations:                 op=Exists
                             node.kubernetes.io/disk-pressure:NoSchedule op=Exists
                             node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/network-unavailable:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists
                             node.kubernetes.io/pid-pressure:NoSchedule op=Exists
                             node.kubernetes.io/unreachable:NoExecute op=Exists
                             node.kubernetes.io/unschedulable:NoSchedule op=Exists
Events:
  Type     Reason            Age                   From     Message
  ----     ------            ----                  ----     -------
  Warning  DNSConfigForming  77s (x7319 over 25h)  kubelet  Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: <IP_ADDRESS> <IP_ADDRESS> 2607:fd28:0:403::11

Was that run when the Cilium pod was stuck? I would expect to see some event msgs about that in the bottom section called Events.

no it does not get stuck, and the above is the all log information that i can get via kubectl describe pods -n kube-system.

anything i can do on my side?

Without understanding what the underlying error msg for why Cilium pod is stuck pending, it's very difficult to debug and propose a solution. If you can find this information out, that would be very helpful.

root@edgemaster:~# docker logs f24747f28df7
cp: failed to access '/hostbin/cilium-mount': Permission denied

it seems that entrypoint command cp /usr/bin/cilium-mount /hostbin/cilium-mount failed because /hostbin/cilium-mount permission.
so that creating container runtime based on exited container with above error.
edgemaster@edgemaster:~$ docker run -it --entrypoint /bin/bash debugimage
root@fda4b48b5e1e:/home/cilium#
root@fda4b48b5e1e:/home/cilium# ls -lt / | grep host
drwxr-xr-x   2 root root    4096 Jan 13 22:22 hostbin
drwxr-xr-x   2 root root    4096 Jan 13 22:22 hostproc
root@fda4b48b5e1e:/home/cilium# ls -lt /usr/bin/ | grep cilium-mount
-rwxr-xr-x 1 root root    3424256 Sep 14 14:46 cilium-mount

based on the file access permission above, there should be no problem to copy that.
actually that works this debug container runtime.
root@fda4b48b5e1e:/home/cilium# cp /usr/bin/cilium-mount /hostbin/cilium-mount
root@fda4b48b5e1e:/home/cilium# ls -lt /hostbin/cilium-mount
-rwxr-xr-x 1 root root 3424256 Jan 13 22:29 /hostbin/cilium-mount

edgemaster@edgemaster:~$ ls /opt/cni/ -la
total 12
drwxr-xr-x 3 root root 4096 Aug 30 16:32 .
drwxr-xr-x 6 root root 4096 Sep 15 09:42 ..
drw------- 2 root root 4096 Jan 18 19:26 bin

/opt/cni/bin directory access permission should be drwxr-xr-x, changing it into so can resolve this issue.
I am not sure what went wrong to change the permission something like that, but so far no further problems during installation. So i will go ahead to close this one.

Glad you found the solution.


Improve/finish Windows support

While the driver can be used on Windows, there are a few rough edges which we need to address before we can state Windows is fully supported.
This issue will track all outstanding tasks and identified problems with the packages on Windows.
Todo:

[ ] #3: add Windows CI
[ ] #4: add build documentation for Windows (related: #17)
[ ] #17: abb_egm_hardware_interface build failing due to robot_hw.h collisions with windows.h (work-around in https://github.com/ros-industrial/abb_robot_driver/issues/17#issuecomment-791529156)
[ ] #20: multi-line rosservice invocations not working in cmd.exe (work-around/alternative: https://github.com/ros-industrial/abb_robot_driver/issues/20#issuecomment-796817916)

@gavanderhoorn I'm sorry, I do not have any status. Our priority queue grows significantly faster than we can whittle it down. If you can share data about the customer impact on this, it might help make the case to increase the priority in our backlog.

@ooeygui @lilustga were you able to improve anything in the end?

@gavanderhoorn Thanks for the ping. We are not currently working on this due to resource constraints.

Ok. Thanks for the update.


Ideal directory structure?

Wondering what the best way to structure a mercury application?
How about:
stores - serialization
states - schema
events - actions
views - rendering

I tend to create individual components that have a function which returns state and a function for rendering (SEE https://github.com/Raynos/mercury/tree/master/examples/login-form). I have been structuring code similar to this:
components/
  header/
    index.js
    render.js
  footer/
    index.js
    render.js
  etc.
event-handlers/
  special-value-event.js
widgets/
  custom-widget.js
index.js

I have a strong personalized opinion here, so I thought I would give my two cents.
index/
layout/
body/
column-body/
left-column.js
right-column.js
row-body/
top-row.js
bottom-row.js
body-reusable-only-thing.js
sub-header.js
column-body.js
row-body.js
sub-footer.js
header.js
body.js
footer.js
layout.js
index.js
reusable-everywhere-majig.js
reusable-anywhere-thingy.js
I was working on a ReactJS project recently and was using react-router. I found that using the same nesting principle for my directory structure resulted in universally understandable structure. I haven't done so in Mercury yet, but imagine no difference in the application of the principle.

Keeping rendering functions in separate files helps when you're doing hot reloading (as in #180). I like @jxson's structure.


javascript stack traces are hard to read

there is a bunch of internal info that the user should not see.
and for the stack frames that are from their code, it shows evaluator/javaScript.js line/column in addition to the user's code line/column.

https://github.com/twosigma/beaker-notebook/pull/1762


[hotfix][flink-runtime-web] Typing improvements for Flink UI

What is the purpose of the change
This is a few commits which aim to slowly improve the code quality in Flink UI by improving type safety and various smaller fixes.
This PR also adds angular-testing-library which will make writing tests in the future easier.
Brief change log
See individual commits.
Verifying this change
Flink UI doesn't yet have tests. I added a couple here due to the addition of angular-testing-library, but we need to add more tests, of course.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): yes
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

@nicoweidner Thanks for the review, I addressed all your feedback, I believe. Note that I'm fully aware that this PR doesn't make things perfect – it'll take several iterations. Right now I focused on changes that do not cause behavioral changes but can be applied across the entire application. We'll of course have to go over things in more detail in later steps and sort more things out, then ideally by adding tests as well.

Thanks for the contribution. I cannot access the content but looking at the size, it's safe to assume that we are not talking about a hotfix. Please create a Jira ticket and use that instead of hotfix. The ticket will be then a point where future developers can refer to. (Imagine you are introducing a bug, it would be much easier to reference that in Jira as caused by)

@AHeise Would it be OK to create an issue and put multiple PRs on it? It'll be rather weird to create random open-ended issues that are basically all the same, so I'm wondering what the best approach for that would be. If you prefer individual issues I'm happy to do that too, though.

It's in general okay to have multiple PRs for one issue.
However, at this size, I'd rather use an umbrella ticket and have smaller tasks on it like ("Improve typing in Web UI", "Reduce code clutter in X", "Increase test coverage of B") each having their own ticket.

@AHeise Fair enough, thanks. I've created an umbrella and made this PR a sub-task thereof (https://issues.apache.org/jira/browse/FLINK-24928). I'm not sure if the JIRA will link up the PR with the issue after the fact now, though.

@AHeise And the CI has passed again now, too. :-)

@AHeise Please merge :)

My pleasure. Thanks!


fix | Security issue fix 2405

Description
Fixed

Security issue fixed.
Dependabot bump version fixes for 24/05

Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[x] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[x] Copyright and license header are present on all affected files

I've ran the dash tool, you can see the issues here:
[INFO] This content is either not correctly mapped by the system, or requires review. [INFO] A review is required for maven/mavencentral/org.apache.commons/commons-csv/1.11.0. [INFO] A review request was created https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/14690 .


Proposal: query path tenancy

Yet another proposal for including multi-tenancy support in the query path. In the same base as outlined previously by #4055 (with implementation available at #4141).

@bwplotka @fpetkovski @saswatamcode: I believe I have handled and/or replied to all of your comments. Please do check the replies and the proposal in its current state when you have some time, we (me and the proposal) ready for a next round of feedback. :)
Thanks for your reviews 🙇

Could reviewers please give this a second look? Thank you for your time.


How to keep background transparent if I use apply_vibrancy

As you see, I only need the radius for window,
how to keep background transparent if I use apply_vibrancy

  #[cfg(target_os = "macos")]
  apply_vibrancy(&window, NSVisualEffectMaterial::HudWindow, None, Some(16.0))
      .expect("Unsupported platform! 'apply_vibrancy' is only supported on macOS");

I found another way to implement this , thanks!

how did you do it ?

For those reading this issue
 #[cfg(target_os = "macos")]
      apply_vibrancy(&window, NSVisualEffectMaterial::HudWindow, Some(NSVisualEffectState::Active), Some(16.0))
        .expect("Unsupported platform! 'apply_vibrancy' is only supported on macOS");


Custom datatypes in yaml files

Hi @amirfru ,
I'm trying to use custom datatypes with this package. In particular I'm trying to use enum and export to yaml file as string. It works but nor in a list
For example
class MyEnum(str,Enum):
    OPT1 = "OPT1"
    OPT2 = "OPT2"

# add representer to avoid type junk in the yaml
yaml.add_multi_representer(MyEnum, lambda dumper, data: dumper.represent_str(data.name))

@params
class MyParams:
    options: MyEnum = MyEnum.OPT1
    other_field:str = "other"

x = MyParams(options= MyEnum.OPT2)

x._to_yaml("my_yaml.yaml") # is this the right way? to use internal function?

y = MyParams()
y._from_yaml("my_yaml.yaml")

Will work fine with the expected yaml file:
options: OPT2
other_field: other

But when I add a list to the game:
@params
class MyParams2:
    options: list[MyEnum] = [MyEnum.OPT1]
    other_field:str = "other"

x = MyParams2(options= [MyEnum.OPT2])

x._to_yaml("my_yaml.yaml") # is this the right way? to use internal function?

y = MyParams2()
y._from_yaml("my_yaml.yaml")

I get the following error:
TypeError                                 Traceback (most recent call last)
Cell In[7], line 11
      8 x._to_yaml("my_yaml.yaml") # is this the right way? to use internal function?
     10 y = MyParams2()
---> 11 y._from_yaml("my_yaml.yaml")

File /miniconda/envs/pytorch/lib/python3.10/site-packages/eparams/main.py:182, in _from_yaml(obj, path_or_buf, Loader, strict)
    180     with open(path_or_buf, 'r') as f:
    181         dct = yaml.load(f, Loader=Loader)
--> 182 _from_dict(obj, dct, strict=strict)

File /miniconda/envs/pytorch/lib/python3.10/site-packages/eparams/main.py:161, in _from_dict(obj, dct, strict)
    159         _from_dict(cur_val, val, strict=strict)
    160         continue
--> 161 _try_set_attr(obj, key, val, strict=strict)

File /miniconda/envs/pytorch/lib/python3.10/site-packages/eparams/main.py:141, in _try_set_attr(obj, name, value, strict)
    139 except Exception as E:
    140     if strict:
--> 141         raise E
    142     else:
    143         print(E)

File /miniconda/envs/pytorch/lib/python3.10/site-packages/eparams/main.py:138, in _try_set_attr(obj, name, value, strict)
...
    788 elif isinstance(expected_type, TypeVar):
    789     # Only happens on < 3.6
    790     check_typevar(argname, value, expected_type, memo)

TypeError: type of options[0] must be __main__.MyEnum; got str instead

The yaml file btw looks fine (the problem is with reading):
options:
- OPT2
other_field: other

Hi @sfaroy , thanks for opening this issue!
Good news!
I've now updated eparams so it would recursively iterate through list tuple and dict types and try to cast the inputs into the desired types if possible :)  it's in version 0.2 so you might need to pip install --upgrade eparams and it should solve this issue

Also, for future reference - you can always define a custom preprocess_fn in case something like this happens; this function is the one that tries to cast the values into the correct type
in your case, a quick hack would look like:
from enum import Enum

import yaml

from eparams import params, Var

class MyEnum(str,Enum):
    OPT1 = "OPT1"
    OPT2 = "OPT2"

# add representer to avoid type junk in the yaml
yaml.add_multi_representer(MyEnum, lambda dumper, data: dumper.represent_str(data.name))

@params
class MyParams2:
    options: list[MyEnum] = Var([MyEnum.OPT1], preprocess_fn=lambda val: [MyEnum(x) for x in val])
    other_field:str = "other"

x = MyParams2(options= [MyEnum.OPT2])

x._to_yaml("my_yaml.yaml") # is this the right way? to use internal function? <<< YES

y = MyParams2()
y._from_yaml("my_yaml.yaml")


NPM Audit: Prototype Pollution in lodash

Environment

Operating System: Darwin
Node Version:     v20.10.0
Nuxt Version:     3.9.3
CLI Version:      3.10.0
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      ssr, devtools, modules, googleFonts
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
npm audit report
Describe the bug
Nuxt v3.9.3 has a dependency on lodash.pick >= 4.0.0 that has a high severity Prototype Pollution vulnerability.
# npm audit report

lodash.pick  >=4.0.0
Severity: high
Prototype Pollution in lodash - https://github.com/advisories/GHSA-p6mc-m468-83gw
fix available via `npm audit fix --force`
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/lodash.pick
  vite-plugin-checker  >=0.2.0-beta.0
  Depends on vulnerable versions of lodash.pick
  node_modules/vite-plugin-checker
    @nuxt/vite-builder  >=3.0.0-rc.0
    Depends on vulnerable versions of vite
    Depends on vulnerable versions of vite-plugin-checker
    node_modules/@nuxt/vite-builder
      nuxt  >=3.9.0
      Depends on vulnerable versions of @nuxt/devtools
      Depends on vulnerable versions of @nuxt/vite-builder
      node_modules/nuxt
        @nuxt/devtools  >=1.0.7
        Depends on vulnerable versions of @nuxt/devtools-kit
        Depends on vulnerable versions of nuxt
        node_modules/@nuxt/devtools
        @nuxt/devtools-kit  >=1.0.7
        Depends on vulnerable versions of nuxt
        node_modules/@nuxt/devtools-kit

Additional context
No response
Logs
No response

I am also having the same problem and haven't been able to figure it out yet.

This doesn't seem to be an issue. User input is not exposed to lodash.pick as it is only run in development mode by vite-plugin-checker.

Same here as well - linked comment/log: https://github.com/nuxt/nuxt/issues/25458#issuecomment-1914107710
-```
lodash.pick  >=4.0.0

Severity: high
Prototype Pollution in lodash - https://github.com/advisories/GHSA-p6mc-m468-83gw
fix available via npm audit fix --force
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/lodash.pick

vite-plugin-checker  >=0.2.0-beta.0

Depends on vulnerable versions of lodash.pick

node_modules/vite-plugin-checker

    @nuxt/vite-builder  >=3.0.0-rc.0

    Depends on vulnerable versions of vite

    Depends on vulnerable versions of vite-plugin-checker

    node_modules/@nuxt/vite-builder

        nuxt  >=3.9.0

        Depends on vulnerable versions of @nuxt/devtools

        Depends on vulnerable versions of @nuxt/vite-builder

        node_modules/nuxt

            @nuxt/devtools  >=1.0.7

            Depends on vulnerable versions of @nuxt/devtools-kit

            Depends on vulnerable versions of nuxt

            node_modules/@nuxt/devtools

                @nuxt/devtools-kit  >=1.0.7

                Depends on vulnerable versions of nuxt

                node_modules/@nuxt/devtools-kit

vite  5.0.0 - 5.0.11
Severity: high
Vite dev server option server.fs.deny can be bypassed when hosted on case-insensitive filesystem - https://github.com/advisories/GHSA-c24v-8rfc-w8vw
fix available via "npm audit fix --force"
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/@nuxt/vite-builder/node_modules/vite

@rolandtannous correct.

if you use npm create vue@latest create a vue project, You will get a vue project powered by vite, but without any of the vite-related security vulnerabilities. All reason to suspect that the nuxt team is just lazy or unwilling to make changes.


Update README.md with link to Visual C++ 2015 Redistr

Make sure that people will install Visual C++ 2015 Redistributable libraries before everything.
Btw, doesnt this dependency kill all the "portable" thing?

@OlegGavrilov I'm looking into it, VC2015 doesn't look very portable, as there's no solid redistributable dlls I can find, I have made the decision to revert back to VC2013 for the time being since the dlls are easily found.


Fix for handcuff exception

Fixes #1922

Uhhhh I think you've left this showing 24/7... probably need a blank state or visible: false

Uhhhh I think you've left this showing 24/7... probably need a blank state or visible: false

The player appearance component disables the cuff overlay when you spawn since it does a check if you're handcuffed when updating the player overlays, i believe it's done in Setup(). You're right though, we could probably make it false in the prototype.


update quasar testnet

In this PR, I have updated the chain-id , and latest node version tag. And removed the not working rpc/rest end point.

Testnet Chain Id - quasar-test-1 ( curl -s https://quasar-testnet-rpc.polkachu.com/status | jq '.result.node_info.network' )
Active RPC/REST - https://quasar-testnet-rpc.polkachu.com and https://quasar-testnet-rest.polkachu.com , https://quasar-testnet-api.polkachu.com/
Updated node tag - https://github.com/quasar-finance/quasar/releases/tag/v1.0.1-rc-testnet

@JeremyParish69 could you please review and merge.  Let me know if there is any question on this PR? I need to merge this update soon due to having some chain-registry dependency on quasar side.

NOTE - Below .jsons validatation works well in my local machine.
jsonschema -i testnets/quasartestnet/chain.json ./chain.schema.json
jsonschema -i testnets/quasartestnet/assetlist.json ./assetlist.schema.json


Add video and add section about watch mode

I gave a talk on PostGraphQL at GraphQL Summit which I am pretty proud of, so we should probably add that to the readme.
Also, PostGraphQL has a pretty advanced watch mode that provides the best GraphQL API development experience in the entire GraphQL ecosystem. We should probably mention that 😉

To see how the changes rendered, check out: https://github.com/postgraphql/postgraphql/tree/update-readme


policy: Add config for enabling Cilium Clusterwide Network Policy

Related to modularizing network policies: #33360
Signed-off-by: Dorde Lapcevic<EMAIL_ADDRESS>

Adding folks with context, who reviewed the previous PR for adding config for CNP. https://github.com/cilium/cilium/pull/35049
cc @doniacld @sypakine @ovidiutirla @joamaki

/test

/test


cudnn5 load path in osX El Capitan

I copied the three libcudnn libs provided by nvidia in /usr/local/cuda/lib/ where the rest of the cuda libraries are symlinked. I did this because simply exporting the current path to DYLD_LIBRARY_PATH might not work anymore as suggested in #111 .
So currently both LD_LIBRARY_PATH and DYLD_LIBRARY_PATH are: /Users/florin/torch/install/lib:/usr/local/cuda/lib: However require cudnn still throws libcudnn (R5) not found in library path. cutorch and cunn seem to be working fine.
I also checked the file permissions are the same as for the symlinks.
Any suggestions?
edit: moving them to /usr/local/lib as suggested by @kcarnold works indeed. However I don't understand why the libs are not reachable from /usr/local/cuda/lib, where the rest of the cuda libs are..

The method of renaming the three cuDNN v5 files and moving them into /usr/local/lib/ worked for me on OS X 10.9. I also copied the cudnn.h header file to /usr/local/cuda/include/ for good measure.

This is unrelated to this specific issue but will hopefully be helpful for somebody in the future...
I was trying to run Facebook's new open source DeepMask and SharpMask under Torch on OSX 10.11 with cudnn 5, and running
th computeProposals.lua $DEEPMASK/pretrained/deepmask
gave me
/Users/Imperssonator/torch/install/bin/luajit: ...Imperssonator/torch/install/share/lua/5.1/trepl/init.lua:384: ...Imperssonator/torch/install/share/lua/5.1/trepl/init.lua:384: .../Imperssonator/torch/install/share/lua/5.1/cudnn/ffi.lua:1597: 'libcudnn (R5) not found in library path. Please install CuDNN from https://developer.nvidia.com/cuDNN Then make sure files named as libcudnn.so.5 or libcudnn.5.dylib are placed in your library load path (for example /usr/local/lib , or manually add a path to LD_LIBRARY_PATH)
I moved libcudnn.dylib, libcudnn.5.dylib, and libcudnn_static.a to usr/local/lib/ and that worked for me, so thanks.

I am working with different project from Facebook, and the way presented by @Imperssonator works perfectly. Maybe they shared common configurations.

an alternative is to do:
export CUDNN_PATH=[path to your so files]
th [your script]

Hi,
How can you got the SO files?
I downloaded CuDNN for Mac OS (version 5.1 for CUDA 8.0 today) and get only three files:
libcudnn.5.dylib*  libcudnn.dylib@    libcudnn_static.a

Of course, there is another file cudnn.h but that's all.

for OSX it is dylib, Linux it is so.


Create a FAQ

Is powerlineOS stable?

No. For a stable Chromium OS experience, use CloudReady.

Are upgrades supported?

No. In the future, upgrades may be supported.

What features does powerlineOS offer over Chromium OS?

The latest LTS Linux kernel (currently 5.15).
TBD.

This project is no longer maintained so i recommend archiving the repository


Run docker -v to find whether Jaeger integration test can be performed.

Fixes #1066.
Though this executes another process, this is hopefully more reliable and faster than scanning the PATH for a docker executable, and therefore fixes AppVeyor's CI builds.

Codecov Report

Merging #1077 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1077      +/-   ##
============================================
- Coverage     81.77%   81.75%   -0.02%
  Complexity     1175     1175
============================================
  Files           184      184
  Lines          5508     5508
  Branches        510      510
============================================
- Hits           4504     4503       -1
  Misses          869      869
- Partials        135      136       +1

Impacted Files
Coverage Δ
Complexity Δ

...census/implcore/trace/export/SpanExporterImpl.java
96.77% <0%> (-1.62%)
7% <0%> (ø)

Continue to review full report at Codecov.

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