Just getting started with JOlivers event store library and having issues with some of the Nuget commands in the build.cmd. here's the log, perhaps you're already aware of the issue but i thought i'd put it up here.
=== COMPILING ===
Compiling / Target: v4.0 / Config: Release
S:\SourceControl\Test Projects\EventStore\bin\nuget\NuGet.targets(6,9): error : Input string was not in a correct format. [S:\SourceControl\Test Projects\EventStore\src\proj\EventStore.Persistence.RavenPersistence\EventStore.Persistence.RavenPersistence.csproj]
S:\SourceControl\Test Projects\EventStore\bin\nuget\NuGet.targets(6,9): error MSB3073: The command ""S:\SourceControl\Test Projects\EventStore\src\..\bin\nuget\nuget.exe" install "S:\SourceControl\Test Projects\EventStore\src\proj\EventStore.Persistence.RavenPersistence\packages.config" -source "" -o "S:\SourceControl\Test Projects\EventStore\src\..\bin"" exited with code 1. [S:\SourceControl\Test Projects\EventStore\src\proj\EventStore.Persistence.RavenPersistence\EventStore.Persistence.RavenPersistence.csproj]
The master branch of EventStore appears to be broken at the moment. The 3.0 branch is in better shape but is also slightly broken. To fix the 3.0 branch so that it builds, you need to upgrade the 1.5 version of nuget.exe to 1.6. The easiest way to do that is to execute \bin\nuget\NuGet.exe update -self in the repository. I already submitted a pull request to JOliver with that change.
(I also submitted a pull request with a few minor fixes for the example project.)
Related
My goal is to deploy NuGet packages (to in-house Nuget server) that auto-increment the version based on date and last Rev, and include a -beta tag.
I am using VSTS to build and package using cake, with a build number format of $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r).
I have a .nuspec manifest file that specifies: $version$, and a NuGet Packager as such:
This works great. But now, I want to have the option of a NuGet packager that produces a package that is tagged as beta, and therefor show in VS NuGet Package Manager as pre-release. I can do this if I hard code the version number with "-beta" appended in the NuGet Packager:
But how can I include the -beta tag AND the the build number? I think I need to include a variable in NuGet Arguments that will return $(BuildDefinitionName)_2.0.$(Date:yyMMdd)$(Rev:.r) plus "-beta", but I'm not sure how.
I tried creating a variable (under the Variables tab) with the Build Number Format as the value, then referencing the variable in NuGet Arguments (-Version theVariable), but received as error that the variable is not supported.
I may be going about this all wrong, however my searches have not turned up any hints on how to auto-increment versions from the date, and include a -beta tag.
NuGet Packager with version using build number, adding -beta
I could reproduce your scenario on my side. In my opinion, Nuget pack task with build number doesn't support character or numbers. You may check this task:
case "byBuildNumber":
tl.debug("Getting version number from build number")
if(tl.getVariable("SYSTEM_HOSTTYPE") === "release")
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_AutomaticallyVersionReleases"));
return;
}
let buildNumber: string = tl.getVariable("BUILD_BUILDNUMBER");
tl.debug(`Build number: ${buildNumber}`);
let versionRegex = /\d+\.\d+\.\d+(?:\.\d+)?/;
let versionMatches = buildNumber.match(versionRegex);
if (!versionMatches)
{
tl.setResult(tl.TaskResult.Failed, tl.loc("Error_NoVersionFoundInBuildNumber"));
return;
}
if (versionMatches.length > 1)
{
tl.warning(tl.loc("Warning_MoreThanOneVersionInBuildNumber"))
}
version = versionMatches[0];
break;
That is the reason why the field $(BuildDefinitionName) and beta could not appear in our package version when we use them in our build number.
If we specify the nuget version in the nuget arguments, but this argument could not parsing predefined variables, like $(Rev:.r).
The limitations of these two situations have caused your current issue.
The workaround to resolve this issue, is using nuget custom task with parameter -version $(Build.BuildNumber) and move the field $(BuildDefinitionName) from our Build number format, otherwise, we still receive the error the version is invalid.
So, you nuget custom looks like:
And the Build number format:
Now, you can see it works fine:
Note:
You said you using VSTS to build and package using cake, but the images you posted shows that you are using NuGet Packagertask in TFS 2015. If you are sure using TFS 2015, I am afraid above workaround will not work for you. Because the custom nuget task is not support for TFS 2015.
Hope this helps.
I am on a raspbian stretch system with the spur32 VM for ARM and a Pharo 7 image. At Startup I always get an exception: Error - Module not found.
It seems to have to do with lgitlibrary. I really cannot figure out what this error is about.
Any ideas?
Thanks,
Henrik
I see. If you check #unixModuleName
unixModuleName
| pluginDir |
pluginDir := Smalltalk vm binary parent.
#('libgit2.so' 'libgit2.so.0')
detect: [ :each | (pluginDir / each) exists ]
ifFound: [ :libName | ^ libName ].
self error: 'Module not found.'
Here you have your error message: self error: 'Module not found.'
You probably have libgit2.so or libgit2.so.0 missing (or dependencies). You may suffer with similar problem as me: Getting error when adding OSSubprocess to my Pharo 6.1 on Centos 7.4x.
You should check the dependencies with ldd (check my question for details).
Edit Adding information due to comment:
I have yet to use IceBerg (the Pharo's git integration). My guess, would be to "(re-)initialize it": (Smalltalk at: #LGitLibrary) initialize.
For more information, I recommend reading these: pharo's iceberg and some Pharo project that uses git like pharo-contributor and checking blog pharoweekly (for some information about the pharo-contributor) - https://pharoweekly.wordpress.com/2018/04/24/pharo-contributor-to-contribute-to-pharo.
You may want to use some guide "How to use git and github with Pharo". Which was done by Peter Uhnak (you can find him on SO).
I had the similar problem and I needed to build libgit2 library from source using this instructions. The basic build didn't work because Pharo wasn't able to initialize the library. I compiled it again with parameter -DSTDCALL=ON an it works.
I've forked a package from github have made some changes. I'm trying to install the version of the package to which I've made changes with install_github(), but am getting an error message. Any suggestions?
The forked version: https://github.com/embruna/refnet
The edited version on the branch: https://github.com/embruna/refnet/tree/proposed-updates
I can install the forked version with:
install_github("embruna/refnet", subdir="pkg")
I tried to install the version on the branch with the following:
install_github("embruna/refnet#proposed-updates", subdir="pkg")
But then get this error:
** help
*** installing help indices
** building package indices
Error in scan(file = file, what = what, sep = sep, quote = quote, dec = dec, :
line 1 did not have 6 elements
ERROR: installing package indices failed
* removing ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/refnet’
Error: Command failed (1)
Thanks for any suggestions.
EDIT: There were two problems: 1) the install_github syntax I used incorrect and 2) there was a folder in "pkg" that was throwing an error even after correcting the syntax. See below for details.
I'm guessing that specifying the branch with # but the subdirectory with the subdir argument is confusing devtools.
This works for me (specifying both subdir and branch in the repo argument):
install_github("embruna/refnet/pkg#proposed-updates",
So does this (specifying both branch and subdir as separate arguments):
devtools::install_github("embruna/refnet",
ref = "proposed-updates", subdir = "pkg")
The output starts this way ...
Using GitHub PAT from envvar GITHUB_PAT
Downloading GitHub repo embruna/refnet#proposed-updates
from URL https://api.github.com/repos/embruna/refnet/zipball/proposed-updates
Installing refnet
This is with devtools 1.12.0
I was able to install your proposed-updates branch with this:
install_github("embruna/refnet", branch = "proposed-updates", subdir = "pkg")
I get a bunch of warnings, but no error messages.
I'm new to Purescript and am following the tutorial for installation. Purescript itself is working and I can start the CLI using pulp psci, but installing purescript-list runs into trouble.
Having entered the command bower install purescript-lists --save, I get a long list of package names, but when it gets to purescript-eff and purescript-prelude I run into some version conflicts:
bower purescript-eff#^2.0.0 cached https://github.com/purescript/purescript-eff.git#2.0.0
bower purescript-eff#^2.0.0 validate 2.0.0 against https://github.com/purescript/purescript-eff.git#^2.0.0
Unable to find a suitable version for purescript-eff, please choose one by typing one of the numbers below:
1) purescript-eff#^1.0.0 which resolved to 1.0.0 and is required by purescript-console#1.0.0
2) purescript-eff#^2.0.0 which resolved to 2.0.0 and is required by purescript-st#2.0.0
Prefix the choice with ! to persist it to bower.json
? Answer
A similar message is shown for purescript-prelude. No matter which options I choose, both pulp build and pulp run fail with:
$ pulp build
* Building project in /Developer/purescript/training1
Error found:
in module PSCI.Support
at /Developer/purescript/training1/bower_components/purescript-psci-support/src/PSCI/Support.purs line 10, column 34 - line 10, column 53
Cannot import value unsafeInterleaveEff from module Control.Monad.Eff.Unsafe
It either does not exist or the module does not export it.
See https://github.com/purescript/purescript/wiki/Error-Code-UnknownImport for more information,
or to contribute content related to this error.
Compiling PSCI.Support
* ERROR: Subcommand terminated with exit code 1
What have I missed here?
Thanks
Chris W
If you are using psc version 0.10.* you should go with prelude, lists and eff v2*.
If you are using psc version 0.9.* you should go with prelude, lists and eff v1*.
If you are using psc 0.10.* you might want to update pulp to version 9.1.0
The problem occurs due to breaking changes between psc 0.9 and 0.10 and the relevant libraries. by writing bower install purescript-lists --save you are asking bower for the latest dependencies which conflict with the dependency versions specified in your bower.json.
I'm trying to build a toolchain for my hobby kernel, but I'm running into problems when building Newlib. Whenever I try to run autoreconf in my kernels directory under newlib/libc/sys/ I get an error:
configure.in:5: error: support for Cygnus-style trees has been removed
Here is the content of configure.in (basically, taken from the below tutorial):
AC_PREREQ(2.59)
AC_INIT([newlib], [NEWLIB_VERSION])
AC_CONFIG_SRCDIR([crt0.S])
AC_CONFIG_AUX_DIR(../../../..)
NEWLIB_CONFIGURE(../../..)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
and the source for Makefile.am (again mostly from tutorial):
AUTOMAKE_OPTIONS = cygnus
INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS)
AM_CCASFLAGS = $(INCLUDES)
noinst_LIBRARIES = lib.a
if MAY_SUPPLY_SYSCALLS
extra_objs = $(lpfx)syscalls.o
else
extra_objs =
endif
lib_a_SOURCES =
lib_a_LIBADD = $(extra_objs)
EXTRA_lib_a_SOURCES = syscalls.c crt0.S
lib_a_DEPENDENCIES = $(extra_objs)
lib_a_CCASFLAGS = $(AM_CCASFLAGS)
lib_a_CFLAGS = $(AM_CFLAGS)
if MAY_SUPPLY_SYSCALLS
all: crt0.o
endif
ACLOCAL_AMFLAGS = -I ../../..
CONFIG_STATUS_DEPENDENCIES = $(newlib_basedir)/configure.host
Yes, I have tried removing the AUTOMAKE_OPTIONS=cygnus.
I've Googled around and been trying to understand this, and as far as I can tell, it is because of the version of autotools I'm using. According to the tutorial I used originally (OSDev - OS Specific Toolchain), I need an older version. My problem is that I'm using Kubuntu, which uses the apt package manager, and that version is not available to fall back to even temporarily. There has to be some fix for this. Either Newlib is outdated (this release is from December of 2013...) or the developers are crazy for depending on an outdated autotools version.
The only other thing I can think is that this is a message from the newlib configuration scheme itself in which case I have no idea how to modify my configure.in and Makefile.am to align with the new newlib configure format. That tutorial is the only one I've found that didn't use libgloss (which I'd prefer not to do) so far and the documentation of adding a new target is rather lacking in the documentation for newlib (or I missed something).
Here is some version information:
System: Kubuntu 14.04
Automake: 1.14.1
Autoconf: 2.69
Newlib: 2.1.0
Unfortunately I'm afraid using automake 1.12 or earlier is your only choice. Ubuntu has an Automake1.11 separate package to help you there, if I'm not mistaken, since the compatibility between 1.12 and 1.14 is generally good, but before that it was spotty.
I am writing this answer for people struggling with the tutorial described here.
I am in the same situation you are (or were), I am building a kernel from scratch and I wanted to port newlib to my toolchain. Unfortunately I think the tutorial has become out of date because I followed the instructions EXACTLY, even installing the correct software with the proper versions (including the correct newlib version). The accepted solution above didn't work for me but I found another solution that might work for others:
Step 1 - get the correct software
Acquire Automake (v1.12) and Autoconf (v2.65) from here:
http://ftp.gnu.org/gnu/automake/automake-1.12.tar.gz
http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
Step 2 - build process
Untar both of the archives:
tar xf automake-1.12.tar.gz
tar xf autoconf-2.65.tar.gz
Create a destination folder:
mkdir ~/bin
Create a build folder:
mkdir build
cd build
Configure automake first:
../automake-1.12/configure --prefix="~/bin"
Make and install
make && make install
Now lets configure autoconf
../autoconf-2.65/configure --prefix=~/bin
Then make and install:
make && make install
You should now have the proper binaries in ~/bin!
Step 3 - update PATH
To add these binaries to your path temporarily (recommended):
export PATH=~/bin:$PATH
Once you update your path, rerun autoconf and autoreconf and it should complete.