I need to build Thunderbird from this archive: archive.mozilla.org/pub/thunderbird/releases/102.5.1 (I don't need the latest version!).
I put the code from the archive in my own git repository.
It was possible to build for Linux.
But I can't build for Windows, it crashes with this error (mach bootstrap):
checking for a shell... C:/mozilla-build/msys2/usr/bin/sh.exe
checking for host system type... x86_64-pc-mingw32
Installing bootstrapped toolchain in C:/Users/r/.mozbuild/node
ERROR!!!!!! Could not find artifacts for a toolchain build named `toolchain-win64-node`. Local commits, dirty/stale files, and other changes in your checkout may cause this error. Make sure you are on a fresh, current checkout of mozilla-central. Beware that commands like `mach bootstrap` and `mach artifact` are unlikely to work on any versions of the code besides recent revisions of mozilla-central.
Hint: consider reverting your local changes to the following files: ['python/mach/mach/site.py', 'python/mozboot/mozboot/bootstrap.py', 'python/mozversioncontrol/mozversioncontrol/__init__.py']
ERROR: Command '['C:\\Users\\r\\.mozbuild\\srcdirs\\desktopmail-f3ac63904a51\\_virtualenvs\\mach\\Scripts\\python.exe', 'C:/Users//Desktop/DesktopMail/mach', '--log-no-times', 'artifact', 'toolchain', '--from-build', 'toolchain-win64-node']' returned non-zero exit status 1.
ERROR: If you can't fix the above, retry with --disable-bootstrap.
Full log output (pastebin)
Is it possible to disable checking for the latest changes in the repository?
To check the functionality of the assembly, I downloaded the original repository hg.mozilla.org/mozilla-central. It was successfully built on Windows. But why can't the version from the archive be assembled?
I tried to fix the python assembly script to remove the check for recent changes. But this mechanism is strongly integrated into the entire assembly, cutting it out is very long and meaningless.
Related
So I've installed svn2git using Ruby on Windows. Unfortunately, since git has made the change of Master branch to Main, this has broken the script. I've found the script in
C:\Ruby27-x64\lib\ruby\gems\2.7.0\gems\svn2git-2.4.0
and made the required modifications. How do I recompile / remake this so that when I run svn2git on the command line it uses my modified script?
since git has made the change of Master branch to Main, this has broken the script
I'm not sure what you mean by "broken"; perhaps you needed to rename master-->main here? (Or even better, you could make it somehow configurable, not hardcoded?)
How do I recompile / remake
This is ruby. It's an interpreted language; you don't need to compile anything.
It would be "bad practice" to edit the gem directly on your machine, but this should still work. If you run svn2git on the command line right now, then - assuming that's the correct installation (e.g. you don't also have a ruby 2.6 version installed that's getting picked up?!), it should run your modified code instead.
But for a "better" long-term solution, it would be advisable to fork the project, make your change, and install your own version of the project.
You could also open a pull request with your change, in case the original author is still active and willing to release an update.
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.
First, a little bit of background as to why I'm asking this question: Our product's daily build script (as run under Debian Linux by Jenkins), does roughly this:
Creates and enters a build environment using debootstrap and chroot
Checks out our codebase (including some 3rd party libraries) from SVN
Runs configure and make as necessary to build all of the code
Packages up the results into an install file that can be uploaded to our headless server boxes using our install tool.
This mostly works fine, but every so often (maybe one daily build out of 10), the part of the script that builds one of our third-party libraries will error out with an error like this one:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/root/software/3rdparty/libogg/missing autoconf
/root/software/3rdparty/libogg/missing: line 81: autoconf: command not found
WARNING: 'autoconf' is missing on your system.
You should only need it if you modified 'configure.ac',
or m4 files included by it.
The 'autoconf' program is part of the GNU Autoconf package:
<http://www.gnu.org/software/autoconf/>
It also requires GNU m4 and Perl in order to run:
<http://www.gnu.org/software/m4/>
<http://www.perl.org/>
make: *** [configure] Error 127
As far as I can tell, this happens occasionally because the timestamps of the files in the third-party library are different (e.g. off by a second or two from each other just due to the timing of when they were checked out from the SVN server during that particular build). That causes the configure script to think that it needs to auto-regenerate a file, so then it tries to call 'automake' to do so, and errors out because automake is not installed.
Of course the obvious thing to do here would be to install automake in the build environment, but the build environment is not one that I can easily modify (due to institutional reasons), so I'd like to avoid having to do that if possible. What I'd like to do instead is figure out how to get the configure scripts (which I can modify) to ignore the timestamps and just always do the basic build that they do when the timestamps are equal.
I tried to finesse the problem by manually running 'touch' on some files to force their timestamps to be the same, and that seemed to make the problem occur less often, but it still happens:
./configure --prefix="$PREFIX" --disable-shared --enable-static && \
touch config* aclocal* Makefile* && \
make clean && make install ) || Failure "libogg"
Can anyone familiar with how automake works supply some advice on how I might make the "configure" calls in our daily build work more reliably, without modifying the build environment?
You could try forcing SVN to use commit times on checkout on your Jenkins server. These commit times can also be set in SVN if they don't work out for some reason. You could use touch -d or touch -r instead of just touch to avoid race conditions there.
I want to compile and run a specific version of a FreeBSD utility from the source code.
For example, I downloaded the repo for the following utility: https://svnweb.freebsd.org/base/stable/9/sbin/routed/
However, when I run the make command, I get the following error:
"../Makefile.inc", line 3: Cannot open ../Makefile.inc
make: fatal errors encountered -- cannot continue
*** [all] Error code 1
Can someone point me in the right direction?
You will need to download the whole source tree. The build system depends on pieces from different locations in the tree. Then;
Unpack the source in /usr/src
cd /usr/src/sbin/routed
make && make install
It looks like you want the 9-stable branch? If you have subversion available, you can do:
rm -rf /usr/src/
svn co svn://svn.freebsd.org/base/stable/9 /usr/src
(Depending on your FreeBSD version, svn may also be called svnlite) Also see the handbook.
On my machine, the complete /usr/src tree is 2445 MiB, including the .svn directory.
Edit: Note that it a program relies on system calls, library functions or other features that were introduced in a certain branch/version of FreeBSD, it will not work on older branches/versions.
I am getting below error when taking checkout from svn using a script.
**[Test] $ /bin/sh -xe /tmp/hudson8576425899836211909.sh
+ sh /cvsrx/rxapp/build_dir/Jenkins_Scripts/test.sh
Could not load program svn:
Could not load module /opt/freeware/lib/libssl.so.
Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded.
Member libcrypto.so.1.0.1 is not found in archive
Could not load module svn.
Dependent module /opt/freeware/lib/libssl.so could not be loaded.
Could not load module .
Build step 'Execute shell' marked build as failure
Finished: FAILURE**
In test.sh I have written just one line svn co /path to svn branch/
I am in middle of some test so please don't ask why am not using jenkins in build svn plugin.
here,I am able to take checkout on command prompt using svn co /path to svn branch/
But not if I write this command line in script and run in execute shell of jenkins.
Any help please ?
Am using jenkins on AIX 7 platform.
I had softlinks from /usr/bin/svn to /opt/freeware/bin/svn.SVN installed at /opt/freeware/bin/svn ..... By default when i do which svn its showing /usr/bin/svnBut When i deleted those softlinks and exported path,Jenkins didnt recognize SVN at all.And which svn command doesnot show any svn installed . PFB logs of jenkins :
`
/bin/sh -xe /tmp/hudson5607872610124977868.sh
+ export PATH=/opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin:/
+ echo /opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin:/opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin
+ cd /usr/local/apps/Jenkins_new/scripts
+ ./test.sh
Could not load program /opt/freeware/bin/svn:
Could not load module /opt/freeware/lib/libssl.so.
Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded.
Member libcrypto.so.1.0.1 is not found in archive
Could not load module svn.
Dependent module /opt/freeware/lib/libssl.so could not be loaded.
Could not load module .
./test.sh[3]: svn: not found
Build step 'Execute shell' marked build as failure
Finished: FAILURE`
ReInstalling Jenkins solved my problem !! It was due to corrupt plugin which happened due to server restart.
Thanks Everyone
I have not seen the exact command of svn you have used in test.sh, but would advice you to give full path of SVN in your calling line, eg /usr/bin/svn co .....
And if also possible make an entry in your test.sh for export PATH and export LD_LIBRARY_PATH setting them to values which are paths of the mentioned .so files
I see you're using Hudson/Jenkins. Hudson and Jenkins use SVNKit internally when checking stuff in and out of Subversion. This means that the command line svn client may not be installed on your system, or that it may have other problems.
It is also possible that there are multiple svn clients on your system. For example, you may have one under /usr/bin/svn and one under /usr/local/bin/svn. If Subversion is working from the command line, but not in the script, you may have a different $PATH setup when you're executing from the command line vs. the script from Hudson/Jenkins. You can add to your script (if it's BASH) the line type svn to see where your executing svn from. It may be different from what you are using from the command line. It may also be nice to print out $PATH as part of your script.
It would also be helpful to see the svn command that your script is executing, and tell us what you're trying to do. You can also add to your script the following lines:
PS4="\$LINE: "
set -xv
These lines will turn on shell script debugging, and help you locate where your script is having problems.
This will give you some clues as to what is going wrong in your script.
Reply
Thanks David. Here only 1 svn path exists (usr/bin/svn)but created as a softlink see -->cd /usr/bin/svn lrwxrwxrwx 1 root system 26 Jul 1 14:34 svn -> ../../opt/freeware/bin/svn. Also soflink of libs.so is created see --> lrwxrwxrwx 1 root system 15 Sep 13 18:15 libssl.so -> libssl.so.1.0.1 .......... Is it possible that softlink is creating these problems ?? Before requesting to remove these softlinks ,i need confirmation that these softlinks are creating problems.
Softlinking isn't unusual for Unix. For example, I have Ant, Grails, Maven, Subversion, and many other packages installed under /opt on my Mac. In order not to have to include each and every one of these in my path, I soft link all of the binaries for those programs under /usr/local/bin. About 80% of the programs under /usr/local/bin are merely soft links elsewhere.
Library soft links are also very common. This usually has to do with version numbering. When a program requests a library, it may or may not include the library's version number. So, you have libfoo-2.0.3.so on your drive. This is the actual version of foo. However, few programs will request that particular version. Instead, they may simply request they need Version #2 of foo or just say they need to link to foo.
To handle this, you will have libfoo2.0.3.so soft linked to libfoo-2.so for programs that specify they need version 2 of foo. Then, libfoo-2.so will be soft linked to libfoo.so. This way, libfoo will be called no matter what. If I install, libfoo2.0.4.so, I can change the link to libfoo-2.so to point to version 2.0.4 instead of version 2.0.3, and anything that depends upon Foo will be picking up the correct version.
Instead, let's look at the error message:
Could not load module /opt/freeware/lib/libssl.so.
Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded.
Member libcrypto.so.1.0.1 is not found in archive
For some reason, it couldn't access the file /usr/lib/libcryto.a. Is this file on you machine? Is it in /usr/lib? If not, where is it located?
So, where did you get this version of Subversion from? Why is the link to the /opt/freeware/bin/ directory? Was this part of your system?
It could be that Subversion on your system is not complete and never did work. In Jenkins, the Subversion repository is accessed by the SVNKit Jarfile which is embedded inside Jenkins/Hudson itself, so it wouldn't really be a surprise to find that the Subversion binary didn't work.
Are you able to do anything with Subversion from the command line? If not, you may have to install a new version of Subversion from Perzl which is where CollabNet points to for an AIX version of Subversion. (It's at least up to date at version 1.8.4).
You may even want to change the soft link at /usr/bin/svn to point to the newer, working version of Subversion.