I am trying to install the libguestfs package for golang but couldn't find the way to do so. I went through this but it didn't work for me and I believe it's empty. I see only test files here
Following is the content of the README
$GOPATH
-------
http://golang.org/doc/code.html
Note that $GOPATH is set (by the ./run script) to the
libguestfs/golang directory so that "installs" happen in the local
build tree.
From this I could figure out that I need to build the package but again for that, I couldn't find some help or proper document.
Is there any way to do the installation? I am using RHEL 7.7
Libguestfs (the C library) is packaged already in RHEL 7, so I would suggest first of all installing that using yum install libguestfs. That's the version that Red Hat supports.
We don't ship the golang bindings, not even in RHEL 8. Furthermore the bindings in all languages are generated from a mechanical description of the API and thus not stored directly inside our git repository. That's why you could only find test files in git.
However we do distribute the generated files in the tarballs, so an easy way is to grab the latest tarball from https://download.libguestfs.org/1.42-stable/ and look in the golang/src/libguestfs.org/guestfs subdirectory of the tarball.
The harder way is to generate them from git. These steps worked for me on RHEL 7.7, YMMV:
sudo yum-builddep libguestfs
git clone https://github.com/libguestfs/libguestfs
cd libguestfs
git submodule init
git submodule update
./bootstrap
./autogen.sh SUPERMIN=/usr/bin/supermin5
make
and again look in the golang/ subdirectory.
I'm reasonably sure that golang bindings from one version should work with another version of the C library. We did test this at one point in time, so if it's no longer true then it may have regressed as these things sometimes do.
So i'm pretty new to the whole windows repo cloning thing. I installed python 2.7, added the path to my windows cmd and I still cannot run any git clone commands. It shows the following output :
git clone
File "", line 1
git clone
^
I've been scouring the internet for an answer but apparently it should work if I use cmd.
Any help would be appreciated!
git clone
File "", line 1
git clone
^
I have had the same issue recently with 3.7, so I made a new username and it worked. Kind of nice, a clean new Windows profile, even though I just started using it again compared to linux. A pain though.
Make sure all other versions of Python are not installed, or at least affecting the path to the file you need the pip installs to be saved. Python can be saved in a few different locations, and some rare times it has been shown in very obscure places. Check where your file saved on your PC. Probablu C:/ then could be many paths. /Users/UnserNameHere/Windows/ProgramFiles. I would use the search bar in the good old GUI while searching under the C drive (if you have multiple HDD/SDD then pic the one used for the C drive, if nothing comes up try the other drives.
Your looking for a file PythonFoundation I can't remember the entire name, however it will have a very long name Python Foundation are in the name of the file. This is where thing are store and where the path should be sending modules, at least the correct file inside that file.
Also try doing it from other Python versions installed. If you had 3.6 and got 3.7 it doesn't mean 3.6 has been deleted. Also doesn't mean you path, is not set to 3.6 while using 3.7. Same with Python 2, most people or many have both. The pip commands vary between python versions pip3 I believe is used (getting windows and linux a little mixed up right now)
If all fails do it the old fashon way, find the mod, download it, and move it to the python file I mentioned above. The homepage for python should have a tab linking to a page, or it's on the main page, letting you know where it has been known to save. Google how to see he path Pip is taking, or how to see if pip is installed and where, and what paths are set to.
I am on a Mac OS X Mojave. From the command line, I want to access a private repo (which I do not own but have access to) located at
https://github.com/<ORG_NAME>/<PROJECT-NAME>
By "access," I mean that I only need to download the project directory to my local machine. I only need the files and directory structure. I do not need to checkout the repo or get the .git history.
How can I do this from the command line?
This question is different because it deals with the scenario where I own the repo. Which I don't. Also that question uses the clone command. And I don't need a clone to checkout or the git history. I just need a copy of the files as previously stated.
This answer suggests the following.
git clone https://<username>:<password>#github.com/<ORG_NAME>/<PROJECT-NAME>.git
But they said you need to enter info at the prompt. I would like to avoid entering info at the prompt because this is part of a larger automation routine I'm making. So I'd like to have the command line instructions self-contained.
Edit: I also found this additional information, but I still can't figure it out from there.
Sorry if this isn't the place for this, I don't know where else I'd ask.
For Mac OSX El Capitan
I am trying to edit the property _staticHtmlFileExts
The variable used to be defined in src/file/FileUtils.js, but has since been moved to src/LiveDevelopment/LiveDevelopmentUtils.js.
When I go to Show Developer Tools within Brackets, I can view the sources, and very easily find /LiveDevelopment/ (and the child JS file)...
But any changes I make to the file are not saves on the system, and thus do not persist on successive opens of the Brackets app.
When I try to find the same file on my system, it is nowhere to be found...
I have hidden folders set to display (which they all do, when present), so I do not believe this to be the issue.
How come I can view the files in the Dev Tools, but not on my system? How, or where, can I make the change permanently?
The build installed with the Brackets.dmg installed minified, concatenated source file (main.js under ~/Application/Brackets.app/Contents/www/) along with a source map, which is why you can see the sources in developer tools, but you cannot see the original source files.
See the article How to hack on Brackets for instructions on setting up a development environment if you want to modify the files themselves.
For reference, the steps are as follows:
Install the latest Brackets build (this gives you the native shell binaries which you'll use in step 6)
Fork the brackets repo
Clone your fork of the repo: git clone https://github.com/<username>/brackets
Fetch submodules: cd brackets && git submodule update --init
Add an "upstream" remote: git remote add upstream https://github.com/adobe/brackets
Run setup_for_hacking script with tools/setup_for_hacking.sh "/Applications/Brackets.app"
Note that the steps 2 and 3 are optional if you are just making modifications for yourself. If so, you can just clone straight from the master (git clone https://github.com/adobe/brackets).
I have a very very large svn repo. When I try to use it (commit, update, etc.) it says there are locks.
When I run 'svn cleanup', it says that the working copy is too old and I need to upgrade it.
When I run 'svn upgrade', it runs, but doesn't say anything.
I also ran 'svnadmin upgrade' on the repo, just in case.
I have the latest TortoiseSVN installed.
Normally, if I had SVN weirdness, I'd move the files out, update, move the files back, but as I mentioned earlier, this is a very LARGE repo.
Any help would be appreciated.
Thanks!
Specific messages:
>svn update
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy '*****' locked.
svn: E155004: '*****' is already locked.
>svn cleanup
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '*****' is too old (format 29) to work with client version '1.8.1 (r1503906)' (expects format 31). You need to upgrade the working copy first.
>svn upgrade
>
Update 1:
I installed a 1.7.X client and tried to run a cleanup. It complained that the repo wasn't a working copy, for some reason. I tried an update with the same 1.7.X client and got the following message:
>"c:\Program Files\SlikSvn\bin\svn.exe" update
svn: E155021: This client is too old to work with the working copy at '*****' (format 31).
You need to get a newer Subversion client. For more details, see http://subversion.apache.org/faq.html#working-copy-format-change
So, this client things the repo is format 31. The tortoisesvn thinks it is format 29. Now I'm more confused.
Update 2:
Response to #David W
Is this about a working copy or the repository?
Working copy. Though I tried svnadmin upgrade on the repo as well. However, the svnadmin I used was the 1.8.1. I just tried to upgrade the repo with the TortoiseSVN one (1.8.10), but that didn't fix the issue.
is this about a file that's locked because someone locked it, or because your working directory is locked due to an incomplete
I'm the only one using the repo, so I know no one else locked it. Its probably due to an incomplete op.
I ran svn status with 1.8.10, and nothing had a 'K'. There were some files with an 'L', and one with a '?'. All items listed were directories, not files, with the exception of the one marked with a '?'.
If I ran an 'svn lock --force dirname', it would respond that that specific node "is not a file". When I ran it on the file marked with a '?', it responded that that node 'was not found'.
Then, there is a locked working directory because of an incomplete operation...
Yep, you called it. That is why all the things are marked with an 'L', I gather.
When I ran a cleanup (1.8.10) it gave me the same error I reported in my intiial question (format 29 too old for this format 31 client).
Remember that you can always delete a working directory and create a new one
Yep. If I delete any directory in the working copy and hit update, it complains that it is locked. I can't clear the lock, 'cause of the format mismatch. I can theoretically just re-checkout the entire repo, then copy things back, but the repo is 12GB (210,000 files).
Be careful about mixing up Subversion clients
So, I was unaware that I had two clients, but I only only only use TortoiseSVN (1.8.10). I only discovered today that I had two when I was trying to troubleshoot.
* UPDATE 3: RESOLUTION *
Using #David W's tips, here is how I fixed the problem:
1) Backed up my .svn folder
2) Downloaded an SQLite editor from https://github.com/sqlitebrowser/sqlitebrowser/releases
3) Opened up my wc.db file and browsed the WC_LOCK table. There was 1 entry in that table, which I removed.
4) Tried running a cleanup using TortoiseSVN (1.8.10), which previously complained about locks. It finally worked!
5) Tried running commands in my repo (update, commit, etc.), and everything was happy.
Thank you to everyone who helped, especially #David W for not giving up on me.
I have a very very large svn repo. When I try to use it (commit, update, etc.) it says there are locks.
Is this about a working copy or the repository? Two different things. Also, is this about a file that's locked because someone locked it, or because your working directory is locked due to an incomplete
You can have a lock on a file that prevents you from doing a commit. From the command line, you can do a svn status and see the K next to the locked file. You can then use svn lock --force to steal that lock, and check in your changes. (As long as there's no hook in the repository that prevents you from stealing locks).
Then, there is a locked working directory because of an incomplete operation. In this case, you'll see an L when you do a svn status. In that case, you can usually do a svn cleanup in the root directory of that working copy (Where the .svn folder is located.)
Remember that you can always delete a working directory and create a new one. Be careful about mixing up Subversion clients. At one time, it didn't seem to matter that much, but in Revision 1.6, 1.7, 1.8, and 1.9, the structure of the working copy has changed and may not be compatible with clients running other revisions.
Update 2
Yep. If I delete any directory in the working copy and hit update, it complains that it is locked. I can't clear the lock, 'cause of the format mismatch. I can theoretically just re-checkout the entire repo, then copy things back, but the repo is 12GB (210,000 files).
Deleting a directory and then doing a svn up doesn't clean up the lock issue. I meant to delete the entire working directory, and redoing a svn co. You don't have to checkout the entire repo. You only have to check out what you need. Do you need all 210 thousand files? I doubt it:
$ svn co http://server/repo # NOOOO!
$ svn co http://server/repo/trunk # A bit better, but do you need all
# the projects under Trunk?
$ svn co http://server/repo/trunk/foo # Now, I'm just checking out foo
$ svn co http://server/repo/trunk/bar # Now, I'm just checking out bar
This checks out two working directories: One for foo and one for bar.
If you really, really want to checkout the entire trunk, use the --depth to sparsely checkout what you need:
# Checking out trunk, but only getting the project directories
$ svn co http://server/repo/trunk --depth=immediates
$ svn up --set-depth=infinity foo
$ svn up --set-depth=infinity bar
Here I am in theory checking out the entire trunk, but I'm only getting empty master project directories. I am only getting files from projectsfoo and bar. However, foo and bar share a working directory. Let's say I start a long update on foo, then I go to bar and try to commit. I'll get a warning that the working directory is locked. I can't do two separate Subversion commands on the same working directory even if they are in different sections of that working directory.
So, I was unaware that I had two clients, but I only only only use TortoiseSVN (1.8.10). I only discovered today that I had two when I was trying to troubleshoot.
If you install Tortoise, you can also install the Subversion command line client which is an optional install. I highly recommend it! Don't use a command line client downloaded from elsewhere (like SlikSVN or CollabeNet. It's not that these clients are bad. It's that you should use the command line client that comes with your version of TortoiseSVN in order to guarantee some parity between the two Subversion clients.
Cleanup vs. Upgrade vs. Svnadmin
It's very easy to get these confused. You shouldn't be using svnadmin commands on your working directory. The svnadmin is for the server. The issue you have is strictly client.
As Subversion moved from 1.6 to 1.7 to 1.8 and now to 1.9, the upgrade will upgrade your working directory to the new format. Once done, you cannot go back to the older format. You upgrade to the 1.8 format, 1.7 and 1.6 clients will no longer work.
Cleanup is to help remove locks due to incomplete Subversion client commands.