I recently upgraded my base system and now gpg with version 2.1.x is in use. Unfortunately it does not read my old keyrings any more.
As I see from here the gpg system should convert it automatically, however this is not happening in my Ubuntu. How can the old format converted then manually?
Somehow there was a migration happening in the past already, so there existed following file already: .gpg-v21-migrated. But the new gpg version could not read or find any migrated files. So I removed the file and the keyrings got reimported:
rm ~/.gnupg/.gpg-v21-migrated
Related
I have a little problem while I want to update my package. I'll explain this: I published my package. After that, I waited for 2-3 hours for my packages be in the microsoft/winget-pkgs in GitHub. My branch merged successfully, It works on any Windows devices but, I created a new version of my application: v3.6.2. The version that I released it was v3.5.7. So now, I can't publish that version because this error is showing when I execute this cmd command: wingetcreate update <packageIdentifier> -u https://github.com/YourUsername/yourrepository/releases/download/3.6.2/yourapp.exe --version 3.6.2 -t ghp_YourGithubPersonalAccessTokenWith_public_repo_setting.
If you want an image, i'll show you the image (My Windows is French btw): Here the image. But as you can see, the red is the error and I tried everything, I searched on Google and didn't find anything that fixed my problem, I tried the examples showed above when you only execute this command: wingetcreate.exe update but still the same error message that you can see on the image.
So I decided to take the third example but same, without success. Is there a way that could update my WinGet package? Thanks!
I don't know if this could help but I can give you some info: it's inno, the achitecture is Neutral.
IMPORTANT NOTE:
FIX HERE
The last answer works but if you type the command winget search <YourApp>, it will keep the previous version and if you install, it would install the previous one... How to fix that because it is litteraly NOT updating but doing nothing.
It's hard for me to know exactly what the issue is without knowing the contents of the manifest or the metadata of the installer. My gut feeling is that there is an architecture mismatch when trying to match the installer you provided with the existing installer that is currently specified in the existing manifest. To override the detected architecture you can use the '|' symbol followed by the desired architecture. Here is an example:
wingetcreate update <packageIdentifier> -u "https://github.com/YourUsername/yourrepository/releases/download/3.6.2/yourapp.exe|x64" --version 3.6.2 -t <githubToken>
If that doesn't work for you, I would encourage you to post an issue on the GitHub repository so we can help you further.
Okay, I found the way: You take the code that the previous answer contains, and add -s:
wingetcreate update -s <packageIdentifier> -u "https://github.com/YourUsername/yourrepository/releases/download/3.6.2/yourapp.exe|x64" --version 3.6.2 -t <githubToken>
It will publish the application on GitHub for verification, in the command prompt you put (replace the sentence in the quotes with your current manifest file):
winget validate --manifest "PathToYourManifestShowedInGreenAfterPublishing"
When the validation on GitHub is done, it's done and normally it should work.
NOTE: Verification on GitHub can take 2 to 3 hours or even 4 hours. Be patient! (I hope)
I tried to build Spring from source using: ./gradlew install
It fails with:
/home/dk/.gradle/caches/1.12/scripts/build_68eiq5ktt9740a7l1bofab8a9a/ProjectScript/no_buildscript/classes/build_68eiq5ktt9740a7l1bofab8a9a$_run_closure27_closure138_closure139_closure140_closure141_closure142_closure143_closure144_closure146_closure147.class (File name too long)
This was reported earlier but should have been fixed in Gradle 0.9.1. However I still have this error with Gradle 1.12. I'm using Ubuntu 14.04 with an ext4 filesystem.
What's the recommend workaround for this?
It seems that this error occurs when using an encrypted home directory. I've set GRADLE_USER_HOME to an unencrypted directory and everything works fine.
The only solutions I'm aware of are to use a filesystem that can handle long filenames, or to ask the Spring folks to change their build script so that it doesn't use such deep nesting levels (10 seems way too much). In any case, this question should be brought to attention of Spring developers (e.g. in their JIRA). I'd be surprised if none of them used Ubuntu/ext4.
I think it is not too late to post it back to this thread. Based on the answer provided by Dennis, Here is what needs to be done to ensure you are able to compile Spring Source on encrypted files system.
$ sudo mkdir /opt/gradle/home
$ sudo chown -R $USER:$USER /opt/gradle/home
$ export GRADLE_USER_HOME=/opt/gradle/home # Probably add it to .zshrc or .bashrc files
Currently I am using cabal-install 1.16.0
I tried to update cabal-install because someone told me that newer version of ghc (7.6.1) is available. Installation result was quite successful except for this message.
Warning: could not create a symlink in /Users/MyName/Library/Haskell/bin
for cabal because the file exists there already but is not managed by cabal.
You can create a symlink for this executable manually if you wish. The
executable file has been installed at
/Users/MyName/Library/Haskell/ghc-7.4.1/lib/cabal-install-1.16.0.2/bin/cabal
I checked those locations and there was files. So installation was ok.
Based on the warning message I got, I tried to create symlinks in /Users/MyName/Library/Haskell/bin by typing this.
ln -s /Users/MyName/Library/Haskell/bin /Users/MyName/Library/Haskell/ghc-7.4.1/lib/cabal-install-1.16.0.2/bin/cabal
but It gives me simple, but frustrating message. "File Exists"
So I tried again, with existing file removed by Finder. (I just move symlink file to recycle bin.) but machine gives me same message. "File Exists"
As a result, I still have installed folder, but not working Cabal, which keep urges me to update. (version 1.16.0)
How can I solve this problem?
I realize this question was asked 6 months ago, I hope you've already found the solution. I'm posting the answer here for future reference.
You were almost there. Removing the existing symlink is the correct first step. The next step is to create the new symlink by doing:
ln -s [actual/path/to/cabal] [name_of_symlink]
You seem to have reversed this order, and this causes the "File Exists" error.
I'm trying to get the Mercurial Eclipse plugin to use my MacPorts version of Mercurial (since I need to access a repo that's using the new dotencode format), but I can't get the Mercurial preference page under "Team" to save the changes. It will recognize "/opt/local/bin" as a valid directory for the "hg" executable, but when exiting the workspace the changes don't appear to be saved properly, since the next time I launch Eclipse, the old "/usr/local/bin" is back there again.
Has anyone else had problems with this? "/opt/local/bin/hg" is a symlink to "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/hg" on my system, but that file also contains a shebang ("#!") with the same path (duh!). Is that known to cause any problems on anyone else's machine?
Edit: Symlinking /usr/local/bin/hg to /opt/local/bin/hg works, but this doesn't fix the cause of the problem.
There are no errors being logged in the Eclipse Error Log view, other than "abort: requirement 'dotencode' not supported!" on startup. I.e. no errors on validating the settings or when saving the workspace.
Do you have another version of hg in /usr/local/bin? If not or if you no longer need it, you might be able to work around the issue by making a symlink:
sudo ln -s /opt/local/bin/hg /usr/local/bin/hg
sudo chmod -h g+rx,o+rx /usr/local/bin/hg
Here's what I did, I have installed svnserve as a service and I started it with the net start svn service command. I typed svn ls svn://localhost to test the service but it returned the error as stated in the title of this post.
I entered svn --version and svnserve --version on my computer to find out the version numbers and the client and the server version is the same, version 1.5.6. I'm guessing the error appears due to different versions of the server and the client.
When I start the server using svnserve --daemon --root command in cmd, The error still appears.
Why does the error appear? Thanks
Which Subverson tool did you use to create the repository? TortoiseSVN? Your TortoiseSVN may be newer, a 1.6.x release, then your 1.5 command line client and svnserve, so svnserve 1.5.x cannot serve a 1.6.x repository.
In my fsfs repository created with svnadmin 1.6.1, the db/format file contains
$ cat repos/db/format
4
layout sharded 1000
I have the same problem but I had resolve it with a different approach
The issue mainly is the db/format file where it expects a "2" best way to check is to ope the file
$ vi db/format
If you get this
4
layout sharded 1000
Then you should change them to say
2
Its better to also check you current file
$ vi db/current
It you get only this (e.g. 0 meaning reviosion number 0)
0
Then you should change them to just say (e.g. 0 meaning revision number append "nx" and also "2" )
0 nx 2
Finally Check also if your directory structure for the revs and revprops is sharded or looks something like this
db/revs/0/0
change it to a non folder structure
db/revs/0
Note: the revision file (e.g. 0) is just inside the revs directory, no more other folder should be there
Same goes with revprops
change
db/revprops/0/0
to
db/revprops/0
I delete my old repository and create a new one using command line -> svnadmin create C:\SvnRepository
*old repository was created by right clicking on the folder and click "Create Repository here"
I installed (the Collabnet install of) SVN 1.5.5 and it was running fine with TortoiseSVN 1.6.1. After upgrading SVN to 1.6.2 I'm getting the same error (Expected fs format between ‘1’ and ‘3’; found format ‘4’) when I try to access it through Trac. This lends credibility to Blair's answer. I'll let you know how I get it running again.
Update: Blair's answer worked for me, too: the message says that an old version of SVN is trying to access the repository, so find it and delete it. The specifics for me were that the error only occurred when I used Trac, so I re-installed Trac on Windows (http://trac.edgewall.org/wiki/TracOnWindows) with the latest installer I could find (svn-python-1.6.1.win32-py2.5.exe) and deleted old eggs from the Python site-packages folder. After a reboot and resync, I was up and running again.
The latest version of Zend Studio (8.x) has an SVN tool which gives the same error about finding format 4, but expecting format 1-3. I had created my repository using CollabNet SVN (about a year ago) and was unable to open the repository from within Zend Studio.
I think the best solution (at least for my case where I want to work with Zend Studio and not fight with it) is to recreate your repository with the old version of SVN. The URL for SVN 1.3 for Windows is:
http://subversion.tigris.org/files/documents/15/32856/svn-1.3.2-setup.exe
After installing this, make sure you are executing the svnadmin.exe and svn.exe in the newly installed version 1.3 directory in case you have already installed CollabNet SVN (which has a default install directory of c:/csvn).
Make sure you are using the correct svnadmin. For example, if you installed VisualSVN, you will need to use the svnadmin located in the bin folder of the installation directory. I had installed the command line version of SVN...and when I used this version of the svnadmin tool, I got the same error.
Thanks, Joe. I had both CollabNet SVN server and VisualSVN installed and was getting errors until I made sure I was using the version of svnadmin that came with VisualSVN (which I had used to create the repositories).
I was able to fix this by updating Subversion on the server. I also made the adjustment on the db file. Then I pushed everything backup onto the server as an overwrite. I actually (on windows) did a checkout locally, then the files that were generated in creating that repo, I edited the db, then grabbed all files and pushed them up to SVN on the server.
That seemed to have done the trick.
well i have also faced the same problem.
just open your svn remote folder you have made.
in your db folder you have format file.
just replace the no. with 1.
if it does not work try 2, and 3.
If you are using VisualSVN server, Make sure your command looks similar as below
Sample Command:
C:\Program Files\VisualSVN Server\bin>svnadmin dump c:\repo > c:\backup\svnbacku
p.dump