Open Bugs which now build, and can be marked CLOSED RAWHIDE:
libgpg-error 193550 NEW
Note: This is using a reduced set of packages in the build chroot as
compared to the standard Fedora Extras build system before FC6test1. See
http://fedoraproject.org/wiki/QA/FixBuildRequires for more
information, including the list of packages removed from the
default build chroot.
Extras Rawhide-in-Mock Build Results for x86_64 Wed May 31 10:01:38 CDT 2006
Number failed to build: 185
Number expected to fail due to ExclusiveArch or ExcludeArch: 11
(there may be some duplicates if rawhide has 2 versions of a package)
Of those expected to have worked...
Without a bug filed: 172
With bugs filed: 2
gtkhtml36 ['193476 NEW']
yumex ['193549 NEW']
Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Since the introduction of Keith Packard's Xft library to XFree86
years ago, and the second incarnation of Xft coupled with Keith's
fontconfig, it seemed natural that at some point in the future,
the majority of modern desktop applications being developed would
move away from the legacy X Window system's "core fonts" system
and use the far superior Xft/fontconfig system.
However, since there are a large number of Xt, Xaw, and Motif
based applications out there, as well as applications which use
other less common toolkits - all of which use the core fonts
system, it was obvious that we would need to provide core fonts
compatibility in our OS products for the forseeable future.
The simplest thing to do, was to just leave the existing system
as it was, under the "if it ain't broke, don't fix it" principle,
which is what I have pushed for since the Red Hat Linux days when
we deprecated xfs and core fonts, reserving the future right to
make changes if the need arose.
For the last 3 Fedora Core releases, there has been a lot of
increasing pressure both in the community, and internally, to
reduce the reliance of Fedora Core on the core fonts system,
and so this problem has been investigated each release to
determine wether it was the right time to make any dramatic
changes or not.
While the migration from monolithic X.Org 6.8.x to X.Org 7.0
introduced quite a number of rather major changes in the way the
X Window System is packaged, maintained and integrates into the
OS, we managed to keep the core fonts system intact, and
decided to keep xfs as the default solution for Fedora Core 5.
Now that we have begun the Fedora Core 6 cycle, this problem
domain is once again on the chopping block so to speak, and
there is increasing pressure to reduce our dependency on the
xfs font server and the legacy core fonts system.
In particular, xfs and core fonts does not fit well into the
One Laptop Per Child (OLPC) effort, or other Fedora derived
embedded distributions. In these embedded systems, or
reduced computing environments if you will, every megabyte
of disk space and memory counts. Shedding megs of stuff out
of the default OS installation is sure to reduce both the
memory footprint and disk footprint of the OS installation,
which is a net gain for these systems, and also for a lot
of the userbase out there that do not use any applications
which rely on core fonts.
On the other hand, there are many applications included both
in Fedora Core, and in Fedora Extras, which do rely on the
core fonts system still, and are likely to rely on it for the
forseeable future. There are also many 3rd party open source
and commercial applications, as well as custom in-house
applications that many users and/or companies rely on, and
will want to keep working in new OS releases.
As such, for the present time and forseeable future, we still
need to provide core fonts support in the OS, however in the
interest of moving forward, and reducing dependencies on
legacy technology, we would like to make the xfs font server
an optional part of OS installation, and change the default
configuration of the X server to not require xfs. Additionally,
the font packages would need to be changed to not have indirect
dependencies on xfs (through a dependency on chkfontpath).
Since this is a change which is likely to affect many users
out there, I thought it was best to discuss this problem with
the community right away, and get everyone involved in the
problem solving and decision making process, in hopes that we
can collectively come up with the best solution overall which
balances the needs of all users, while at the same time
keeping things as simple as we possibly can.
Here is a bit of background on the OLPC issue:
We look forward to hearing your constructive feedback and
suggestions as to how best to attack this problem. Please
respond to this thread on-list, and if you have any comments
to add to the OLPC bug report above, please feel free to
provide some constructive feedback there as well.
Thanks in advance for your contributions.
Mike A. Harris * Open Source Advocate * http://mharris.ca
On 5/29/06, Callum Lerwick <seg(a)haxxed.com> wrote:
> On Wed, 2006-05-24 at 10:08 -0500, Chris Adams wrote:
> > Once upon a time, Bernardo Innocenti <bernie(a)develer.com> said:
> > > What's wrong with GPL programs using the Mozilla implementation?
> > > Last time I checked NSS was totally GPL compatible.
> > mozilla-nss requires mozilla-nspr. libnss3.so also pulls in
> > libpthread.so. Those are pretty heavy requirements for SSL.
> Even OpenSSL is so bloaty that the smallest I can get it down to (on
> MIPS, who's code size seem to be about 2x i386) is 1.5mb. Making it
> impossible to fit into the 2mb flash on a belkin router. Sigh.
> There's MatrixSSL, but there's next to nothing that actually uses it...
What do you want to do in 2MB? I mean in that space I doubt you could
get many encryption algorithm beyond 1 or 2 ( one for key exchange,
one for cipher). At that size point, I would just look for whatever
encryptions are in the kernel source code and use those all the time.
Stephen J Smoogen.
CSIRT/Linux System Administrator