I want to install typo3 using dummy and source packages, how is it done ? i unpack both tar.gz into each own directory or mix them into one single directory ?
Even creating ENABLE_INSTALL_TOOL file and giving permissions, the instalation is is still locked.
Thank's in advance
There is also source+dummy package available, download it and unzip. Downloading separate dummy or source packs makes sense only when you want to add missing element or update the sources.
http://typo3.org/download/
Related
I have build a nuget package at published it to a nuget.server site. But when I try to use the package form the server the .targets file from build folder is not in the file. But if I use the package from a local folder it works as it should. How do I get it to work ?
If i look in the package in the folder on the server it looks ok.
It's not clear to me if you mean using (referencing and restoring) a package, or building (packing) a package.
If the problem is with packing the nupkg, NuGet requires the props and targets files to have specific filenames in specific folders, but if you got it to work at least once, you probably already know that. If this is not the problem with packing, you need to give us more information because not using the correct filename convention is the most common problem and I can't guess what else the problem could be. In particular, if the package is being packed differently on your local machine compared to when it is packed on the server, it means there is something different between how you pack on the two computers, so we need more information about how the build and pack work with your project.
If the problem is with using (restoring) the package, there are a few possibilities. My best guess is that you once had a package without the targets file working correctly, and you restored the package on the server. By design, NuGet packages are immutable which means it's invalid for the contents of a package (same ID and version) to change. This allows NuGet to download the package from a remote feed once, save it in the global package folder (not a cache; they never expire) and the next time NuGet needs to restore the same package (id + version) it uses the one in the global package folder, it does not download again. This means if you once built a bad nupkg and restored it on a machine, then fix the nupkg and kept the same version number, that machine will never get the fixed nupkg. You need to delete it from the global packages folder. I'm not 100% sure, but I think if you have a local file feed and you restore a project that uses packages.config, the nupkg does not get saved in the global packages folder, so doesn't have the same problem. In short, I think the problem is that you changed the nupkg contents once without changing the version number, and one of the machines has the old copy in its global packages folder that it keeps using.
If that's not the problem, the next most likely cause is that the nupkg on the server feed has different contents to the nupkg in the local feed. I've never used NuGet.Server, but some nuget respositories (like nuget.org) do not allow overwriting nupkgs. So, if you pushed a nupkg to your server, fixed a problem in your nupkg without changing the version, then tried to push again, the second push might have failed.
In summary, your question doesn't provide enough information for us to help you, but I wrote about the most common issues above. If it doesn't help, you need to provide us with more information. An example of the problem is the best way to give us enough information to help you.
I saw someone "extending" an existing viewdef by simply copying the stock file into the custom folder and then modifying that copied file.
It makes sense, but I don't see that in official documentation.
Example modules/Leads/metadata/editviewdefs.php copied to custom/modules/Leads/metadata/editviewdefs.php
Is this safe/correct way of doing it?
That's the correct way to do it.
A quick reminder about future SuiteCRM upgrades and view/edit-defs.
Sometimes newer SuiteCRM versions add/edit fields to modules and the upgrade process will not upgrade your copy of those files, sometimes causing weird errors.
If you have access to a Backup is more easy to copy the file from there and then edit it with a new Uploader Package.
I have compiled the yocto fido and i want to clean required libs in tmp/sysrootdir instlled by some recipes like qtbase-native. can anyone guide me how to do that any particular commands are present or I need to delete manually ?
Thanks!
I'm afraid that Yocto does not provide any build in solution for cleaning files from shared headers area like tmp/sysroots/.
Indeed please familiar with this do_clean tasks (there exist 3 of them) which are available for every recipe: http://www.yoctoproject.org/docs/2.4.1/ref-manual/ref-manual.html#ref-tasks-clean
The easiest way is to delete tmp/. It will be rebuild very quickly from sstate-cache.
As I need to develop java, php, c++, I use several eclipse packages.
so I try to simple to copy several packages into one, and then I use these option to start the eclipse:
1. -clean
2. osgi.checkConfiguration=true
but it doesn't work, I only find the last copied packages after the IDE start.
Get one of the packages from their site and use the Install new software... feature under the help menu.
I think the most straightforward way to get the modules for all of the languages to play nicely together, though I admire your DIY spirit.
Try to use Yoxos for building your custom Eclipse distribution.
From luxsie:
How to merge several setup packages of Eclipse?
Whom this is for?
The ones that can not hold back their temper any longer when trying to install another Eclipse function package. Right the installation speed from some countries is too slow to bear, also the Equinox P2 always try to connect the Download.Eclipse.org. Much to damn.. when your Internet connection closed or reset all of a sudden and got all downloaded files broken. Also OSGi based Eclipse plugins is chaos -- always have some conflict errors.
Oh that is another problem..
Do the following steps:
1 Download the Install Packages that you need from www.eclipse.org. Also please remember verify to see if that is correct package. I choosed J2EE with C/C++.
2 Unpack one package with uncompress softwares, such as 7-zip and WinRAR. unzip all the files to a directory you wanna install to. for example "D:\Eclipse\".
3 open Configurations. Files "\configuration\org.eclipse.equinox.source\source.info" and "\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info" in the installation directory is the ones that need to be merged. also you need "\configuration\org.eclipse.update\platform.xml".
4 open the other packages and fetch their configuration files, and merge files.
to Bundles.info:
Open the bundle.info with any Functional Text Editor, copy all text begin from the line after "#version={Number}" and paste it to another. [{Number} means any Integer number.]
to Source.info:
Similiar with what you did with the bundle.info. If not modified, that line should be the 3rd line in the text file.
to Platform.xml:
Open the file, then find where "feature id=" starts just after the "site" node. Find the "/site" tag and copy all the text between them, paste to another file just before the "/site" tag.
[You can do the similiar also marked feature tags with artifacts.xml]
5 when merging i suggest you to make a new directory and when finished please remember copy the merged file to the one where should it be and overwrite. [I mean where it comes from]
Although not merge "platform.xml" will not cause any functional errors, it will make the About dialog with no button -- to ugly yeah?
[= =|||]Ugly is caused by the artifacts.xml in the installation directory...
6 Open all the package, find "plugins" and "features" directories.now extract!
first extract the one you want most. I extracted JEE package.
then extract the other ones. I don't see any problem whether Overwrite the ones or not.
7 do open a console window, and locale in the installation directory, and then execute "eclipse.exe".
Well, somebody ask me why i paid no attention to the Artifacts.xml in the installation directory. That's because Eclipse will never check the file. It seems to be when you want to update using zip files -- however this way is blocked for lacking site.xml file now.
Then guys, wait a several minutes for eclipse to do some sorting and cleaning job for the merged configurations.. and install your plugins!
INFO: if you face some problems after install a new plugin and restart.. that is because you haven't finish a complete artifacts.xml merging.
You may delete all the artifacts.xml 's header [document start to the "artifacts size = '{Number}'"] and its bottom [from "/artifacts" to document end]. just merge the left content. and make one file just contains the header and bottom, paste the merged one in.
Eh..maybe you can calculate the {Number}s' sum and correct the one in the final document.
I'm new to NuGet -- just started using it and got myself a copy of WatiN.
I'm trying to trim down the size of the folder that was pulled back before I put it into version control. I noticed that WatiN.2.0.50.nupkg is about 12mb. I noticed from this link that the .nupkg is essentially a compressed version of the package contents. Is it OK to delete it, or might doing so cause any issues in the future?
If you delete it we can't update/uninstall since we use that file as a record of what is currently installed. We're looking at a feature that would allow people to restore the packages from packages.config so you could avoid putting packages in source control altogether. More info here http://nuget.codeplex.com/workitem/165