firefox-0.8-0.fdr.2.src.rpm mach rebuild help
by Gavin Henry
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I am trying to help test firefox, but I get errors with mach and I wasn't sure
is this should be posted on bugzilla:
checking for c++... no
checking for g++... no
checking for gcc... gcc
checking whether the C++ compiler (gcc -O2 -g -march=i386 -mcpu=i686 )
works... no
configure: error: installation or configuration problem: C++ compiler cannot
create executables.
*** Fix above errors and then restart with "gmake -f client.mk build"
make: *** [/usr/src/rpm/BUILD/mozilla/Makefile] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.83042 (%build)
??? Is this my configuration?
- --
Regards,
Gavin Henry.
Director.
Open Source. Open Solutions.
http://www.suretecsystems.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAKA3OeWseh9tzvqgRApfvAKCDCuhfXuq0+0Uu2invQRLFurrNZQCfTsuh
OOyoZWHWMDiT4M6f9xekbfg=
=sIcC
-----END PGP SIGNATURE-----
20 years, 3 months
Funny bugzilla error when adding myself to CC: list
by Leonard den Ottolander
Hi,
I tried to add myself to the CC: list of bug #53003, as I want to file a
bug report and patch that should close #53003 as duplicate, but I get
the error:
You tried to change the component field from AfterStep-APPS to
initscripts, but only the owner or submitter of the bug, or a
sufficiently empowered user, may change that field.
What's funny about this is that the component is already set to
initscripts.
Bye,
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
20 years, 3 months
RFC: X library package changes, dependancy changes, freedesktop.org xlibs, etc.
by Mike A. Harris
This is a Request For Comments intended to help determine the
best /long term/ solution over time for a problem developers and
rpm packagers will face with multiple alternative X11
implementations being available in RPM packaged format in the
future. This is not intended to be a short term or rushed
solution, but one in which developers will be able to migrate rpm
packages to using over time. It is my hope that the time period
would be short, but it can theoretically be as long as is
necessary, as this is just a discussion for now.
Problem scenario:
Currently, the XFree86 implementation of X11 has all of the
libraries present in the package XFree86-libs, and all of the
necessary development headers are included in XFree86-devel.
All rpm packages containing applications/libs which link to the
standard X11 libraries, currently have hard coded dependancies
such as:
Requires: XFree86-libs
Buildrequires: XFree86-devel
This is suboptimal for packaging however, as it makes a bad
assumption that there is only a single implementation of X11
APIs, and that only this implementation can be used to satisfy
the dependancies of applications needing to link to X libraries.
In order to facilitate alternate X11 implementations, these hard
coded dependancies in RPM spec files need to be changed to be
more generic, rather than implementation specific. This does
pose a rather large problem however, as the entire base of OSS
software rpms out there which link to X libraries pretty much all
assume there is one and only one implementation of X11 which will
be in rpm format with longevity.
The problems of course only arise when considering an actual
alternative implementation of these APIs, such as the
freedesktop.org X libraries. (xlibs CVS module). When these
libraries are packaged up, they could be packaged in individual
rpm packages (my current plan for now), or they could be put in
one bigger package. Either way, this causes large changes to
various assumptions on dependancies.
While there is no easy one-stop-shopping solution which can
work around all of the possible problems and annoyances that
will occur when alternate implementations of X11 are rpm
packaged and made available, there are probably different ways
to achieve the end goal, which is to:
1) Allow multiple X11 implemenations to be available in rpm
packaging, and be substituted with each other easily.
2) Allow X11 software to compile, link, build and produce
packages irrespective of which implemenation is present. This
is important, because X11 is a standard, and so any compliant
implementation should be substitutable, at least for the bits
that are actually official standards.
3) Allow X11 software binary rpm packages which were compiled
with any X11 implementation, to install cleanly on a system
which has any X11 implementation installed. Of course, in
this particular case, only "official standard" parts of the
given X11 implementation should be interchangeable 100%,
however implementation specific features may require
additional dependancies.
I've thought of various approaches to solving this problem, and
there are rather large tradeoffs no matter which path is chosen.
I personally believe that the best solution is the one that gives
the greatest long-term benefits, and is "future proof". A best
long-term solution however may have additional short term growing
pains which are necessary in order to get to the long term gains.
Here are some example problems:
Package "Requires: XFree86-libs" to get libX11 and libXaw. It
currently "BuildRequires: XFree86-devel" to meet dependancies.
We now want this package to build and work with the alternative X
library implementation "freedesktop-libX11" and
"freedesktop-libXaw". Since only one implementation could be
installed at a given time in a clean manner (we'll make that
assumption anyway), by changing every rpm to use:
Requires: freedesktop-libXaw
BuildRequires: freedesktop-libXaw-devel
That just substitutes one poor assumption problem for another
equally bad problem. It doesn't solve the real problem, which is
that multiple X11 implementations can exist, and any particular
one could be present on the system theoretically.
Another possibility, would be to have something do a virtual
provide for XFree86-libs and XFree86-devel. For example, we
could have a fake XFree86-libs package which does nothing more
than "Requires: freedesktop-libX11" etc. and same for the -devel
package
Problem with that is, that would allow a real quick short term
solution which is quite an ugly hack, and it still makes bad
assumptions and isn't really IMHO "future proof", which as stated
earlier is one of the main goals I wish to achieve from this.
Proposed Solution:
After much thought, my own proposed solution, is to do the
following:
- Create a number of new "virtual Provides:" in the XFree86 rpm
spec file in the XFree86-libs and XFree86-devel packages
respectively. Essentially there would be one new virtual
provide for each library, and perhaps for developmental
utilities necessary for X development also, which are presently
in XFree86-devel.
After testing this and working out any quirks by experimenting
with some out-of-tree packages, by changing their Requires and
BuildRequires to point to the new virtual provides instead, any
major issues could be worked out before anything were to be
developer-visible.
Example for the package freedesktop-libX11 would be:
Provides: libX11 = %{version}
for freedesktop-libX11-devel:
Provides: libX11-devel = %{version}
Requires: freedesktop-libX11 = %{version}
At this point, rpm packagers could begin to change their packages
at will to use the new virtual provides instead of relying on the
implementation specific XFree86-libs and XFree86-devel packages
explicitly. Since both XFree86-libs and XFree86-devel would
continue to exist for some period of time at least, no packages
should break right away, and developers would have plenty of time
to fix the packages to use the virtual provides. Announcements
would be sent out to as many forums deemed necessary to try to
reach rpm packagers who would be affected and need to modify
their rpms.
This would amount to determining exactly _which_ X11 libraries an
rpm package is really dependant on at build time, and then
listing their virtual requires:
Xawtv:
Requires: libX11
BuildRequires: libX11-devel
Packages in the distribution itself could be modified over time
by their respective maintainers, or en-masse by a few people
trying to "solve the problem all at once" with minimal impact on
others internally. Likewise a similar process could occur with
external packages such as Fedora Extras/fedora.us, freshrpms.net,
and other rpm factories. This could very largely be scripted to
find the rpms needing changes, and most of the short-term
problems would be solveable IMHO without much difficulty,
especially since the existing XFree86-devel and XFree86-libs
packages existing still and also containing the right collection
of virtual provides.
This way, if a system has an alternative X11 implementation
installed in the future, it should be harmonious. Of course
there would likely be packages found which never got updated over
time, but that's impossible to avoid 100%. Those remaining
packages could be updated at that point, and it would still be
possible to provide a fake XFree86-devel and/or XFree86-libs
package if there was any significant problem caused by this
solution.
One could then also for example, drop in rpm packages from X.org,
to use their implementation, and have Xorg-libX11 providing the
virtual libX11 package.
I believe that this solution has a lot of merits, although as
stated above, there would be some growing pains in some cases,
however that could be mitigated by continuing to provide the
faked XFree86-foo packages over time, and trying to find and fix
problematic packages as time and whatnot permits, rather than
being forced to do it right away.
I look forward to hearing developmental comments and feedback,
both from other developers at Red Hat, as well as community
developers working on/with Fedora project, Freshrpms.net,
rpmfind.net, and other rpm repositories out there, as well as
feedback from individual project developers who maintain rpm
packages that have dependancies on X11.
Alternative ideas, and/or modifications to my proposal above are
also encouraged. Please try to look at the long term aspects and
benefits and not focus on short term drawbacks/problems, and
please make suggestions that try to remain as X11 implementation
neutral as possible, as I believe that is an important goal.
I look forward to hearing everyone's feedback and comments.
Thanks in advance.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
20 years, 3 months
RH updates on external packages
by Thiers Botelho
Hi,
I've posted a similar request a while ago on fedora-list and got no answer
at all - I suppose it might fit better in here.
Some days ago I received, from fedora-announce, info on updated iptables
1.2.9-1.0. That'd be
http://www.redhat.com/archives/fedora-announce-list/2004-February/msg0000...
It happens that the announcement mentioned a new config option
(IPTABLES_MODULES_UNLOAD), so I went to iptables.org in order to learn
some more about it.
I couldn't find anything there on the topic (
http://iptables.org/files/changes-iptables-1.2.9.txt ) ; then it downed on
me that the Fedora update was 1.2.9-1.0 - this trailing _1.0_ suffix was
nowhere to be found on iptables.org (I might as well have missed something
there).
But the whole point I'd like to understand is more general and not
iptables-specific at all .
It seems that all updates to FC are published by _someone_at_redhat com_ .
So I ask - when RH updates a package in FC, might it make some ADDITIONAL
change to the original package ? I'm asking this due to the _1.0_ and to
the new switch which was not mentioned on the original changelog.
Would someone care to clarify ? Not necessarily on the specific iptables
package, but do outside packages receive additional changes before
becoming generally available for updating users' systems?
Any docs describing this process ?
Thnx
Thiers
20 years, 3 months
qt-3.3 and QTDIR
by Rex Dieter
Any chance of seeing qt-3.3 in FC2? It's -dlopen-opengl option looks
promising for improving prelinking...
While we're on the subject, redhat's/fedora's default QTDIR has been
/usr/lib/qt-3.x for awhile now, which causes at least a small amount of
upgrade pain whenever x changes. Is there any good reason (anymore) to
not put all qt-3.x installs in a common directory, say something like
/usr/lib/qt3?
-- Rex
20 years, 3 months
problem w/ running opengl/Mesa apps on fc1x
by Didier Casse
Hi all,
I noticed that I can no longer run my OpenGL/Mesa apps since I
upgraded
to FC1. Every time I compile and try to run them I get the following error
msg:
---------------------------------------------------------
Xlib: extension "XFree86-DRI" missing on display ":0.0".
---------------------------------------------------------
My hardware seems to support DRI as a
"cat /var/log/XFree86.0.log| grep DRI" gives:
(II) Loading extension XFree86-DRI
w/ no visible error. I also tried to comment out the line
Load "dri"
in /etc/X11/XF86Config, but w/ no success. It still gives me this nasty
error message!
"glxinfo" gives me:
===============================================================================
name of display: :0.0
Xlib: extension "XFree86-DRI" missing on display ":0.0".
display: :0 screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 24 tc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x24 24 tc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x25 24 tc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x26 24 tc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x27 24 dc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x29 24 dc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x2a 24 dc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
===============================================================================
Can anybody tell me what's wrong w/ the system or if it is some bug? How
can I run OpenGL/Mesa apps?
With kind regards,
Didier.
---
PhD student.
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg /
didierbe at sps dot nus dot edu dot sg
20 years, 3 months
Re: Spec file help
by Nils O. Selåsdal
On Fri, 2004-02-06 at 22:39, Karsten Hopp wrote:
> On Fri, Feb 06, 2004 at 09:27:23PM +0000, Gavin Henry wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear all,
> >
> > I know everyone is extremely busy, but if someone has time to check
> over my
> > first spec file and give me some feedback/pointers, it would be
> greatly
> > appreciated.
> >
> > It was made with Mach and installs on FC1 and RH9 fine.
> >
> > Thanks,
> >
> > Gavin.
> >
> > url: http://www.suretecsystems.com/docs/netmon_applet.spec
> >
> >
>
> A few comments:
>
> > Source0 :
> http://www.demonseed.net/~jp/code/netmon_applet/netmon_applet-0.4.tar.gz
> It's better to use %{version} here. Otherwise you'd have to change the
> version
> at two places when you update to p.e. 0.5
Not really. The Source: should be the real URL so QA'ers can copy/paste
it for downloading.
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
20 years, 3 months
Re: Disabled root - by default; up2date more annoying
by Jef Spaleta
Colin Charles wrote:
1. Follow the Mac OS X style of disabling a root login by default.
Enable sudo, and the first account that gets created thru the firstboot,
gets sudo privileges. Thoughts?
---
My understanding is that incorporate selinux has a great impact on what
'disabling' root looks like. I'm pretty sure i had a conversation with
mkj at one point about the selinux implications for the system tools,
the ones we use userhelper and pam_console to ask root password for.
I think whatever you wanted to accomplish with sudo, the selinux
capabilities make possible in a deeper more secure way.
too bad test1 wont have selinux enabled...too play around with this.
-jef
20 years, 3 months
self-introduction
by Alexander L. Belikoff
Ok, following the http://www.fedora.us/wiki/PackageSubmissionQAPolicy
guidelines... ;-)
Name: Alexander L. Belikoff
Country: USA
Profession: Software Developer
Company: Bloomberg L.P.
Goals:
- Help making Fedora Linux the best linux distribution out there, not merely
on par with others.
- Ensure that Fedora Linux is stable enough for production usage (number
crunching, clustering, etc).
- Packages I want to see: PVM, frotz, f2c, p2c, svn
- Yes, I am doing and I will be doing QA!
Historical qualifications:
- Projects: Cyrillic HOWTO, ERC (an IRC client for Emacs), misc patches here
and there.
- Languages: C, C++, Perl, Common Lisp, Java, PHP, others
- Dunno :-)
GPG: key ID 84242701
pub 1024D/84242701 1999-11-06 Alexander L. Belikoff <alexander(a)belikoff.net>
Key fingerprint = 0D58 A804 1AB1 4CD8 8DA9 424B A86E CD0D 8424 2701
uid Alexander L. Belikoff (a.k.a. Sasha)
<abel(a)vallinor4.com>
sub 2048g/BE856296 1999-11-06
Cheers,
--
Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P. 424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key)
20 years, 3 months