I have a Plone add-on with the following setup.py
setup(
...
install_requires=[
...
'zope.i18n',
...
'Zope2',
],
...
)
If I run bin/instance I get the following traceback:
File ".buildout/eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 1527, in resolveConflicts
raise ConfigurationConflictError(conflicts)
zope.configuration.config.ConfigurationConflictError: Conflicting configuration actions
For: ('utility', <InterfaceClass zope.i18n.interfaces.INegotiator>, '')
File ".buildout/eggs/zope.i18n-3.7.4-py2.7.egg/zope/i18n/configure.zcml", line 3.2-6.8
<utility
provides="zope.i18n.interfaces.INegotiator"
component="zope.i18n.negotiator.negotiator"
/>
File ".buildout/eggs/Zope2-2.13.22-py2.7.egg/ZPublisher/i18n.zcml", line 5.2-8.8
<utility
provides="zope.i18n.interfaces.INegotiator"
component="zope.i18n.negotiator.negotiator"
/>
If I comment out zope.i18n from setup.py, run buildout again, then the instance starts fine.
Surprisingly enough, both bin/instance files (before and after removing zope.i18n) are exactly the same.
So I'm sort of left clueless about what's wrong on defining something on setup.py that anyway the same version gets picked...
Last note, on the distribution's main configure.zcml I have this line:
<includeDependencies package="." />
Does this matter at all?
That seems odd?? obviously it's not possible to registry twice the same utility, but both packages do? I'm very confused about that. Usually you don't need the <includeDependencies package="." /> parts, since all components should be loaded by the plone entry point of z3c.autoinclude. I assume in a default plone environment, one of the components will not be loaded.
I checked in on a Plone 4.3.6... The Negotiator of zope.i18n is used.
So my best bet is, that your <includeDependencies package="." />, also loads the configure.zcml of Zope2, which should not happen.
Removing the <includeDependencies package="." />, may solve your issue.
Related
I installed oh my zsh and zsh auto suggestion. Then I read here (https://www.sitepoint.com/zsh-tips-tricks/) about z zsh, an interesting plugin. And I really wanted to install it. So I put the plugin inside my .zshrc file. But the plugin feature is not active, it's not yellow like source command or alias (and those are properly working). I tried to change place of the plugin line (after / before source), but it didn't work. I did'nt understand the first line. My .zshrc, if someone could help...:
export PATH=$HOME/bin:/usr/local/bin:$PATH
export ZSH="/home/yanalolux/.oh-my-zsh"
ZSH_THEME="ys"
. /home/yanalolux/z.sh
source $ZSH/oh-my-zsh.sh
plugins=(z zsh-autosuggestions)
plugins=(zsh-autosuggestions)
In your .zshrc you have the following two lines:
plugins=(z zsh-autosuggestions)
plugins=(zsh-autosuggestions)
The second line remove the z plugin. You should have only one line with:
plugins=(z zsh-autosuggestions)
According to the ZSH-z plugin Github homepage:
ZSH-z is a command line tool that allows you to jump quickly to directories that you have visited frequently in the past, or recently -- but most often a combination of the two (a concept known as "frecency"). It works by keeping track of when you go to directories and how much time you spend in them. It is then in the position to guess where you want to go when you type a partial string, e.g. z src might take you to ~/src/zsh.
build pipeline is: Typescript, browserify, browserify-css, uglify.
runtime libraries: react, bootstrap.
My application so far has very little functionality (that's why I'm asking if this is going to bite me later, even though it appears to work for now). Later on it will get bigger (react-router, redux, other js libraries like Auth0, maybe even some actual functionality.)
I have an app.css that contains:
#import url("node_modules/bootstrap/dist/css/bootstrap.css");
I then import that into my index.tsx with:
import './app.css';
This all appears to work in that my helloworld react component displays "hello world".
But, during the build, uglify reports:
WARN: Output exceeds 32000 characters
Should I ignore it? And if so, is there a way to suppress it?
Looking at the file produced by uglify shows that it seems to make sure no lines are > 32000 characters - most lines truncate at just short of 32000 (one at 31999).
But there's one line var css='/*!\n * Bootstrap v3.3.7 ...' that is 120K characters long. I assume this is what Uglify is trying to tell me, but what's the big deal?
As per DavidG's comment, you can tell Uglify not to complain about this with the max-line-len option.
But, you can't just add that option, because it only works if you're "beautifying" the code. Which then does other stuff that you may not want to do.
The solution to that is to use the -b option to enable beautification, but then tell Uglify not to actually beautify. o_O
"scripts": {
"uglifyjs":"uglifyjs -b beautify=false,max-line-len=120000"
}
The above will set the line length to 120K - which made the warning go away.
This is more of a workaround than an answer though - it answers the "how do I suppress it" part of my question. I still don't know why it's warning me about that - problems with older browsers or whatever, I don't know.
I'm writing am openembedded/bitbake recipe for openembedded-classic. My recipe RDEPENDS on keyutils, and everything seems to work, except one thing:
I want to append a single line to the /etc/request-key.conf file installed by the keyutils package. So I added the following to my recipe:
pkg_postinst_${PN} () {
echo 'create ... more stuff ..' >> ${sysconfdir}/request-key.conf
}
However, the intended added line is missing in my resulting image.
My recipe inherits update-rc.d if that makes any difference.
My main question is: How do i debug this? Currently I am constructing an entire rootfs image, and then poke-around in that to see, if the changes show up. Surely there is a better way?
UPDATE:
Changed recipe to:
pkg_postinst_${PN} () {
echo 'create ... more stuff ...' >> ${D}${sysconfdir}/request-key.conf
}
But still no luck.
As far as I know, postinst runs at rootfs creation, and only at first boot if rootfs fails.
So there is a easy way to execute something only first boot. Just check for $D, like this:
pkg_postinst_stuff() {
#!/bin/sh -e
if [ x"$D" = "x" ]; then
# do something at first boot here
else
exit 1
fi
}
postinst scripts are ran at roots time, so ${sysconfdir} is /etc on your host. Use $D${sysconfdir} to write to the file inside the rootfs being generated.
OE-Classic is pretty ancient so you really should update to oe-core.
That said, Do postinst's run at first boot? I'm not sure. Also look in the recipes work directory in the temp directory and read the log and run files to see if there are any clues there.
One more thing. If foo RDEPENDS on bar that just means "when foo is installed, bar is also installed". I'm not sure it makes assertions about what is installed during the install phase, when your postinst is running.
If using $D doesn't fix the problem try editing your postinst to copy the existing file you're trying to edit somewhere else, so you can verify that it exists in the first place. Its possible that you're appending to a file that doesn't exist yet, and the the package that installs the file replaces it.
We are moving into Scala/SBT from a Java/Gradle stack. Our gradle builds were leveraging a task called processResources and some Ant filter thing named ReplaceTokens to dynamically replace tokens in a checked-in .properties file without actually changing the .properties file (just changing the output). The gradle task looks like:
processResources {
def whoami = System.getProperty( 'user.name' );
def hostname = InetAddress.getLocalHost().getHostName()
def buildTimestamp = new Date().format('yyyy-MM-dd HH:mm:ss z')
filter ReplaceTokens, tokens: [
"buildsig.version" : project.version,
"buildsig.classifier" : project.classifier,
"buildsig.timestamp" : buildTimestamp,
"buildsig.user" : whoami,
"buildsig.system" : hostname,
"buildsig.tag" : buildTag
]
}
This task locates all the template files in the src/main/resources directory, performs the requisite substitutions and outputs the results at build/resources/main. In other words it transforms src/main/resources/buildsig.properties from...
buildsig.version=#buildsig.version#
buildsig.classifier=#buildsig.classifier#
buildsig.timestamp=#buildsig.timestamp#
buildsig.user=#buildsig.user#
buildsig.system=#buildsig.system#
buildsig.tag=#buildsig.tag#
...to build/resources/main/buildsig.properties...
buildsig.version=1.6.5
buildsig.classifier=RELEASE
buildsig.timestamp=2013-05-06 09:46:52 PDT
buildsig.user=jenkins
buildsig.system=bobk-mbp.local
buildsig.tag=dev
Which, ultimately, finds its way into the WAR file at WEB-INF/classes/buildsig.properties. This works like a champ to record build specific information in a Properties file which gets loaded from the classpath at runtime.
What do I do in SBT to get something like this done? I'm new to Scala / SBT so please forgive me if this seems a stupid question. At the end of the day what I need is a means of pulling some information from the environment on which I build and placing that information into a properties file that is classpath loadable at runtime. Any insights you can give to help me get this done are greatly appreciated.
The sbt-buildinfo is a good option. The README shows an example of how to define custom mappings and mappings that should run on each compile. In addition to the straightforward addition of normal settings like version shown there, you want a section like this:
buildInfoKeys ++= Seq[BuildInfoKey](
"hostname" -> java.net.InetAddress.getLocalHost().getHostName(),
"whoami" -> System.getProperty("user.name"),
BuildInfoKey.action("buildTimestamp") {
java.text.DateFormat.getDateTimeInstance.format(new java.util.Date())
}
)
Would the following be what you're looking for:
sbt-editsource: An SBT plugin for editing files
sbt-editsource is a text substitution plugin for SBT 0.11.x and
greater. In a way, it’s a poor man’s sed(1), for SBT. It provides the
ability to apply line-by-line substitutions to a source text file,
producing an edited output file. It supports two kinds of edits:
Variable substitution, where ${var} is replaced by a value. sed-like
regular expression substitution.
This is from Community Plugins.
I am trying to define some values in my ccnet.config file.
I am running version 1.4.4.83.
I added xmlns:cb="urn:ccnet.config.builder" to my main cruisecontrol element.like:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
next I defined some defines processor constants:
<cb:define prodbuildtag="1.1.25.1207" />
<cb:define testbuildtag="1.1.25.1207">
finally I tried to reference the define values in a tag like so:
<sourcecontrol type="svn">
<trunkUrl>https://someserver/svn/myproject/tags/$(prodbuildtag)</trunkUrl>
<username>johnDoe</username>
<password>JelloW0r1d</password>
<tagOnSuccess>false</tagOnSuccess>
<tagBaseUrl>https://someserver/svn/myproject/tags/</tagBaseUrl>
</sourcecontrol>
When I bulid using the script it treats the define $(prodbuildtag) as an empty string and checkes out the code based on the trunkUrl 'https://someserver/svn/myproject/tags/'. I am having trouble getting the Configuration Preprocessor to work; please help.
I tested the code you posted in 1.5 and it seems to work. If you are including multiple files make sure you have <cruisecontrol xmlns:cb="urn:ccnet.config.builder"> in each file
I think $() syntax resolves environment variables as well.
I know that this works because we do it all the time. Here is an example of what we have in our ccnet.config file:
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:define svnPath="C:\Program Files\CollabNet Subversion\svn.exe"/>
<cb:define svnReposRootUrl="http://someserver/svn"/>
<!-- cc.net auto-updating config project -->
<project name="ccnet-config">
<triggers>
<intervalTrigger seconds="30"/>
</triggers>
<sourcecontrol type="svn">
<workingDirectory>C:\Program Files\CruiseControl.NET\server\config</workingDirectory>
<executable>$(svnPath)</executable>
<trunkUrl>$(svnReposRootUrl)/build/trunk/ccnet/config/XMGBUILD01</trunkUrl>
</sourcecontrol>
</project>
</cruisecontrol>
It's not clear from your question where the cb:define tag is in relation to where you are using it. I would try putting it as child of the cruisecontrol element. I don't know if it can be a child of anything else... I've never tried.