Clean build RPM with mock as like git-buildpackage — mkouhei's blog
Clean build RPM with mock as like git-buildpackage DebianパッケージのビルドシステムはTrustyでJenkinsとpbuilder & cowbuilder & git-buildpackage を使って実装している、という話を 7月のDebian勉強会 でお話しました。 一方、RPMについては、2年ほど前にFlaskとCouchDBで実装したパッケージ管理システムを作成しました。Webブラウザ経由でRPMbブラウザでアップロードすると、ローカルリポジトリに登録されるようなシロモノです。個人的にはRPM使わないのでまぁ良いのですけど、ブラウザ経由でアップロードとか面倒ですね。 1 また、Upstreamが配布しているRPMはまだしも、カスタムパッケージの場合、Debianパッケージでのpbuilderなどのように、mockでクリーン
革命の日々！ おまえら rpmdev-setuptree を使えという話
いままで、rpmbuildするときに mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} して、 echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros とかやってたんだけど、それはもう古いらしい。 % yum install rpmdevtools % rpmdev-setuptree すると、上記の両方をやってくれるのに加えて .rpmmacrosに並列処理設定を追加してくれる。 こんな感じ %_topdir %(echo $HOME)/rpmbuild %_smp_mflags %( \ [ -z "$RPM_BUILD_NCPUS" ] \\\ && RPM_BUILD_NCPUS="`/usr/bin/nproc 2>/dev/null || \\\ /u
RHEL 5 と KMP (Kernel Module Package) - daily dayflower
カーネルのバージョンが上がる度にカーネルモジュールもビルドしなきゃいけない，というのはめんどくさい。 しかも。 バイナリパッケージでカーネルモジュールをインストールしているとする。 このカーネルモジュールがシステム動作の上で必須だとすると，新しいカーネル（本体）がリリースされても，それに対応するバージョンのカーネルモジュールがリリースされない限り新しいカーネルにアップデートすることができない。 これは不便。そして危険。 なので，RHEL 5 から KMP (Kernel Module Package) という新しいカーネルモジュールのパッケージング方式がでてきた。 たとえば，centosplus のバイナリパッケージ（IIJ さんのミラー）で XFS のカーネルモジュールのパッケージを見ると， kmod-xfs-0.4-1.2.6.18_92.1.1.el5.centos.plus.i68
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
第8回 CentOS6でのRPMパッケージを用いた MySQL 5.6 & mroonga & PHP 5.4 環境の作り方 | gihyo.jp
例えばPHP 5.4.xとMySQL 5.6.x環境を用意する際、mysqlndが採用できれば後述の手順において、PHPのRPMパッケージ作成は省略可能です。つまり、mroongaのRPMパッケージ作成のみで導入できます。しかし事情により、mysqlndが使えず従来のlibmysqlclientが必要な環境の場合には、PHP・mroongaそれぞれのRPMパッケージを後述する手順で作成します。なお、iusの提供するmysql56u-develパッケージにはmroongaのビルドに必要なlibmysqlservices.aが不足しているため、オラクル公式のRPMパッケージを利用して紹介します。 Remiリポジトリ・IUSリポジトリのインストールについては、公式サイトが参考になります。 Remiリポジトリ : http://rpms.famillecollet.com/ IUSリポジトリ :
yumによるRHELの保守的パッチ適用方法 - めもめも
何の話かというと Red Hat Networkに登録したRHELシステムであれば、 # yum updateとすれば、すべてのパッケージが自動的に最新にアップデートされます。あるいは、 # yum install hogehogeとすれば、hogehogeの最新バージョンと依存パッケージがまとめてインストールされます。 しかしながら、場合によっては、特定のパッケージだけ特定のバージョンに上げたい、とか、いきなりインストールするのではなくて、まずはRPMファイルをダウンロードして、根掘り葉掘り調べてからインストールしたい、という場合もあります。 このような際に、yumを使わずに、Red HatのCustomer Portalから個別にRPMをダウンロードして対応している方も多いと思いますが、実は、yumでもそのようなきめ細かな対応は可能です。特に、EC2/Nifty Cloudなどで時間課
RPM パッケージを Git で管理する方法（案） - Gosuke Miyashita
@trombik さんの 弊社ではtinderbox+gitですべて統一させてる — trombik (@trombik) December 27, 2012 という tweet を見て気になったので調べてみたところ、 Tinderbox はどうやら FreeBSD の ports を自動ビルドするためのシステムのようで、RPM でもこんなのないのかなー、と探してみたものの見つけられなかったし、Tinderbox が自分が求めてるものなのかどうかもいまいちピンと来なかったので、プロトタイプ的なものをつくってみることに。 現在 RPM パッケージの管理は、こんな感じで ソース/バイナリパッケージを直接リポジトリに突っ込んじゃってるんだけど、これだと以下のような問題がある。 バイナリパッケージのファイルサイズが大きすぎて、git clone や push や pull に時間がかかる パッケー
Jenkinsを用いた継続的RPMビルド - GeekFactory
RHEL系を使っていて、yumで取得できないバージョンのパッケージを使いたい場合、一般に以下の選択肢があります： 他ディストリビューションのSRPMをビルドしてRPMを生成する。 配布元のtar ballをビルドしてRPMを生成する。 配布元のtar ballを /usr/local 等にインストールする。 Gentooに乗り換える。 このようなケースでは、パッケージのライフサイクルに合わせて誰がどのように運用していくか、担当者の頭を悩ませることになります。構築手順が後で分からなくなると悲惨です。そのための対策として、構築手順書を用意したり、バージョンアップ用のスクリプトを書いたりすると思います。 本稿では、対策の一つとしてJenkinsによる自動化を考えてみます。ワンクリックのRPMビルドが可能になることで、yumのようなきめ細かいバージョンアップも現実的になります。また、運用担当者の負
nginxでLDAP認証を使う - GeekFactory
Webアプリや共有フォルダなどの認証を必要とする場面が増えてくると、ユーザ管理のコストが無視できなくなります。Active DirectoryやLDAPでIDを統合すると、運用者はユーザ管理が楽になり、利用者はシングルサインオンで快適になります。たとえ自分しか使わない環境であっても、一括でパスワード変更できたり、簡単に認証を設定できるメリットは大きいでしょう。多くのアプリがLDAP認証に対応しています。 この記事ではnginxでLDAP認証を使う方法を説明します。.htpasswdによる認証とは異なり、IDとパスワードはWebサーバでは管理しません。LDAPサーバのリポジトリで管理します。 今回は以下のミドルウェアを使いました。 Amazon Linux 2011.9 OpenLDAP 2.4.23 nginx 1.0.12 nginx-auth-ldap LDAPを準備する OpenLD
cat_in_136.blog(): rpmbuild setting for multi core CPU
rpmbuild setting for multi core CPU rpmbuild(8) is a command to build a RPM file (binary software package.) Usually rpmbuild's build process is running with only one CPU. But it is possible to run with more than one CPU. To run with more than one CPU, edit ~/.rpmmacros and add: %__make /usr/bin/make -j 6 Specify -j 6 if you have a hexa-core CPU. Specify -j 4 if dual-core. See also PackagerDocs/Mac
RPMパッケージ作成メモ
一覧するには、rpmbuildコマンドの--showrcオプションで可能です。 _docdir マクロ定義に_docdirはないが、specファイルで_docdirを使用しているものがあります。_docdirは実行時に確定するマクロで、事前に定義されているマクロ_defaultdocdirが適用されるようです。 descriptionセクション パッケージ内容を詳細に記述するセクションです。 %description The xyz utilities are used for software development activities. The main activities are in construction and unit testing. : %description -l ja XYZユーティリティは、ソフトウェア開発作業に役立つツールを収めています。 特に、ソフトウェ
いまさら聞けないrpmbuildことはじめ - hack in 3 minutes
CentOSなどrpmを使っているシステムで、欲しいツールのrpmが見つからない、使いたいツールのバージョンが古いときに、rpmbuildを使って望みのrpmを作成することが出来ます。 ウェブを探せば色々と情報はあるんですが、ざっとスタートするときに必要な流れをまとめて書いてみることにしました。 専用のビルド環境 専用の環境を準備た方が吉です。centXbuildXXみたいな名前でVMを作ってます。 cent4build32.tnmt.local cent5build64.tnmt.local とか。 パッケージの依存性もあるので、あまりサードパーティのyumリポジトリなどを追加しないか、実環境と同じリポジトリのみ有効にするとよいです。複数サービスがあったらそれごとにVMを作るのもありかと思います。 必要なパッケージ類のインストール rpmbulidに必要なパッケージ類をインストールします
再インストールせずにFedoraを32ビット版から64ビット版にアップグレード | OSDN Magazine
Linuxのすばらしい点の1つは、32ビットのAMD XPプロセッサ搭載マシンから64ビットのIntel Core 2マシンにハードディスクを移設しても、Linux環境がそのまま動作することだ。ただし、この場合、プロセッサは64ビットコードに対応していても、32ビットのカーネル、Cライブラリ、システム環境一式を実行することになる。また、新しいマシンに4GB以上のメモリがあっても、その一部は利用されないか、32ビットのPAE（Physical Address Extension）カーネルを実行するかのどちらかとなり、せっかくのリソースが無駄になってしまう。だが、Linuxディストリビューションを64ビット版にクロスグレードすれば、リソースをもっと賢く活用することができる。 私が使ってきたのはFedoraで、すでに64ビット版への移行を決心していた。もう何年もLinuxのカンファレンスでFed
RPM REFERENCE: spec ファイルで使用できるタグ/マクロ/環境変数一覧
前のページ 次のページ 目次 1. spec ファイルで使用できるタグ/マクロ/環境変数一覧 索引(アルファベット順) AutoProv AutoReq AutoReqProv BuildArchitectures BuildRoot BuildConflicts: BuildRequires: Conflicts Copyright Distribution DocDir ExcludeArch ExcludeOS ExclusiveArch ExclusiveOS Group Icon Name NoPatch NoSource Obsoletes Packager Patch Prefix Prefixes PreReq Provides Release Requires Serial Source Summary URL Vendor Version
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Feature: 8 Cores on a Budget- Building a Better Workstation - Linux.com