headers
thomas | 27 Jun 22:51
Gravatar

RELEASE: Mach 0.9.5 'MMM...'

mach - make a chroot - RELEASE NOTES
------------------------------------

Announcing the release of mach 0.9.5 - MMM...

WHAT IS IT
----------
mach allows you to set up clean roots from scratch for any distribution or 
distribution variation supported.

This clean build root can be used to run jailed services, create disk images,
or build clean packages.

mach can currently set up roots for the following distributions:
- Fedora 7, 8, 9   (Fedora, Everything, updated, rpm.livna.org,
         10, 11     JPackage, FreshRPMS, GStreamer)
         devel
- Fedora 4, 5, 6   (core, updated, extras, rpm.livna.org,
                    JPackage, FreshRPMS, GStreamer)
- Fedora 1, 2, 3   (core, updated, www.fedora.us, rpm.livna.org,
                    JPackage, FreshRPMS, GStreamer)
- Red Hat 8.0, 9   (basic, updated, www.fedora.us, rpm.livna.org,
                    JPackage, GStreamer, FreshRPMS)
- Red Hat 7.2, 7.3 (basic, updated, FreshRPMS, JPackage)
- Red Hat 7.0, 7.1 (basic, updated, FreshRPMS)
- CentOS 4, 5
- SuSE 8.1/8.2/9
- OpenSuSE 10.2/10.3/11.0
- Yellowdog Linux 3.0 (basic, updated, FreshRPMS)
- Yellowdog Linux 2.3 (basic, updated, FreshRPMS)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Panu Matilainen | 17 Oct 12:52
Picon
Favicon

Attention: rpm-list moves


Hello all,

As RPM is used by wide variety of distributions, hosting the generic RPM 
users' discussion list at redhat.com is not the most appropriate place. To 
address this historical leftover, this list moves now to the vendor 
independent upstream location at rpm.org.

Current subscribers will NOT be automatically subscribed to the new list to let 
everyone adjust their mail filters and subscribe to the new address at their 
discretion.

To subscribe to the new list, either go to 
http://lists.rpm.org/mailman/listinfo/rpm-list or send (an empty) mail to 
rpm-list-subscribe <at> lists.rpm.org

Archives of this list will remain in place but otherwise the 
rpm-list <at> redhat.com list is closed, effective immediately.

Apologies for the disruption, and hope to see you on the new list to 
continue discussion regarding questions about and use of rpm.org releases.

 	- Panu -
Permalink | Reply | 0 comments |
headers
Frost, Jere | 14 Oct 23:39
Picon
Favicon

Spec file question


Hello all,

I have little experience with RPM/spec files but trying to help a fellow worker.   We have an an RPM meta
package (task-compat-vcd_fw_ipg_ins_ics_ics) that we want to install RHEL 32bit packages on RHEL
64bit systems via yum for compatibility purposes.

In the spec file, we specify "Requires: PackageName(s).i386"  for each 32 bit package we want to install
(e.g. "ImageMagick-c++-devel.i386").

When trying to install the RPM metapackage via yum, we get an error for each line "requires
PackageName.i386"  e.g.:

Error: Missing Dependency: ImageMagick-c++-devel.i386 is needed by package task-compat-vcd_fw_ipg_ins_ics_ics

How do we specify PackageName(s).i386 in our spec file so Yum will install the i386 version?

yum list | grep ImageMagick-c++-devel
ImageMagick-c++-devel.x86_64             6.2.8.0-3.el5.4        installed
ImageMagick-c++-devel.i386               6.2.8.0-3.el5.4        RedHat-5.1Server

"yum install ImageMagick-c++-devel.i386" works fine on the 64 bit systems.

See spec file below.

Thanks in advance....

--jere

------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Pawson | 12 Oct 12:23
Picon
Gravatar

rpmbuild questions

New to rpm's in general. I'm trying to help out with Klavaro,
currently about 4 versions behind
the Sourceforge version. FC9 has 1.1

$ rpm -qa klavaro
klavaro-1.0.1-1.el5.rf.i386

current version is 1.1.6

I've attempted a spec file, from the sources at
http://klavaro.sourceforge.net/en/
and it seems to be partially working.

I'm stuck on debugging it though.

I've built /usr/src/redhat/RPMS/i386/klavaro-debuginfo-1.1.6-1.fc9.i386.rpm

Questions.

How to find out if this is up to standard?
How to properly test it please?
I'm running FC9 on an i386 arch (I think!)

spec file below

%define version 1.1.6
%define dist
%define _tmppath /tmp
%define release 1
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael A. Peters | 10 Oct 11:05
Picon

Leaving a file behind

Is there some attr I can set in %files that tells rpm to leave a 
particular file behind when removing the package?
Permalink | Reply | 3 comments |
headers
Lev Lvovsky | 8 Oct 01:17

signing RPMs without a passphrase?

Is it possible to sign an RPM without being asked the passphrase for  
the signing key?  It hampers automated RPM creation to be asked for  
the passphrase when building them.  Otherwise, is the only other  
option just batch signing the RPMs after they've been created?

thanks,
-lev
Permalink | Reply | 10 comments |
headers
Feng Li Wang | 29 Sep 22:01
Picon
Favicon

Peter Wang will be out of office from Sep 29 to Oct 5, urgent contact 13911309718

I will be out of the office starting 2008-09-28 and will not return until 2008-10-06.

Peter Wang will be out of office from Sep 29 to Oct 5. Urgent contact 13911309718

_______________________________________________
Rpm-list mailing list
Rpm-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list
Permalink | Reply | 0 comments |
headers
Chinnakka K Batakurki | 29 Sep 16:32
Picon

Chinnakka K Batakurki is out of the office.

I will be out of the office starting  29/09/2008 and will not return until
06/10/2008.

kindly expect a delay in response
Thanks!
Permalink | Reply | 0 comments |
headers
Adrián Márques | 26 Sep 21:55
Picon
Favicon

Issues when updating running apps?

Hello all,

I have a very basic question I hope someone can help me with.

I'm not sure on how to package an application so that updating it while 
it's running won't cause any problems. For instance, I'm packaging a 
quite typical java app that has a swing GUI and stores its data in a 
database. In the event of an update requiring modifications to the 
database schema I had thought of including these in the %pre or %post 
sections, but I assume this could lead to the app breaking to pieces if 
the old version is running when the changes meant for the newer version 
are made. A similar problem could occur if I update some jar and the 
running app happens to load some classes from it that won't work 
properly with the older version. Am I making any sense with this?

How can I get around these issues? are there other I should look out for 
that I'm not considering?

I'd highly appreciate any advice/tips/links you could give me.

Regards.

Adrián.
Permalink | Reply | 4 comments |
headers
Adrián Márques | 24 Sep 20:54
Picon
Favicon

Didactic spec file suggestions?

Hi all,

I'm just starting with RPM packaging. I've been reading around a lot and 
everyone recommends learning from working spec files of other projects. 
I've also read comments about how it is not uncommon to find 'bad rpm 
practices' in some of these.
Right now I'm checking out spec files at random from JPackage (I have to 
package a java app).

Do any of you have suggestions on what freely-available spec files are 
worth checking out for a newcomer? The most valuable for me would be 
those that illustrate how to do key elements of packaging 'the right 
way'. Right now I'm particularly interested in how to list files and 
what logic (not)to put in the %pre, %post, %preun, and %postun scripts, 
but I'm sure other things will come up soon enough.

I'd highly appreciate any suggestions; even more so if you could also 
mention why you deem those spec files to be important or which aspects 
of them are relevant in particular.

Thank you all.

Adrián
Permalink | Reply | 2 comments |
headers
Adrián Márques | 24 Sep 20:28
Picon
Favicon

Files listed twice question

Hi there,

I'm an absolute newbie trying to package an application with RPM for the 
first time and would like to mark some files as config files.
The top directory of this aplication has several files and directories, 
only two of which hold config files. Thus, I'm doing something like this 
in my spec file:

%files
/usr/local/myAppTopDir/
%config /usr/local/myAppTopDir/configDir1/*
%config /usr/local/myAppTopDir/configDir2/*

Obviously, this generates several 'file listed twice' warnings. However, 
I queried the generated rpm and didn't find anything wrong with it. All 
config files where included and correctly marked as config files.

So my questions are: can I safely ignore these warnings or listing files 
twice like I have causes a problem I'm not seeing now? is there a better 
way to do what I want?

I have been looking through the list archives so I know many of you 
would advice me to explicitly list all files. I know this would take 
care of this particular problem, but I don't want to do that unless I 
really have to, since I find globbing significantly more practical in 
this case.

I thank you already for taking the time to read this.

Regards.

Adrián.
Permalink | Reply | 11 comments |

Gmane