I am trying to create a patch for my application. Implementing the example described here worked as expected. However, the files for each version are stored in separate directories. Version 1.0 files are in c:sample\1.0 and 1.1 files are in c:sample\1.1. If I move the files to a single location, create the 1.0 installer, modify the files, and create the 1.1 installer; wixmst output of torch contains no differences. When I run pyro I get:
warning PYRO1079 : The cabinet 'media1.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet.
This is a problem for me because the files for my project are kept in a single git repository. We use branching and tagging to delineate versions. Because of this I only have one directory of files.
I have the .msi and .wixpdb for both versions.
How can I create my patch in this situation?
Pyro requires access to the .wixmst and the old and new files. If you only have one set of files (newer or older) then the patch will obviously find no file differences. That is why you are getting the error from Pyro.
If you use bindpaths to create the original .msi files (and their .wixpdbs) then you can provide the old paths using the -bt switch to pyro and the new paths to the -bu switch. If you didn't use bindpaths and you need to recreate the old directory structure for the old files and create a new directory structure for the new files.
If you can't get the old and new files to be found (bindpaths work best) then you'll have to do admin image type patching.
Related
I'm in the process of converting a rather huge project to a Windows 10 Store app. I've gotten it to compile and now can't get past several APPX1101 errors - "Payload contains two or more files with the same destination path". The files are .xml files part of the project, e.g. "baseDir\Assets\foo\timers.xml" and "baseDir\Assets\bar\timers.xml". Different files and different paths.
The solution and projects are created by CMake (3.72). The cmake files have been modified to support creating a Windows 10 store app platform config.
It appears that the directory tree has been flattened and files are overlapping. But how or why eludes me. Every UWP project I've seen contains an "Assets" folder under the main project but this one does not. I see files such as Logo.png and SplashScreen.png in folder named "Resource Files". The files causing the errors are under the folder named "Assets" which existed before this was a UWP project.
Primarily:
How can I fix this error? Did I misconfigure CMake?
Additionally:
How to avoid directory flattening?
There are a few hundred data files taking up a few hundred megabytes used by the program. Will I need to add each of them to the solution to be packaged?
Updates:
I've gleaned more info but not enough to fully satisfy the question. The directory flattening in the output occurs due to how the files are added to the project via CMake and how the original Windows product was packaged. The XML files are added to the project with a full path in the .vcxproj. The .vcxproj.filters also use a full path to the file and a filter like "Data\foo". The desktop Windows version didn't need to care since it knew where to find it's data relative to the executable and was packaged by an external tool.
I've manually added an "Assets" filter and modified the .vcxproj and .vcxproj.filters files. The .vcxproj file needed a property added to the file's include. This uses relative paths and gets rid of the APPX1101 duplicate error.
.vcxproj
<XML Include="..\Base\Assets\foo\Data\timers.xml">
<Link>Assets\foo\Data\timers.xml</Link>
</XML>
.vcxproj.filters
<XML Include="..\Base\Assets\foo\Data\timers.xml">
<Filter>Assets\foo</Filter>
</XML>
Update 2
From what I can tell, it's not possible to get CMake to add a <Link> to XML and other .vcxproj Include types. I went through the latest CMake source code (3.8rc). The <XML Include> is added to the .vcxproj in cmVisualStudio10TargetGenerator::WriteExtraSource() in cmVisualStudio10TargetGenerator.cxx. Other types have the option to set the flag to add the <Link> but XML and other data types do not have code to set the flag.
The only options I can see are modifying CMake source or reworking the project to add data files using relative paths that match the same <Filter> for the matching Include in the vcxproj.filters file. This is only a problem with CMake. Visual Studio 2015/2017 have no problem adding assets above your tree. The MS UWP examples on GitHub do it to share common data between sample projects.
It's been a while and I'm posting this as an answer in case someone else runs into this problem. I'm not marking it accepted because I find the workaround rather weak. My knowledge of CMake is limited and my understanding of Universal Windows apps even less.
The primary issue is that by design, CMake does not build a relocatable solution. i.e. you can't xcopy a Windows solution to another tree and expect it to work as you would would with one generated from within the Visual Studio IDE.
The second issue is that this was a huge pre-existing project already targeting multiple platforms. And by huge, I mean it ships on a dual layer blu-ray disc. The location of asset files was fixed and was above the location of the CMake build folder. This caused files to be stripped of their path when added to the layout whenever their location was not under the expected assets folder.
There is no way in the current CMake (3.8) to add a <link> tag to the include in the project file. And CMake creates the include tag with the full path to the file not a relative one by design.
The workaround I came up with was to add a step to the batch file that invokes CMake to edit the .vcproj and vcproj.filters files to change the fixed asset paths relative ones and then added another step to create a symbolic link/junction (SysInternals.com) under the build folder to the location where the assets were. The assets now appear as being under the expected asset folder are now added correctly to the layout.
As I said, not ideal but it works. The real solution would be to re-organize all the data but this is not something that can happen for this project when a vast amount of data is generated from different script, tools, sources and contributors.
I've recently tried to upgrade my Trac from version 0.12.2 to version 1.0.1 by following the upgrade guide on the Trac website. It mentioned to remove the attachment folder for the ticket and wikis because the folder has been changed from /path/to/project/attachments to /path/to/project/files/attachments. So I backed up the attachment folder and after the upgrade I put it back into my project folder under files/attachment.
When I try to access an attachment in the new trac environment it has trouble finding it. It's trying to look for the attachment in this
/path/to/project/files/attachments/fad/fadece229cc1ef23ce5f467cec5f4675cec7ace5ad7c148c
folder, and the file names are in hashed code like
b10a69f289e6ae408878d2286758a3121be4759.txt.
instead of its actual name. Any files that are uploaded after the upgrade will go into this folder instead of the respective Wiki or ticket folder like it used to do before my upgrade. Has anyone experienced this issue while doing the Trac upgrade?
Upgrade to 1.x includes a file store redesign including changed file paths.
File names with path are hashs now, computed from user-supplied names, and no the lightly encoded names. Consequently the backup doesn't match the expected new paths at all - as you experienced.
The conversion of an existing attachment storage is part of the upgrade script, so you clearly misread the upgrade guide. The removal was meant for attachment sub-directories not managed by Trac core, and as post-upgrade-cleanup.
You should rather leave the files and let the store get transformed for you. Ensure you read the logs of the upgrade process to notice delicate issues immediately.
I am trying to use Nuget to distribute a ms build .targets file. I need to modify some elements of the file to include the installed path of a few assemblies. For that I would like to use the tools folder. I am having a hard time finding the token (if it exists) to do the replacement. Has anyone encountered this problem or know of a workaround?
http://docs.nuget.org/docs/creating-packages/configuration-file-and-source-code-transformations
You'll have to go the PowerShell route to get this done, as no transform exists AFAIK. The init.ps1 file can process some parameters provided by the NuGet VSIX.
Simply add the following to the top of the init.ps1 file and use the $installPath variable in your scripts that modify the file content.
param($installPath, $toolsPath, $package, $project)
Check here for an example usage.
I am working on an embedded system that uses buildroot as a tool for building the kernel and the root filesystem. I want to apply some patches to this kernel source tree, Can somebody tell me how buildroot apply patches?
To expand on #pradeepchhentri's answer. Quilt will look for a file located in the same folder as the *.mk file. To construct the appropriate file:
diff your source package from the original into a file called
packagename-number-description.patch
where
packagename - has to be identical to the package name
number - is the order in which the patches should be applied if you have more than one patch to apply (otherwise it will be applied alphabetically)
description - can be any free text
Place this file into the package at the same level as the [packagename].mk file and the package/Config.in file.
Don't forget to blow away your build files or do a [package]-rebuild if you do this. You should see a "Patching..." message if this is done correctly.
some details about patch files in the buildroot project:
you have to
diff -u "old_file" "new_file" > file.patch
while standing exactly above extracted location of your package tar.gz defined in
PACKAGE_NAME_SOURCE
it means, your path to the file must include extracted package folder name.
in case you wonder if the "old_file" path would be different from the original one - don't worry, the important one is the "new_file" path and name - it should match your package extracted one.
naming convention for the patches already used/defined in buildroot (all parts are separated with '-' sign):
4 digits patch priority (starting from 0001)
target filename
reason for patching
.patch extention
example:
0001-configure.ac-convert-AC_TRY_COMPILE-AC_COMPILE_IFELS.patch
deposit patch file inside buildroot/package/"your package name"/ folder.
there is no need for configuration files to modify, all patches will be tried for application automatically.
in case of the failure, the reject-patch file (named similar to the file you are trying to patch but with .rej extention) will be deposited inside package extracted folder.
Use *_OVERRIDE_SRCDIR and track everything in submodules
Instead of using patches, I highly recommend that you to this instead:
myproject/
.git/
submodules/buildroot/
submodules/source_of_my_package/
and just track the source of your in a submodule that points to your fork of the project with your patches on top.
This will make everything much saner and easy to keep track of.
More info at: How to modify the source of Buildroot packages for package development?
BR2_GLOBAL_PATCH_DIR out-of-tree patches
Directory structure:
.git/
buildroot/ Buildroot submodule as mentioned at: https://stackoverflow.com/a/23635403/895245
global_patch_dir/packagename/0001-my-test.patch
Add to config:
BR2_GLOBAL_PATCH_DIR=../global_patch_dir
Then build with:
cd buildroot
make
The patch should be applied to output/build/packagename-1.0.0/ before build.
After studying the buildroot architecture, I came to know that buildroot uses quilt tool for applying the patches. quilt keeps track of all the patches in the a file named "series" which is present in the "patches" directory. You have to keep your patches in this directory. And add your entry of patches in the series file in the order in which you want the patches to be applied keeping the patch to be applied first at the top.
This way when you will run the buildroot makefile, it will automatically apply the patches listed in the series file.
My PackageMaker project was generating a .mpkg file, but then, all of the sudden, when I go to build, it only generates .pkg files. The .mpkg files are actually directories into which I place my custom installer bundle along with an InstallerSections.plist file to specify the order in which my custom view should display. The .pkg files are not directories and I have no way to add my custom installer bundle to it.
Anyhow, something is awry as PackageMaker no longer lets me generate a .mpkg file. Any idea why that might be? Is there some other way I should be approaching this?
Thanks.
p.s. If you are thinking of suggesting I ought to check out this tutorial, please don't bother. It's way out of date. Thanks.
Your pmdoc is a distribution project, and you've set the pmdoc's minimum system version to 10.5. PackageMaker always generates flat packages in this case.
There are three solutions:
Choose “Install Properties…” from the Project menu, and set the pmdoc's minimum system version to 10.4. This is the go-back-to-.mpkg solution.
Use the Flat Package Editor (hidden inside the PackageMaker bundle) to add the custom installer bundle. The contents of a .pkg file are the same as, and lain out similarly to, those of a .mpkg bundle.
Since flat packages are xar archives, use xar to extract the contents of the .pkg file to a temporary directory, add the custom installer bundle in that directory, then use xar to re-assemble the .pkg file from the temporary directory.