I am new to Electron and want to make (at first) a sample javascript change in the Slack Electron app. I am here on a Mac OSX:
/Applications/Slack.app/Contents/Resources
and run the following:
asar extract app.asar ~/Desktop/src
And then without even making a change run:
asar pack ~/Desktop/src app.asar
The "re-packed" file is significantly larger:
-rw-r--r-- 1 oliverwilliams staff 28336486 Apr 21 03:25 app.asar
-rw-r--r-- 1 oliverwilliams staff 8175963 Mar 21 13:26 app.asar.original
and Slack will not start. Reverting back to the original file, Slack runs again.
Obviously I need to crawl before I can walk. What needs to be done here?
Related
I have general.log file in application, I edited file on server manually using vi (without sudo) for some reason and saved file using esc + : + wq
After this logs are not getting written to the general.log
I have checked the permission before and after the edit, its the same
-rw-rw-r-- 1 ubuntu ubuntu 42K Jan 31 08:32 general.log
Anyone know what may be the issue?
Issue resolved by deployment but I'm investigating the cause.
I just created an Ionic app. Now I'm thinking about publishing.
Just a few days coding, but the output distribution is 50MB. Even it's iOS app without the crosswalk.
That's crazy, is that normal? What should I do? Check or config?
Update, the size of www folder:
$ du -h -d 1 www
4.0K www/css
8.0K www/img
48K www/js
14M www/lib
28K www/templates
14M www
Update: I used https://github.com/diegonetto/generator-ionic, works fine.
The default template when starting an Ionic app only contains "www\lib\ionic" when it comes to bower plugins. If you do not use any of the other libraries inside www\lib then it should be safe to delete them.
Update:
The Out-of-the-box gulp task does not clean up your bower folders for you By renaming your .apk's or .ipa-files to .zip it is possible to further analyze whats causing massive file sizes.
I build CI server and use Xcode bot to build my project. I have one question that why the bot take so long to integrate (over 30 minutes). It seems like Xcode bot has to check out all source code to build for each integration. Even my normal build from scratch after cleaning project only takes about 15 minutes. The second integration is just faster than the first time a little bit. I wonder what happens when Xcode bot is integrating. Is it check out new source code for each integration or just update the old source? why it takes so much time?
I had a similar issue. It turned out that the directory name source code was checked out got corrupted on the CI server. I created the Xcode Bot from a project located in MyProject - iOS directory, this information was conveyed to the bot which did not handle spaces properly.
If you look at the log you will see the directory name got escaped into MyProject%20-%20iOS and then again into MyProject%2520-%2520iOS.
Mar 2 10:56:01 [3230] <Info>: Will attempt to update checkout cache for bot
Mar 2 10:56:01 [3230] <Info>: Xcode Source Control Blueprint was valid.
Mar 2 10:56:01 [3230] <Info>: About to update/checkout:
https://ciuser#code-ci.mycompany.com/MyProject Branch: develop into MyProject%20-%20iOS/
Mar 2 10:56:01 [3230] <Warning>: Could not load cached workspace: Error Domain=XCSIntegrationService Code=2 "The repositories have changed since the last integration. Falling back to a clean checkout." UserInfo={NSLocalizedDescription=The repositories have changed since the last integration. Falling back to a clean checkout.}
Mar 2 10:56:01 [3230] <Warning>: An error occurred updating existing checkout: Error Domain=XCSIntegrationService Code=2 "The repositories have changed since the last integration. Falling back to a clean checkout." UserInfo={NSLocalizedDescription=The repositories have changed since the last integration. Falling back to a clean checkout.}
Mar 2 11:04:31 [3230] <Info>: 0.40% Compressing objects: 4% done
Mar 2 11:10:26 [3230] <Info>: Counting objects: 69562, done.
Mar 2 11:10:26 [3230] <Info>: 13.57% Receiving objects: 1,7 MB done
[...cut...]
Mar 2 11:35:45 [3230] <Info>: Completed checkout of:
https://ciuser#code-ci.mycompany.com/MyProject Branch: develop (#24cec9eca484405f7d2819f3652e34f67853b6fe) into MyProject%2520-%2520iOS/
To fix the problem I had to delete the bot, change repository directory name from MyProject - iOS to MyProject and create the bot from scratch.
I have spent days trying to submit my app on the RIM Vendor Portal.
I can build it. I can run it on my device using debugtoken.bar.
When I try to submit it to the Vendor Portal I get the dreaded "Some files are missing signatures" error.
I built my application.bar file (actually named QuoteUnquote.bar), then signed it with:
"C:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-signer" -verbose -cskpass ******** -keystore sigtool.p12 -storepass ******** "C:\work\word\quotes\platform_airplay\build_smartquotes-airplay_vc10\deployments\default\playbook\release\QuoteUnquote.bar" RDK
"C:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-signer" -keystore sigtool.p12 -storepass ******** "C:\work\word\quotes\platform_airplay\build_smartquotes-airplay_vc10\deployments\default\playbook\release\QuoteUnquote.bar" author
I confirm that there are the required five files inside the META-INF folder in the signed .bar file.
When I verify it without the -verbose option, it just says ".bar verified". When I verify it with the -verbose option, the verify tool appears to crash:
C:\work\word\quotes\platform_airplay\PlayBook>"C:\Program Files (x86)\Research In Motion\BlackBerry WebWorks SDK for TabletOS 2.1.0.6\bbwp\blackberry-tablet-sdk\bin\blackberry-signer" -verify -keystore sigtool.p12 -verbose "C:\work\word\quotes\platform_airplay\build_smartquotes-airplay_vc10\deployments\default\playbook\release\QuoteUnquote.bar"
2240 Sat Jun 30 00:31:16 PDT 2012 META-INF/MANIFEST.MF
1287 Sat Jun 30 00:31:16 PDT 2012 META-INF/AUTHOR.SF
710 Sat Jun 30 00:31:16 PDT 2012 META-INF/AUTHOR.EC
1287 Sat Jun 30 00:31:02 PDT 2012 META-INF/RDK.SF
280 Sat Jun 30 00:31:02 PDT 2012 META-INF/RDK.EC
0 Tue Jan 01 00:00:00 PST 1980 META-INF/
0 Tue Jan 01 00:00:00 PST 1980 native/
barsigner error: java.lang.NullPointerException
So that's not very helpful. I don't know if the -verify tool is just flaky, or if some problem with the .bar file is making it crash, or what.
This is all very frustrating because I've successfully signed and submitted .bar files in the past. I don't know what I'm doing differently now.
As I say, I've been stuck on this for days. If you can give me pointers, that would be great. If I can send you my .bar file and you can tell me what's wrong with it, that would be better.
Any help greatly appreciated.
My little hack to get around this was to sign the .bar as usual (RDK and Author) then rename the .bar file to .zip and extract all files into an temporary directory.
Using 7Zip I then RE-ZIP all files using this command:
7z a -tzip <AppName>.bar *.* -r
Which will re-zip all files back and remove the entries for directory names.
Run a verify on it:
blackberry-signer -verbose -verify <AppName>.bar
So long as you properly signed the app, you should see the lovely message:
Info: Bar verified.
Submit it and off you go!
I have figure out what was going on here. The problem is that there are two kinds of .zip files in the world, those where the directories get their own entry in the .zip file's directory, and those where they don't. This is a difficult issue because (as I understand it) most tools for viewing .zip files don't give an indication of whether the directories have their own entries -- they just show the directories using GUI folder icons like in Windows Explorer or whatever.
The solution was given here: http://supportforums.blackberry.com/t5/Native-Development/Error-while-uploading-Invalid-signature-file-digest-for-Manifest/td-p/1623873
It gives a java program to rebuild the .zip from the extracted contents, and using that particular java library to rebuild the .zip does not include the folders as their own entries.
This problem arose for two reasons:
(1) The RIM Vendor Portal submission tool checks to see if each item in the file is properly signed, and it apparently sees those two directory entries in the contents directory and freaks out because they are not signed, hence "Some files (sic) are missing signatures." In fact, it seems like it could just notice that those are zero-length directory entries and that there's nothing to sign anyway, and just let it go. That would avoid the whole mess in the first place.
(2) The Marmalade tool that makes the .bar file creates a zip that includes those directory entries. What's tricky is that, best as I can tell, it doesn't create those entries on everyone's system, just on some. There are other Marmalade users who apparently don't get this problem. I don't know if it has to do with the underlying .zip library that the Marmalade tool is using, whether that's part of the .jdk, part of the python system Marmalade uses, or what. But it definitely seems to behave differently on different systems.
So, both RIM and Marmalade should include information about this. When RIM gives the error that "some items are missing signatures" it should specify that it's these zero-length directory entries that are missing signatures (or it could just not treat it as an error at all, as mentioned above). Marmalade should tell all users who are working on PlayBook submissions about this issue.
Ok don't use this method.... it verifies and allows you to submit BUT on RIM's side they will complain about the fact that you modified the .bar file AFTER it was signed! !
I am trying to setup OpenCV v2.4.1 with FFMPEG v0.11 support on Scientific Linux SL release 5.0 (Boron), and I am running into a problem with a missing file that seems completely undocumented. The error I am getting is as follows:
-- Install configuration: "Release"
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv/cv.h
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv/cxmisc.h
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv/cvwimage.h
-- Up-to-date: /home/s18/s1138832/OpenCV/include/opencv2/opencv.hpp
CMake Error at modules/core/cmake_install.cmake:63 (FILE):
file INSTALL cannot find file
"/home/s18/s1138832/OpenCV/lib/libopencv_core.so.2.4.1" to install.
Call Stack (most recent call first):
modules/cmake_install.cmake:57 (INCLUDE)
cmake_install.cmake:56 (INCLUDE)
I honestly don't know where to begin troubleshooting this at this point. I successfully installed without ffmpeg a few days ago, but now I can't even install with ffmpeg support set to off.
The files that link to the missing library are:
lrwxrwxrwx 1 s1138832 s18 21 Jun 17 18:26 libopencv_core.so -> libopencv_core.so.2.4
lrwxrwxrwx 1 s1138832 s18 23 Jun 17 18:26 libopencv_core.so.2.4 -> libopencv_core.so.2.4.1
Any advice or prods in the right direction would be much appreciated. I would also be happy to provide more info on whatever interesting details I may have omitted.
UPDATES: This website seems to have the same error, but I can't read it and translations patchy - http://www.opencv.org.cn/forum/viewtopic.php?f=1&t=15664 ( http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.opencv.org.cn%2Fforum%2Fviewtopic.php%3Ff%3D1%26t%3D15664&act=url )
libopencv_core.so.2.4.1 exists after "make", but "make install" deletes it somehow. I copied it and added it again, but it didn't change anything
As always, it was something very simple! I had my CMAKE_INSTALL_PREFIX set to "/foo" and I was configuring and building from "/foo" - when I configured from "/foo/temp" everything went swimmingly.
I guess the make install step tries to copy your built files to the install prefix path, and deletes the originals. Obviously this could cause some problems. Works like a charm now.
Thanks to everyone who made suggestions!