I'm a noob to waf. I need to configure, build & install samba-4.1.4 on my RHL 6.5 system.
Trying to understand waf options specifically I've noted a lot of "with-xxxxx" options, and a few
"without-xxxxx" options. My question is: can I specify "without-xxxxx" if I don't want a particular samba feature built? e.g. there's a default "with-ldap", can I specify "without-ldap" ??
The supplied documentation does not specify exactly how to negate a default option.
I hope I've made myself clear
Thanks
Guy
Yes, thanks I went ahead and used the without-xxxx and ran the waf config process and it ran w/o error
Related
I am upgrading from version 6 to version 7, which means switching from from instantiating a Broker to using the SystemLauncher.
In particular, I had specified the keystore with a variable, and am now providing that via the systemConfigAttributes to start. But it reports that it can't find they keystore, and names my ${variable} as the keystore, rather than the value I provided.
I've also tried using one of the standard variables ${qpid.amqp_port} instead, just in case, and it's still reporting that variable name rather than a value.
Is this a feature that doesn't work any more, or am I plugging it in wrong?
The feature is still used in the broker configuration, and so you should be able to use it. Can you share your code / config so we can see what the problem might be?
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
We've been using Gitlab CI for some months, and in the last 1 week, we've been using the specific runner installed on a VPS. Currently, we are using "shell" as the executor.
Today our pipeline got stuck out of sudden, when we looked into the server free RAM, it's only 48MB out of 996 MB, FYI, we're using CentOS 6.
We've been struggling to get the answers, but we're stuck at the moment, and would like to know :
What's causing the pipeline from getting stuck?
is it true because of low free RAM?
Should we use another executor, perhaps SSH or even docker?
What is the best practices to deal with this kind of problem?
We would appreciate any kind of help or directions.
In my case the pipeline was stuck because the only available runner had the option "Can run untagged jobs" set to "No" and the job was really untagged. One can fix this issue by changing the "Can run untagged jobs" option or by adding a tag to the appropriate section of the ".gitlab-ci.yml" file in the repository. In my case it was section default:tags:.
(It seems that your case is much more complicated. However I've came across this issue twice a month, and I've forgotten the decision at the second time. Thus I've came to this page which looks appropriate to save the decision. Hope the answer will help someone else.)
In my case, the pipeline was stuck because of two things:
The tags specified in the .gitlab-ci.yml do not match those in the runner configuration.
If you specify the simulator in the build command, ensure that you write the right version of the simulator.
Once I did these changes, everything worked well!
Good luck.
In my case, It happened on a container that was off for a couple of days for maintenance reasons, I had to clear runner caches, and it worked!
In my case the windows gitlab-runner service was not running. Starting it solved it.
So i have had no luck piecing together the documentation on how to do this as it seems a bit scattered.
So i have a dedicated box running TCadmin. I have a cs go server deployed through it however now i have reached the stage of needing to add my GSLT.
I have looked through all the documentation and i have kind of got to the point of realising that i need to edit the default template of configuration that is used so that i can add a autoexec.cfg and allow that to be edited through the config editor. The other way would be to edit the default command line to allow +sv_setsteamaccount
I am totally stuck as to do either of these things though.
Any advice appreciated.
Contrary to nearly every other source on the internet, i CAN declare the login token in the server.cfg
The problem i was facing with the templating turned out to be simply a misunderstanding of the fact that the linux template was set up as a kind of "child" of the windows version as all the configs are the same. I had to amend the windows setup.
Yesterday I tried updating from MATE 1.4 to MATE 1.6. I didn't like some things about it, and I decided to switch back, at least for now. One of the changes was a switch from the mateconf configuration system to GNOME 3's GSettings. As I understand this is a frontend to a system called dconf (or connected some other way).
This rendered many of my settings viod. I figured I could try to migrate them, but unlike gconf and mateconf, which created convenient folders in my home directory and filled them with XML I could edit or copy, I wasn't able to find any trace of dconf's settings storage.
A new Control Center is provided (and mandatory to install) but I don't want to be clicking through dozens of dialogs just to restore settings I already have. The Configuration Editor utility might be okay, but it only works with mateconf.
So what I want to know is where I can find the files created by dconf and how I can modify them directly, without relying on special tools.
I almost forgot that I asked this, until abo-abo commented on it. I now see that this is a SuperUser question, but for some reason I can't flag it. I would if I was able to.
The best solution I found was to install dconf-tools, which is like the old conf-editors.
As for the actual location of the data on disk, it seems to be stored in /var/etc/dconf as Gzipped text files, but I'm not entirely sure because I'm not using Mate 1.6 right now. I wouldn't advise editing them directly.
I've been having another issue with dconf, and I checked the folder that I mentioned above. It doesn't even exist. There now seems to be a single configuration file at ~/.config/dconf/[USERNAME]. It isn't in text format, so special tools are required to edit it.
This might be the result to an update to dconf.
I had a similar problem (was trying to back up keyboard custom shortcuts). The path for that was:
dconf dump /org/gnome/desktop/wm/keybindings/ > wm-keybindings.dconf.bak
dconf dump /org/gnome/settings-daemon/plugins/media-keys/ > media-keys-keybindings.dconf.bak
This thanks to redionb's answer on Reddit.