Re: Making Fedora Core CD #1 Standalone -- Core should continue, but let's define a subset
by Bryan Smith
Jeff Spaleta wrote:
> I really really really don't think you have to do something as
> elaborate as this.
Well, that depends. (read on)
Eventually it _might_ be a good idea to define a "formal" subset.
But I see where you are leading this.
> Just have people in the community who care about this issue work
> on the comps.xml file definitions that define what a minimal
> install includes and have those packages be part of cd1.
> No reason to formalize with lots and lots of policy.
It seems that simple at first. Unfortunately, there seems to be
a lot of "legacy" dependencies that bite you in the touche.
> This has come up repeatedly...and people in the community SEEM
> interested but those people wander off the mailinglists and never
> actually produce anything of usefulness.
And I can read between the frustration there. Point taken.
There's nothing more distracting than a bunch of "dreamers" but
no "doers" -- I for one have been guilty of being in the former
9 times of out 10.
However, I have been doing little things like this since Red Hat
Linux (RHL) 7, and multiple CDs. Packaging has been much of my
Linux epxerience. And those "legacy" dependencies, one that don't
make sense -- lots of touche missing. ;-ppp
I would like to start documenting some of them, as they exist
in Fedora Core 2.
> Look back in the pre-fc1 release discussions there are several
> threads about how to better define a minimal install and the go
> no where...no where fast. If you are serious about this...you
> will work on the comps.xml file with other people who have an
> interest in a better defined minimal install option.
And that's what I was interesting in. Finding out who was
interesting in helping me.
I'm just curious on what happens if and when I start finding
"interesting" dependencies. Who can I "report" them to
("devel" list or Bugzilla)? At what point will there be
"changes" made -- if at all?
I guess I'll just wait to see those answer _after_ I start
producing more than just hot air, eh? Thanx for your input,
and I _do_ understand where you are coming from.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
20 years
rawhide report: 20040525 changes
by Build System
New package mod_authz_ldap
LDAP authorization module for the Apache HTTP Server
Removed package bluez-sdp
Removed package bluez-pan
Updated Packages:
cdrdao-1.1.8-4
--------------
* Wed Apr 14 2004 Harald Hoyer <harald(a)redhat.com> - 1.1.8-4
- fixed BuildRequires
distcache-1.4.5-4
-----------------
* Mon May 17 2004 Joe Orton <jorton(a)redhat.com> 1.4.5-4
- run ldconfig in %post and %postun
* Sun May 02 2004 Joe Orton <jorton(a)redhat.com> 1.4.5-3
- add BuildRequires: openssl-devel (#122265)
gmp-4.1.3-1
-----------
* Mon May 24 2004 Thomas Woerner <twoerner(a)redhat.com> 4.1.3-1
- new version 4.1.3
iiimf-le-xcin-0.1.5-2
---------------------
* Fri May 21 2004 Leon Ho <llch(a)redhat.com> 0.1-5-2
- backport from cvs
- fixed the problem on ctrl, alt keys when turned on (#121050)
- added new candidate selection screen (shift+< and shift+>)
kernel-2.6.6-1.381
------------------
* Mon May 24 2004 Dave Jones <davej(a)redhat.com>
- Add yet another multi-card reader to the whitelist (#85851)
* Sun May 23 2004 Dave Jones <davej(a)redhat.com>
- Add another multi-card reader to the whitelist (#124048)
* Wed May 19 2004 Arjan van de Ven <arjanv(a)redhat.com>
- put firewire race fix in (datacorruptor)
pilot-link-0.11.8-4
-------------------
* Mon May 24 2004 Than Ngo <than(a)redhat.com> 1:0.11.8-4
- fix build problem with new libpng
qmkbootdisk-1.0.2-1
-------------------
* Mon May 24 2004 Than Ngo <than(a)redhat.com> 1.0.2-1
- release 1.0.2, fix build problem with qt,
add missing KDE icon
rpmdb-fedora-2-0.20040525
-------------------------
tvtime-0.9.12-8
---------------
* Mon May 24 2004 Than Ngo <than(a)redhat.com> 0.9.12-8
- add another patch to enable PIE build of tvtime binary
* Mon May 17 2004 Than Ngo <than(a)redhat.com> 0.9.12-7
- add patch to enable PIE build
wl-2.10.1-3
-----------
* Fri May 21 2004 Jens Petersen <petersen(a)redhat.com> - 2.10.1-3
- update semi to 1.14.6
- semi-1.14.3-CAN-2003-0440.patch no longer needed
- rename some of the version variables in this file
- mention semi in the package description
zisofs-tools-1.0.4-5
--------------------
* Mon May 24 2004 Harald Hoyer <harald(a)redhat.com> - 1.0.4-5
- fixed BuildRequires (123771)
20 years
Making Fedora Core CD #1 Standalone -- WAS: Reduce "Core" to 1 Binary CD?
by Bryan Smith
[ Yes, I'm renaming the subject yet again ;-]
Alexandre Oliva wrote:
> As in, make the installer one of the applications of a Fedora Core
> Live CD? First thing it does is to copy the contents of its root
> filesystem to the chosen root filesystem (should be faster than
> `rpm'ing around lots and lots of packages, and saves CD space!), then
> enables the user to select additional packages to install/remove.
Oh, no. I don't think I was saying that at all. Doing a "Live!" CD
would only bloat the sucker, while adding additional engineering
effort.
What I'm proposing is just:
1. A careful re-evaluation of the "essential" components
2. These components go on Fedora Core CD #1,
which can _now_ be standalone (you only need CD #1)
That's _all_ I'm suggesting. All it takes is some careful decision
making regarding packages, but *0* re-engineering effort. At most,
there would just need to be some checking that _nothing_ on CD #1
has any dependencies on any other "Core" CDs.
Maybe I only confused people by calling it "Quark" or "miniCore."
In a nutshell, I'm just talking about making Fedora Core CD #1
standalone -- that's all!
But if careful planning is required, then we _might_ need to add
a 6th repository guideline (I call it "Quark" by call it whatever):
Dependency Limitations
Quark: Quark
Core: Quark, Core
Extras: Quark, Core, Extras
... etc ...
We'll still have "Core" for Legacy Red Hat Linux (RHL) and all its
dependencies. But sooner or later (hopefully sooner), it would be
nice to define a "smaller Core" -- one that amounts to less than
500MB compressed would be ideal (fits on a single CD). Let us
aim for just basic client functionality using X+GNOME (and minimal
at that!).
I call this Fedora "Quark" for repository/dependency arguments
sake (call it what you will in the finale).
Fedora "Core" should continue to be developed, as-is, as the RHL
replacement. Quark will be a part of Core. But Quark will offer a
"reduced package list" that has self-only dependency, just like
Core is to Core, Extra to Extras, etc...
[ BTW, someone could certainly make a "Live" version of Fedora Core
CD #1, but I'm not suggesting the Fedora team head that up. There
are plenty of people who could do this after-the-fact. In fact,
something like "Quark" should be defined in the first place _before_
someone comes up with a "Live" CD. But a Live CD is something else
entirely. ]
Chris Chabot wrote:
> Actually rpm packages compress the binary payload (gzip default,
> configurable for bzip2), so uncompressed on cd storage would require
> more space. Secondly cd read speed is slower (presumably) then your
> HD write speed, so extracting & writing files should be faster then
> copying them straight from cd.
Just to re-iterate, I was not talking about a Live CD. That's not
related to my recomendation for a "subset" of Core that weighs
in at less than 500MB, has 0 dependencies on anything else, and would
ideally be CD #1 in Fedora Core itself.
--
Bryan J. Smith, E.I. -- b.j.smith(a)ieee.org
20 years
Interested to help....
by Kim B. Nielsen
Hi...
To be short, I would like to participate in the development of new
Fedora Releases...
I primary got experience in building new rpm packages and maintaining
them, and I have some experience in overall system administration... But
I'm also interested in learning new aspects of Linux, even though I'm
not a newbie to Linux...
I didn't know how to announce my interest other places than here, so I
hope it's apropriate... And i hope that there will be some tasks to do...
Regards
/kbn
20 years
Fedora Project Mailing Lists reminder
by Elliot Lee
This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
http://fedora.redhat.com/participate/communicate/
When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!
Mailing Lists
Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.
The following mailing lists are available. To subscribe, send email to <listname>-request(a)redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.
fedora-announce-list - Announcements of changes and events. To stay
aware of news, subscribe to this list.
fedora-list - For users of releases. If you want help with a problem
installing or using , this is the list for you.
fedora-test-list - For testers of test releases. If you would like to
discuss experiences using TEST releases, this is the list for you.
fedora-devel-list - For developers, developers, developers. If you are
interested in helping create releases, this is the list for you.
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
configuration tools
fedora-legacy-announce - For announcements about the Fedora Legacy
Project
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-de-list - For discussions about Fedora in the German language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
Fedora Core
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
German: fedora-trans-de
French: fedora-trans-fr
Spanish: fedora-trans-es
Italian: fedora-trans-it
Brazilian Portuguese: fedora-trans-pt_br
Japanese: fedora-trans-ja
Korean: fedora-trans-ko
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw
20 years
/sbin/devlabel errors at boot.
by Brian Millett
Hi,
First of all, I am running FC2 + rawhide (got to bleed!). I've been just
yum updating and did not have any problems that were not resolved. I did
not upgrade to FC2 with the CS's so my problems could be a result of not
having anaconda work its final mojo, but I'm not sure.
Problem: I get the following errors at boot, or rather when
/sbin/devlabel is restarted in /etc/rc.sysinit:
/sbin/devlabel: line 880: /etc/sysconfig/devlabel.d/ignore_list: No such
file or directory
/sbin/devlabel: line 881: /etc/sysconfig/devlabel.d/proc_partitions: No
such file or directory
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 905: [: -eq: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
grep: /etc/sysconfig/devlabel.d/ignore_list: No such file or directory
/sbin/devlabel: line 129: [: -gt: unary operator expected
I see that all of these messages are caused from a lack of having a
/etc/sysconfig/devlabel.d directory.
Do I need one? What steps do I take to get right with the world?
Thanks.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpmATec-groupDOTcom Greg Glenn
20 years
Re: Request for Packages in Fedora Core 3
by PLinnell
> Message: 1
> Date: Sun, 23 May 2004 19:55:18 +1000
> From: David Le Sage <dlesage(a)iprimus.com.au>
> Subject: Request for Packages in Fedora Core 3
> To: fedora-devel-list(a)redhat.com
> Message-ID: <40B07506.8060407(a)iprimus.com.au>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Hello All,
>
> I am really enjoying my use fo Fedora Core 2. To make the next release
> even better, I humbly request the following packages be considered for
> inclusion:
>
> Scribus - The first modern DTP package for Linux. This is an
> essential for myself and many others moving from commercial
> operating systems. More than any other package, I would love to see
> this included. It will help you win converts...
>
> KIllustrator or Sketch - Vector graphics would be very good. I
> understand one of these products has as much functionality as GIMP but I
> am not sure which. Open Office's drawings do not suffice.
>
> Ardour or Audacity for audio manipulation.
>
> Please keep up the excellent work.
>
>
> Regards,
>
> David
Thanks for the kind words about Scribus. We are working diligently
towards a stable 1.2 release in the next few months. This is a question
I have long pondered having used RH since 7.0. "When would Scribus be
worthy of inclusion?"
Disclaimer: I have been part of Scribus since 0.37
Comments/Observations:
1) AFAIK - the best place to request this is:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107630 which is a
existing request to add Scribus in Fedora/RH.
2) Three of five Scribus devels run RH9 and/or Fedora.
3) Scribus has been in Fedora.us and works very well with the stock
distro. We have had no issues with RH/Fedora users - provided they have
not messed with mixing third party stuff or home brewed installs.
4) For Vector Graphics - I would vote for Inkscape or Skencil. Inkscape
is rapidly developing and has excellent SVG output. By the time FC-3 is
out it should be more feature complete and better import/export
capabilities. Inkscape has a very good team and is _very_ user friendly
for an advanced vector application. The only issue adding it to Core
would be the need for gtkmm. Skencil is mature and the next version is
based on GTK, not Tk. I do think a real drawing tool is needed for the
desktop.
5) Suse has made a big fuss about Scribus:
http://www.suse.com/us/private/products/suse_linux/i386/graphics.html
6. Scribus needs no other packages from Fedora Core except littlecms.
That can be made optional, though not recommended.
7. It has consistently been voted one of the most popular programs on
kde-apps.org
I think the best argument is Scribus fills a couple of huge niches on a
Linux Desktop: Desktop Publishing for both beginners _and_ experts. It
also can create PDF forms like Acrobat.
By any objective standard, Scribus produces superb PDF, as tested by
several professional pre-press tools. It also can create PDF forms like
the full Acrobat and has other PDF features which no other application
is even remotely capable of on Linux.
By the time, FC-3 is out, there should be a stable Scribus 1.2 released,
feature complete with new documentation, many sample files and
templates.
As a long time Redhat user, yeah, I can honestly say, without
hesitation, its ready.
I would be most curious to have feedback from Redhat devels.
Cheers,
Peter
20 years
Call For Use of i18n keyword for bugs
by Akira TAGOH
Hi,
Our bugzilla has supported 'i18n' keyword on Keywords
field. and people can see from
http://bugzilla.redhat.com/bugzilla/describekeywords.cgi how
many I18N related bugs are opened. (of course it's not only
for I18N, though). but actually we have many bugs for I18N,
which isn't added 'i18n' keyword. so I would like to call for
use of 'i18n' keyword if you need to file an I18N related
bug. it will helps us to track the I18N bugs.
Please use proper keywords for people who wants to check out
the bugs extensively.
Thanks,
--
Akira TAGOH
20 years
Prepackaged configurations
by Havoc Pennington
Hi,
Something that's missing in the OS is an "out of the box" experience
for the different ways one might use the operating system.
For example, if you want an X terminal server and some X terminal
clients, then you have to read a fair bit of docs and modify all the
relevant config files, which may be in a number of formats. Other use
cases that require custom setup might include router/firewall,
clustering, locked-down desktop, or whatever.
In an ideal world, someone could maintain the canonical best practice
setup for say a locked-down desktop lab, and everyone else just
clicks/types "install me a locked down desktop lab system," applies any
site-local tweaks, and that's it.
I'm calling this a canned or prepackaged configuration.
This would be useful because:
- developers could encode the recommended best practices
in these canned configurations
- QA and testers could then easily install and test the
OS for each canned use case
- docs authors could easily get things working for
each use case
- users and admins would have a nice "out of the box"
experience getting things going very quickly, and
avoiding a lot of custom engineering that tends to
break on upgrade
- allows developers to coordinate the whole network
environment; e.g. the canned config for LDAP/Kerberos
server should automatically work with all the client
installs, same for print server etc.
- we probably need different defaults for desktop and server
in some cases, e.g. for how hardware is handled
Some of the things that _might_ change across canned configurations:
- the package set (the only thing we can change now, via
the Workstation or Server split in the comps file for example)
- specific parts of a config file, e.g. enabling xdmcp in gdm
- default settings in gconf (e.g. each canned config might
add a new config source in /etc/gconf/2/path)
- contents of /etc/skel
- optimum partitioning scheme
- first boot screens, e.g. asking for site-specific info to
go into the configuration
- kernel boot options
Some baseline considerations for how to approach this problem:
- we should approach it consistently, such that there's one place
to browse a list of available configurations, a general pattern
followed for how they are implemented, and so forth
- ideally, it's dynamic instead of only install-time, i.e.
you can change a machine from config A to config B post-install.
Easier for some things than others (e.g. partitioning scheme
impossible to change post-install, config files perhaps easier,
package set relatively simple)
- ideally, third parties can provide their own canned
configurations maintained separately from the main OS.
You can imagine whole open source projects that basically
just maintain a configuration.
- ideally, these configurations can be in the installer in the
same list as Workstation vs. Server choice; it would be strange
to choose between Workstation and Server then later choose
between canned configurations
- ideally, local or site-specific tweaks can be kept separate from
and "override" the canned settings, so that on upgrade you
inherit new updates to the canned config
- Jeremy does not want to maintain this stuff in the installer
- selecting a given canned config has to be possible via kickstart
Some possible approaches:
A. documentation. We just write down how to build each
configuration, possibly providing an example kickstart file.
Put these documents in a common location with a standard
naming scheme, etc.
Downsides: doesn't provide the automation, so no "out of the box"
experience; doesn't clearly make one developer/maintainer
responsible for whether the config works and what it's like.
Upside: relatively easy
B. kickstart files. We provide a kickstart file for each
configuration, probably there's a package naming convention
like kickstart-x-terminal-client, and a convention for
where the kickstart file is installed.
Downsides: user has to install the OS, set up a kickstart server
or make a boot disk, learn about kickstart, etc.; kickstart files
contain incidental noise such as partitioning and so forth that
will usually be unrelated to the canned config
Upside: does not affect the installer, and again relatively
easy
C. kickstart profiles. Introduce something like "%profile
x-terminal-client" that can go in a kickstart file.
Could implement an XML description of each profile,
support something like:
$ kickstart-profile --list
vnc-terminal Remote Desktop Terminal VNC based thin client terminal...
x-terminal X Terminal X based thing client terminal...
....
This is somewhat nicer than just providing a collection of
kickstart files.
D. config profiles usable by the installer. Same as above, but
offer them in the installer rather than just package sets
in the installer.
E. dynamic "alternatives" system for configurations. Direction
suggested by Owen, haven't sorted out how this would work
precisely, perhaps symlink-based.
F. write a simple library for redirecting config file lookup
depending on a global "what this system is for" setting.
e.g. you might have gdm.conf.normal and gdm.conf.xterminalclient
and gdm would use a simple library that keys off of
/etc/sysconfig/system-profile to locate the right config file?
G. meta-packages. e.g. have a package x-terminal-client that depends
on some set of other packages, provides certain config files,
etc.
The obvious problem is that the gdm package provides
gdm.conf, so how does a meta-package install a different
gdm.conf. If every important daemon/feature supported a
conf.d with override files in it, that might answer the
question, but sadly that isn't the norm.
H. Some sort of RPM changes. Presumably we could make RPM smart
about this problem in some way. I don't have concrete ideas.
Obviously, this is far from fully thought-out at this point, I'm just
trying to start the thread. It looks pretty likely to me that our
solution will be a pragmatic compromise that isn't quite ideal. But
which compromise is the best one?
Havoc
20 years
Fedora minimal install...
by MG
Hi!
When will be avaiable in Fedora the absolute minimal install option?
It could be the 300-400MB with the absolute necessery packages?
For exmaple for a single firewall system.
Bye!
Gabor
20 years
