Why does Chocolatey fail to pack a ~2GB self-contained package? - windows

I would like to build a self-contained "app.nupkg" package from "app.nuspec" file using cpack command. Here is the directory tree of my application:
C:\CHOCO_REPO\APP
│ app.nuspec
│
├───bin
│ dist
│ Setup.exe
│
└───tools
chocolateyinstall.ps1
chocolateyuninstall.ps1
The dist file (size ~2G) is actually the program. When I try to run:
cpack app.nupgk
I get:
bin\dist
Cannot access a closed stream
with debug option:
cpack app.nuspec -d
I get:
Attempting to build package from 'app.nuspec'.
bin\dist
Attempting to delete file "C:\choco_repo\APP\app.nupkg".
Chocolatey had an error occur:
System.ObjectDisposedException: Can not access a closed Stream.
at System.IO.Compression.DeflateStream.EnsureNotDisposed()
at MS.Internal.IO.Packaging.CompressStream.Flush()
at MS.Internal.IO.Zip.ZipIOLocalFileBlock.FlushExposedStreams()
at MS.Internal.IO.Zip.ZipIOLocalFileBlock.UpdateReferences(Boolean closingFlag)
at MS.Internal.IO.Zip.ZipIOBlockManager.SaveContainer(Boolean closingFlag)
at MS.Internal.IO.Zip.ZipIOBlockManager.SaveStream(ZipIOLocalFileBlock blockRequestingFlush, Boolean closingFlag)
at MS.Internal.IO.Zip.ZipIOModeEnforcingStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at System.IO.Packaging.PackagePart.Close()
at System.IO.Packaging.Package.DoClose(PackagePart p)
at System.IO.Packaging.Package.DoOperationOnEachPart(PartOperation operation)
at System.IO.Packaging.Package.System.IDisposable.Dispose()
at NuGet.PackageBuilder.Save(Stream stream)
at chocolatey.infrastructure.app.nuget.NugetPack.BuildPackage(PackageBuilder builder, IFileSystem fileSystem, String outputPath)
at chocolatey.infrastructure.app.services.NugetService.pack_run(ChocolateyConfiguration config)
at chocolatey.infrastructure.app.runners.GenericRunner.run(ChocolateyConfiguration config, Container container, Boolean isConsole, Action`1 parseArgs)
at chocolatey.infrastructure.app.runners.ConsoleApplication.run(String[] args, ChocolateyConfiguration config, Container container)
at chocolatey.console.Program.Main(String[] args)
Exiting with 1
Any help? thank you

It could be the size. NuGet and .NET have some limitations around the size of what can go into the package.
It could be just Choco, but I doubt it since it is built as AnyCPU which means x64 when in 64-bit.
I've seen some folks do some ingenious things to take a 6GB iso and split it into multiple packages that are dependencies of a master package.

Related

Access denied when building esp-idf-sys for Rust project for ESP32 on Windows 10

I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!

use k8s deepcopy-gen generate code failed

I am going to use k8s code-generator to generator deepcopy file and my project under GOPATH/src, but i seems not work and got a problem about GOROOT.
deepcopy-gen command is deepcopy-gen -i k8s_customize_controller/pkg/apis -p k8s_customize_controller/pkg/client -v 10
output blow:
[root#centos72-k8s code-generator]# deepcopy-gen -i k8s_customize_controller/pkg/apis -p k8s_customize_controller/pkg/client -v 10
I0122 02:51:04.609157 17278 parse.go:383] importPackage k8s_customize_controller/pkg/apis
I0122 02:51:04.609359 17278 parse.go:330] addDir k8s_customize_controller/pkg/apis
I0122 02:51:04.730397 17278 parse.go:404] unable to import "k8s_customize_controller/pkg/apis": package k8s_customize_controller/pkg/apis is not in GOROOT (/usr/local/go/src/k8s_customize_controller/pkg/apis)
I0122 02:51:04.730701 17278 main.go:82] Completed successfully.
unable to import "k8s_customize_controller/pkg/apis": package k8s_customize_controller/pkg/apis is not in GOROOT
it seems this problem about GOROOT?
how to resolve this problem?
I had similar issue with an error like this:
Generating deepcopy funcs
F1018 10:51:28.259741 74132 main.go:80] Error: Failed making a parser: unable to add directory "github.com/[my-git-account]/[repo-name]/pkg/apis/v1": No files for pkg "github.com/[my-git-account]/[repo-name]/pkg/apis/v1"
The problem was that I recently moved my github golang projects folders out of the $GOPATH/src folder (which is in my case is ~/go/src), because it worked well on vanilla Ubuntu and WSL Ubuntu, but it has challenges to update packages on MacOS - I moved all my project from the folder ~/go/src/github.com/[my-git-account]
(where the code-generator expected them) to the folder ~/dev/[my-git-account].
Solution I use to fix the error above - to create a symbolic link on my current github projects folder to the $GOPATH/src/github.com:
ln -s ~/dev/[my-git-account] $GOPATH/src/github.com
This way there is a folder $GOPATH/src/github.com/[my-git-account] (provided by the sym-link) with golang projects, where code-generator can find them.
Faced one drawback of this trick - in the IDE navigation to the method can move to the linked source (within SDK package by the link - not to the source code, opened in the IDE).

What should the configure.win file contain in the cplex API package?

I'm trying to install cplex API in windows. I'm not super familiar with the programme so I've been using this link from R bloggers
https://www.r-bloggers.com/2017/01/using-cplex-in-r-installing-cplexapi-in-windows-10/
After using the windows command prompt I get the following responses:
R CMD build --no-build-vignettes --no-manual --md5 C:\Users\Rharris\Desktop\cplexAPI
* checking for file 'C:\Users\RHARRIS\Desktop\cplexAPI/DESCRIPTION' ... OK
* preparing 'cplexAPI':
* checking DESCRIPTION meta-information ... OK
* cleaning src
Warning in cleanup_pkg(pkgdir, Log) :
unable to run 'make clean' in 'src'
* checking vignette meta-information ... OK
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* adding MD5 file
* building 'cplexAPI_1.4.0.tar.gz'
Warning: file 'cplexAPI/cleanup' did not have execute permissions: corrected
Warning: file 'cplexAPI/configure' did not have execute permissions: corrected
C:\Users\RHARRIS>R CMD INSTALL --build --no-multiarch .\cplexAPI_1.4.0.tar.gz
* installing to library 'C:/Users/RHARRIS/Documents/R/win-library/4.0'
* installing *source* package 'cplexAPI' ...
** package 'cplexAPI' successfully unpacked and MD5 sums checked
** using staged installation
Warning in system("sh ./configure.win") : 'sh' not found
ERROR: configuration failed for package 'cplexAPI'
* removing 'C:/Users/RHARRIS/Documents/R/win-library/4.0/cplexAPI'
It seems I have an error in the configure.win file, however I haven't edited it at all after downloading it. When I open it up its a blank file, I'm not sure if thats what I'm supposed to be.
If anyone has any insight to offer here it's be much appreciated.
Looking at this error message "'sh' not found" I suspect you should install cygwin so that the install can use the BourneShell.
If this fails, I guess you can contact the author of the package https://www.th-koeln.de/personen/gabriel.gelius-dietrich/.
Cheers,

"The process cannot access the file 'Default.rd.xml' because it is being used by another process." on AppVeyor CI

I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.

Teamcity - Octopus: Packages not found

I have quite a complex TeamCity-Solution.
Configuration "tcBuild" builds and creates nuget-packages, as well as it modifies the version number of the assembly.
Configuration "tcDeploy" depends on "tcBuild", takes the nuget-packages and send it using octopus.
tcBuild just works fine and also creates the wanted packages.
tcDeploy throws the following error for each package:
2014-01-28 14:50:05.5826 ERROR Unable to download package:
Octopus.Platform.Deployment.ControlledFailureException: Could not find package Packagename 1.1.0.903 in feed: 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/'
at Octopus.Shared.Packages.PackageDownloader.FindPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 155
at Octopus.Shared.Packages.PackageDownloader.AttemptToFindAndDownloadPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log, String cacheDirectory, IPackage& downloadedPackage, String& path) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 130
at Octopus.Shared.Packages.PackageDownloader.AttemptToDownload(PackageMetadata metadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 89
2014-01-28 14:50:05.5826 ERROR Error in DownloadAndPushToTentaclesOrchestrator-OCw-lDdz+eWP#SQ-PESY0002-F9FA8F1A while receiving bedf70c1-1f30-496f-91ca-aba6cc956042
(where "packagename" is the name of the package)
The version number of the error message is the same as of the nuget packages' "core-properties"-folder.
Other, quite similar builds on that machine work just fine. Tell me if I need to provide more information.
You can try to create one tc project to package which triggers another project to deploy. We ended up with this approach so that we can deploy the latest build to octopus. Good luck.

Resources