I've created an offline repository for RHEL 6.2. I put a bunch of packages in a group called JARSS. I made a file in /etc/yum.repos.d called jarss-amg-3.0.repo. Here it is:
[jarss-amg-3.0]
name=<<omitted>>
baseurl=file:///usr/local/install/rpmbuild/
enabled=1
gpgcheck=0
I performed a yum clean all to put this in the metadata. Now, here comes the strange part. I can individually install packages with the command yum install package, but yum groupinstall group doesn't work.
I get the following error:
Error Downloading Packages:
package error [Errno 256] No more mirrors to try.
Which doesn't make sense to me because it should be on the local disk. Is this a bug in the yum software? I find it hard to believe that it can install individual packages from the disk but not a group.
EDIT
Here is my comps.xml file:
<comps>
<group>
<id>JARSS</id>
<name>JARSS</name>
<default>true</default>
<description>Default 3rd Party Software needed for JARSS installation</description>
<uservisible>true</uservisible>
<packagelist>
<packagereq type="default">ace-tao-amg</packagereq>
<packagereq type="default">opendds-amg</packagereq>
<packagereq type="default">imlib2</packagereq>
<packagereq type="default">imlib2-devel</packagereq>
<packagereq type="default">lct</packagereq>
<packagereq type="default">xerces-c</packagereq>
<packagereq type="default">xerces-c-devel</packagereq>
<packagereq type="default">xmlrpc-c</packagereq>
<packagereq type="default">xsd</packagereq>
<packagereq type="default">atlas</packagereq>
<packagereq type="default">atlas-devel</packagereq>
<packagereq type="default">blas</packagereq>
<packagereq type="default">blas-devel</packagereq>
<packagereq type="default">cppunit</packagereq>
<packagereq type="default">cppunit-devel</packagereq>
<packagereq type="default">lapack</packagereq>
<packagereq type="default">lapack-devel</packagereq>
</packagelist>
</group>
</comps>
And here is the ls command in the local directory:
atlas-3.8.4-2.el6.x86_64.rpm
atlas-devel-3.8.4-2.el6.x86_64.rpm
blas-3.2.1-4.el6.x86_64.rpm
blas-devel-3.2.1-4.el6.x86_64.rpm
cmake-2.8.7-1.el6.rfb.x86_64.rpm
comps.xml
cppunit-1.12.1-3.1.el6.x86_64.rpm
cppunit-devel-1.12.1-3.1.el6.x86_64.rpm
createrepo-0.4.10-1.el5.rf.noarch.rpm
curl-7.19.7-26.el6.x86_64.rpm
expat-2.0.1-9.1.el6.x86_64.rpm
fltk-1.1.7-2.el5.rf.x86_64.rpm
fltk-devel-1.1.7-2.el5.rf.x86_64.rpm
fox-1.6.33-1.el5.rf.x86_64.rpm
fox-devel-1.6.33-1.el5.rf.x86_64.rpm
ftgl-2.1.3-0.3.rc5.el5.x86_64.rpm
ftgl-devel-2.1.3-0.3.rc5.el5.x86_64.rpm
giblib-1.2.4-1.el5.rf.x86_64.rpm
giblib-devel-1.2.4-1.el5.rf.x86_64.rpm
giblib-devel-1.2.4-1.el6.rf.x86_64.rpm
graphviz-2.28.0-1.el5.x86_64.rpm
imlib2-1.4.4-1.el6.rf.x86_64.rpm
imlib2-devel-1.4.4-1.el6.rf.x86_64.rpm
jdk-7u5-linux-x64.rpm
lapack-3.2.1-4.el6.x86_64.rpm
lapack-devel-3.2.1-4.el6.x86_64.rpm
opendds-amg-3.4.1-1.x86_64.rpm
plib-1.8.4-8.el5.kb.x86_64.rpm
plib-devel-1.8.4-8.el5.kb.x86_64.rpm
README
remove-native-display-driver-amg-3.0-1.x86_64.rpm
repodata
rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
useradd-amg-3.0-1.x86_64.rpm
wxGTK-2.8.9-1.el5.rf.x86_64.rpm
wxGTK-devel-2.8.9-1.el5.rf.x86_64.rpm
xerces-c-2.7.0-1.el5.rf.x86_64.rpm
xerces-c-devel-2.7.0-1.el5.rf.x86_64.rpm
xmlrpc-c-1.06.18-1.el5.kb.x86_64.rpm
xsd-3.3.0-1.x86_64.rpm
EDIT 2
The createrepo command: createrepo -g comps.xml .
Ok, I figured it out.
Some of my RPMs in my repository were checked into subversion. Some were not, like the large ones.
Since I didn't want to create a repo with svn metadata inside of it, I did an svn export first. Since some of the rpms were not in svn, they were not copied by the svn export command.
When I created the repo, I was attempting to group rpms that were not present, hence the error.
Related
I want to create a yum repository from my Artifactory URL where I have various rpm packages available.
I created .repo file as below in /etc/yum.repos.d
[customrepo]
name=CustomRepository
baseurl=https://jfrogurl/postgres/13.01.0000
enabled=1
gpgcheck=0
After this when I type yum list I get the following error:
Error: Failed to download metadata for repo 'customrepo': repomd.xml parser error: Parse error at line: 32 (Opening and ending tag mismatch: meta line 0 and head)
Am I missing anything?
You need to make sure that the baseurl in yum.repos.d points to the path which contains the Yum repository metadata files.
From your question it looks like you are pointing to postgres/13.01.0000. You need to make sure that this path contains the metadata files.
By default the metadata is stored relative to the repository's root folder. In this case, Artifactory searches the entire repository for RPMs and saves the repodata directory at $REPO-KEY/repodata. You can control this behavior by configuring the RPM Metadata Folder Depth parameter.
We have a distributed subsystem consisting of multiple components, each component is deployed in it's own RPM package onto various different RHEL/CentOS environments. For example the components might be called:
JL_batman,
JL_superman, and
JL_wonderwoman.
And they are deployed as follows:
host1:
JL_batman
JL_wonderwoman
host2:
JL_superman
We do periodic system releases and also maintenance releases. So the initial few System Releases might look like this:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm
So in each System Release not all packages are updated. Currently we use symbolic links on the YUM repo for the packages that are not updated between releases:
SR1:
JL_batman-1.0-hg123.rpm
JL_superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm
SR2:
JL_batman-2.0-hg137.rpm
JL_superman-2.7-hg651.rpm --> ../SR1/superman-2.7-hg651.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
SR3:
JL_batman-2.0-hg137.rpm --> ../SR2/batman-2.0-hg137.rpm
JL_superman-2.8-hg655.rpm
JL_wonderwoman-1.1-hg101.rpm --> ..SR1/wonderwoman-1.1-hg101.rpm
Each release directory (SR1, SR2, SR3, ...) is a YUM repository. We also use symlinks to link to the following rolling repositories:
JL-old-stable --> SR1
JL-stable --> SR2
JL-testing --> SR3
This is all managed on the YUM repo server using some home grown scripts to pull packages from Jenkins and put them into the JL-testing repo (replacing any old versions there). When SR3 testing is complete and it is promoted to stable, we jiggle the symlinks as follows:
JL-old-stable --> SR2
JL-stable --> SR3
JL-testing --> SR4
Each production environment has the yum .repo file installed for JL-old-stable.repo and JL-stable.repo. Test environments also have a JL-testing.repo file. Then yum upgrade 'JL_*' is used on each environment to keep it up to date. Works OK but has some issues, mainly:
When SR3 is promoted to stable, but we need to rollback to SR2 we need to use something like yum --disablerepo='JL-*' --enablerepo='JL-old-stable' downgrade 'JL-*'.
There is no way to easily rollback from SR3 (stable) to SR1 apart from installing a new JL-SR1.repo file and then using yum --disablerepo='JL-*' --enablerepo='JL-SR1' downgrade 'JL-*'.
Is there a better way?
I would instead use a single RPM that provides no files, but Requires the various other packages with exact versioning. The "Version" of each of the config RPMs is just the release number.
OurConfig_SR_1.noarch requires:
JL_batman = 1.0
JL_superman = 2.7
JL_wonderwoman = 1.1
OurConfig_SR_2.noarch requires:
JL_batman = 2.0
JL_superman = 2.7
JL_wonderwoman = 1.1
Then you can have them all in a single repo and versionlock the OurConfig on the machine until you're ready to move it. A quick check with rpm -qi OurConfig can tell you what that system expects. Requiring the exact versions should stop an SR1 system from automatically upgrading JL_batman to 2.0 (I didn't test this of course!).
How do I install Helm (https://hackage.haskell.org/package/helm) on Windows 7 (64-bit)?
(Update: I had posted a lot of error messages here, but I've moved them to my answer to not clutter up the question.)
Installation for Windows 64-bit:
I'm including error messages, for if you follow all the steps up to that point and then just try to install directly. This is a conglomeration of a bunch of ad-hoc steps from following many different posts. Any simplification would be appreciated!
Note: Do all work in directories without spaces. I'm doing all work in C:/PF; modify this to your directory.
Download MSYS2-x86_64 from https://msys2.github.io/ and install it. Cabal install cairo (or helm) will give something like:
Configuring cairo-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
Missing C libraries: z, cairo, z, gobject-2.0, ffi, pixman-1, fontconfig,
expat, freetype, iconv, expat, freetype, z, bz2, harfbuzz, glib-2.0, intl,
ws2_32, ole32, winmm, shlwapi, intl, png16, z
Download C libraries. In MINGW64 (NOT MSYS2 - I had trouble with MSYS2 at random stages in the process), use the package manager:
pacman -Ss cairo
to search for the Cairo package. You'll find "mingw64/mingw-w64-x86_64-cairo", so install that:
pacman -S mingw64/mingw-w64-x86_64-cairo
*.pc files should have been added to C:\PF\msys64\mingw64\lib\pkgconfig and C:\PF\msys64\usr\lib\pkgconfig. (pkg-config needs to be able to find these files. It looks in PKG_CONFIG_PATH, which by default should have the lib/pkgconfig folder above. Moving the file here is easiest. See Can't install sdl2 via cabal) If you get
The pkg-config package ... version ... cannot be found
errors then check your *.pc files.
Repeat with other required libraries, like atk
pacman -S mingw64/mingw-w64-x86_64-atk
(I don't know the complete list, but error messages later on will let you know what to get.)
Get the development files for these libraries (as suggested by How to install cairo on Windows). Most of them are bundled up at http://ftp.gnome.org/pub/gnome/binaries/win64/gtk+/2.22/. Unzip.
Copy files (.a, .dll.a) in lib to C:\PF\msys64\mingw64\lib. Copy the pkgconfig folder, which contains the .pc files.
Copy files in include to C:\PF\msys64\mingw64\include.
Add C:\PF\gtk+-2.22.1\bin to the path.
(2) and (3) might be redundant. I don't know - I did them both.
At this point you can probably do "cabal install cairo". (Warning: if your end goal is something else, you may not want to "cabal install" intermediate packages, see https://wiki.haskell.org/Cabal/Survival#Issue_.232_--_Not_installing_all_the_packages_in_one_go.)
See (4) for the syntax in specifying extra-include-dirs and extra-lib-dirs (but if you copied the files above this shouldn't be necessary),
Any time you get
Missing (or bad) header file
check to see you copied the *.h files to mingw64\include and/or add the include folder to the PATH. Use cabal install -v3 to get verbose error messages if the problem persists.
If you get something like
cairo-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
try --ghc-pkg-options="--force" (as mentioned at https://github.com/gtk2hs/gtk2hs/issues/139).
Get SDL. Otherwise you'll get
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5.1
Follow the instructions in (2) to get sdl/sdl2 libraries. (See instructions here Installing SDL on Windows for Haskell (GHC).)
The new version helm-0.7.1 requires sdl2, but there are other dependency issues with helm-0.7.1 as of writing. Download SDL from http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/ (direct download link to newest version as of writing http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-SDL-1.2.15-7-any.pkg.tar.xz.sig/download), unzip. "cabal install sdl" gives
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
so we specify where the dirs are (change the name depending on where you extracted sdl to)
cabal install sdl --extra-include-dirs=C:/PF/sdl\include --extra-lib-dirs=C:/sdl/lib
If you got SDL2 (http://libsdl.org/download-2.0.php) (for a newer version of Helm): there is a fatal bug that hasn't been fixed in the release version. (If you don't fix it, cabal install -v3 things which depends on it will give error
winapifamily.h: No such file or directory
("winapifamily.h: No such file or directory" when compiling SDL in Code::Blocks) Download https://hg.libsdl.org/SDL/raw-file/e217ed463f25/include/SDL_platform.h, replace the file in the include folder and in C:/PF/msys64/mingw64/include/SDL2.
Download gtk2hs from http://code.haskell.org/gtk2hs and run
the following
cd gtk2hs/tools
cabal install
cd ../glib
cabal install
cd ../gio
cabal install
cd ../pango
cabal install --ghc-pkg-options="--force"
(Maybe you have already installed glib and gio from before? I did this step because normal install of Pango caused an error for me (https://github.com/gtk2hs/gtk2hs/issues/110)
pango-0.13.1.0: include-dirs: /mingw64/include/freetype2 is a relative path
which makes no sense (as there is nothing for it to be relative to). You can
make paths relative to the package database itself by using ${pkgroot}. (use
--force to override)
Once the Helm developers get things updated you should be able to do "cabal install helm" but right now there seem to be dependency issues. For me, cabal automatically tries to install helm-0.4 (probably because 0.4 didn't give upper bounds on dependencies, while newer versions do. You could try "cabal unpack"ing and deleting the upper bounds...). Then
cabal unpack helm-0.4
Installing gives an error because "pure" got moved to Prelude. Open helm-0.4\src\FRP\Helm\Automaton.hs and change line 17:
import Prelude hiding (id, (.), pure)
Now
cabal install
Try to compile and run a program using Helm
(This is 0.4 - look on the website for a newer sample if you tried a newer Helm)
import FRP.Helm
import qualified FRP.Helm.Window as Window
render :: (Int, Int) -> Element
render (w, h) = collage w h [filled red $ rect (fromIntegral w) (fromIntegral h)]
main :: IO ()
main = run $ fmap (fmap render) Window.dimensions
If you get an error about a missing .dll (sdl.dll), find it in a bin/ folder and add the folder to your PATH (or copy it to somewhere on your path).
When I try to install a package through raco, I get a strange error message:
raco setup: directory: #<path:/Users/ben/code/racket/benchmark/tr-pfds/pfds> does not exist for collection: "pfds"
Even stranger, running raco pkg show doesn't show anything about this "pfds" collection:
Installation-wide:
Package Checksum Source
main-distribution f07e2d4bf2708c1085be38eca18aa9eb6755e547 (catalog main-distribution)
racket-lib 41c7b3221006758c5a840a18dcc0d265632f14c2 (catalog racket-lib)
[178 auto-installed packages not shown]
User-specific for installation "6.1":
Package Checksum Source
benchmark 1237b50804bb42bd242ba7b3eb6e2b98794b40ee (catalog benchmark)
feature-profile 109e89701839a6d2fed9d1713aef8d21cc8b54d4 (catalog feature-profile)
quickcheck 1afac87825c5da8b35b327f5df3f1f9e1bf3cb9d (catalog quickcheck)
rackunit-chk 9c6e9c346c0e83bd3bb8dd16e321a2fa3e02b42e (catalog rackunit-chk)
Another thing I tried was just removing the "pfds" collection, but that didn't go well either:
raco6.1 pkg remove pfds
Removing pfds
raco6.1 pkg remove: package not currently installed
package: pfds
current scope: user
But in retrospect this error makes sense to me, because the directory /Users/ben/code/racket/benchmark/tr-pfds/pfds doesn't exist on my machine. I deleted it a few weeks ago.
Does anyone know what's going on?
Have you used raco link in the past? You can sometimes see this error message if you have raco linked a directory that you have since deleted.
There are three things you can try:
Run raco link --repair. This should ideally repair your installation by removing all dead links.
Run raco link -r pkfds, this should remove your pfds link.
Check your links.rktd file, which can be found in:
(Linux) ~/.racket/<version>/links.rktd
(OS X) ~/Library/Racket/<version>/links.rktd
(Windows) C:\Users\<username>\AppData\Roaming\Racket\<version>\links.rktd
In the file, you may see a link to pfds, which is causing the issue.
Once the link is removed, raco setup should work normally again.
(As an addendum, it might be interesting to note that raco link has an API call from within Racket.)
I do
> chocolatey.bat install -force PowerTab
Chocolatey (v0.9.8.23) is installing 'PowerTab' and dependencies. By installing you accept the license for 'PowerTab' an
d each dependency you are installing.
______ powertab v0.99.6 ______
Downloading powertab 64 bit (http://powertab.codeplex.com/downloads/get/159925) to C:\Users\phelan\AppData\Local\Temp\ch
ocolatey\powertab\powertabInstall.zip
Extracting C:\Users\phelan\AppData\Local\Temp\chocolatey\powertab\powertabInstall.zip to C:\Windows\SysWOW64\WindowsPowe
rShell\v1.0\Modules...
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules
powertab has finished successfully! The chocolatey gods have answered your request!
Finished installing 'PowerTab' and dependencies - if errors not shown in console, none detected. Check log for errors if
unsure.
Reading environment variables from registry. Please wait... Done.
C:\Users\phelan\workspace\weincad.net [master]
>
and the directory it tries to put stuff into is
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules
which can't be correct as it is neither on $env:PSModule path and I don't have permission to write there. I can't find any information in chocolately on where it really should be installing the modules.
It is possible to look "inside" every Chocolatey package using the Nuget Package Explorer in order to see "what is going on". If you do this for the PowerTab package, you will see the following:
$name = 'powertab'
$url = 'http://powertab.codeplex.com/downloads/get/159925'
$target = Join-Path $PSHOME 'Modules'
Install-ChocolateyZipPackage $name $url $target
As you can see, the author of this package has chosen specifically to unzip the package to the location that you have mentioned, it is not something that Chocolatey is doing out of the box.
Since each package is contributed by the community, the best suggestion would be to use the "Contact Maintainers" link on this page:
PowerTab Package on Chocolatey.org
to ask the creator of the package directly.
Hope that helps!
Gary