Sponsored Content
The Lounge What is on Your Mind? VBulletin 3.8 to Discourse on Docker Migration Test Take Two Post 303045264 by Neo on Saturday 14th of March 2020 09:42:07 PM
Old 03-14-2020
This is the end of test build 2 (and 3).

Now that I have most of the general bugs worked out; and I'm convinced this migration will work, I will setup another server and start new test build 4 from scratch.

Now waiting for DNS to sync / propagate to new server IP address.

Will start new thread for test build 4 soon.
 

7 More Discussions You Might Find Interesting

1. Web Development

Removing VBSEO for vbulletin – Reverting back to vbulletin URLs

Please note, this information was copied from vbseo.com, now showing a database error. This is posted for reference since vbSEO seems to be going out of business: If you ever need to uninstall vBSEO , you can use the following instructions. Make sure you carefully follow each step. Login... (37 Replies)
Discussion started by: Neo
37 Replies

2. Linux

Docker and pipework,ip with other subnet

Recently i found this for give to docker a "personal" ip ip addr del 10.1.1.133/24 dev eth0 ip link add link eth0 dev eth0m type macvlan mode bridge ip link set eth0m up ip addr add 10.1.1.133/24 dev eth0m route add default gw 10.1.1.1On container i did ... (0 Replies)
Discussion started by: Linusolaradm1
0 Replies

3. AIX

AIX - FC Switch migration, SAN Migration question!

I'm New to AIX / VIOS We're doing a FC switch cutover on an ibm device, connected via SAN. How do I tell if one path to my remote disk is lost? (aix lvm) How do I tell when my link is down on my HBA port? Appreciate your help, very much! (4 Replies)
Discussion started by: BG_JrAdmin
4 Replies

4. Shell Programming and Scripting

Problem in extracting yocto SDK for docker

Actually I was facing the following issue while building my Yocto SDK on Docker container sudo docker build --tag="akash/eclipse-che:6.5.0-1" --tag="akash/eclipse-che:latest" /home/akash/dockerimage.yocto.support/ Sending build context to Docker daemon 26.93MB Step 1/5 : FROM eclipse/cpp_gcc ... (3 Replies)
Discussion started by: Akash BHardwaj
3 Replies

5. UNIX for Beginners Questions & Answers

Can't pass a variable representing the output of lsb_release to a docker dontainer

I don't know why, but the rendering of my code mucks up the spacing and indentation, despite being correct in the original file. I'm having issues getting the following script to run (specifically the nested script at the end of the docker command near the end of the script; I think I'm not passing... (2 Replies)
Discussion started by: James Ray
2 Replies

6. Docker

Docker learning Phase-I

Hello All, I had recently learnt a bit of Docker(which provides containerization process). Here are some of my learning points from it. Let us start first with very basic question: What is Docker: Docker is a platform for sysadmins and developers to DEPLOY, DEVELOP and RUN applications ... (7 Replies)
Discussion started by: RavinderSingh13
7 Replies

7. What is on Your Mind?

Under Consideration: Migrate the Forums to Discourse

Dear All, After being active on the Node-RED forum for the last few weeks, I have been very impressed with Discourse, and my eyes have been opened. https://www.discourse.org/ but not the paid /hosted offering, but using the open distribution: https://github.com/discourse/discourse ... (52 Replies)
Discussion started by: Neo
52 Replies
build(1)						      General Commands Manual							  build(1)

NAME
build - build SuSE Linux RPMs in a chroot environment SYNOPSIS
build [--clean|--no-init] [--rpms path1:path2:...] [--arch arch1:arch2:...] [--root buildroot] [specfile|srcrpm] build --help build --verify DESCRIPTION
build is a tool to build SuSE Linux RPMs in a safe and clean way. build will install a minimal SuSE Linux as build system into some direc- tory and will chroot to this system to compile the package. This way you don't risk to corrupt your working system (due to a broken spec file for example), even if the package does not use BuildRoot. build searches the spec file for a BuildRequires: line; if such a line is found, all the specified rpms are installed. Otherwise a selec- tion of default packages are used. Note that build doesn't automatically resolve missing dependencies, so the specified rpms have to be sufficient for the build. If a spec file is specified on the command line, build will use this file and all other files in the directory for building the package. If a srcrpm is specified, build automatically unpacks it for the build. If neither is given, build will use all the specfiles in the current directory. OPTIONS
--clean remove the build system and reinitialize it from scratch. --no-init skip the build system initialization and start with build immediately. --list-state list rpms that would be used to create a fresh build root. Does not create the build root or perform a build. --rpms path1:path2:path3... Where build can find the SuSE Linux RPMs needed to create the build system. This option overrides the BUILD_RPMS environment vari- able. --arch arch1:arch2:arch3... What architectures to select from the RPMs. build automatically sets this to a sensible value for your host if you don't specify this option. --root buildroot Specifies where the build system is set up. Overrides the BUILD_ROOT enviroment variable. --useusedforbuild Tell build not to do dependency expansion, but to extract the list of packages to install from "# usedforbuild" lines or, if none are found, from all "BuildRequires" lines. This option is useful if you want to re-build a package from a srcrpm with exactly the same packages used for the srcrpm build. --norootforbuild --help Print a short help text. --verify verify the files in an existing build system. .spec FILE OPTIONS The build command interprets some special control comments in the specfile: # norootforbuild # needsrootforbuild build uses either user root or user abuild in the build system to do the build. For non-SUSE distros as well as since SUSE 10.2, the default build user is abuild. For 10.2 and before, the default build user is root. These two flags in the spec file allow to deviate from the defaults and force-set the build user to abuild and root (for # norootforbuild and # needsrootforbuild respec- tively. # needsbinariesforbuild provide the binary rpms that have been used to set up the build root in /.build.binaries within the build root. ENVIRONMENT
BUILD_ROOT The directory where build should install the chrooted build system. "/var/tmp/build-root" is used by default. BUILD_RPMS Where build can find the SuSE Linux RPMs. build needs them to create the build system. "/media/dvd/suse" is the default value which will do the trick if you have the SuSE Linux DVD mounted. BUILD_RPM_BUILD_STAGE The rpm build stage (-ba, -bb, ...). This is just passed through to rpm, check the rpm manpage for a complete list and descrip- tions. "-ba" is the default. You can use this to add more options to RPM. SEE ALSO
rpm(1), Maximum RPM: http://www.rpm.org/max-rpm/ cross distribution packaging: http://en.opensuse.org/Build_Service/cross_distribution_package_how_to SUSE packaging standards and guidelines: http://en.opensuse.org/Packaging (c) 1997-2008 SuSE Linux AG Nuernberg, Germany build(1)
All times are GMT -4. The time now is 01:07 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy