RFC: drop old autofoo spackages
by Karsten Hopp
Hello,
We're currently shipping several quite old automake/autoconf packages just to keep
a few other old packages building. I'd like to drop the following packages:
autoconf213 (8 years since the last upstream maintenance)
automake14 (5 years since the last upstream maintenance)
automake15 (6 years since the last upstream maintenance)
automake16 (5 years since the last upstream maintenance)
Packages with build dependencies on those packages:
in Core:
autoconf213:
esc
pam_smb
tetex
vnc
automake14:
libwmf
automake15:
nss_db
automake16:
gmp
krbafs
in Extras:
autoconf213:
glib
gtk+
automake14:
gdk-pixbuf
glib
gtk+
imlib
WindowMaker
automake16:
aplus-fsf
qalculate-kde
Maintainers are encouraged to switch to more recent releases of the autoconf tools
and work with upstream to get this done. They also should make sure if it is really
necessary to run p.e. automake at all.
--
Karsten Hopp | Mail: karsten(a)redhat.de
Red Hat Deutschland | Tel: +49-711-96437-0
Hauptstaetterstr.58 | Fax: +49-711-613590
D-70178 Stuttgart | http://www.redhat.de
17 years, 4 months
Re: Fedora 7 media sets
by Chris Schumann
Speaking as a fan and user of Fedora on several machines, I would very
much like to see the detailed instructions on making one's own
distribution based on Fedora, or a very minimal install.
I have a couple of old laptops with no CD drive that I would really like
to put Fedora on because I know how to administer it. I've made my own
boot floppy sets (that still don't seem to work quite right for FC6) and
plan to start looking into initrd so my old 486 laptop with 36MB RAM will
install something.
Chris
17 years, 4 months
Re: Fedora 7 media sets
by bastard operater
Jeremy Katz wrote:
>Just putting the bits on the DVD isn't enough to be able to install from
>it. The metadata on the first disc has to encompass all of them, there
>has to be some kind of reasonable way to opt-in to the fact that you've
>got everything, package ordering could be ... interesting. Also, the
>fact that the metadata will have everything ends up meaning that the
>memory requirements are higher due to "more bits". Or how do you drop
>the bits you no longer need.
I did something like that a long time ago. Translated to current times and
Linux it should be as easy as:
1 On the first DVD create two directories. fc7dvd and everything for
example
fc7dvd contains the metadata for the first dvd only. everything contains
the
metadata for the 2nd dvd. If the user selects an everything install
anaconda
reads the metadata from both fc7dvd and everything (I don't know how hard
this is to do). Or just have the full metadata for both dvds in
\everything.
This might waste a little space as I don't know how much space is used by
the metadata.
2 At the boot screen the default is fedora dvd and reads from the fc7dvd
directory. If the types linux everything then anaconda reads from the
everything directory or from both depending on which way you go.
Just my 2 pennies.
_________________________________________________________________
Check out all that glitters with the MSN Entertainment Guide to the Academy
Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2
17 years, 4 months
Re: Smolt: firsboot revisited
by Dennis Gilmore
On Thursday 15 February 2007 09:06, Ralf Corsepius wrote:
> On Thu, 2007-02-15 at 08:46 -0600, Dennis Gilmore wrote:
> > for now shut up and stop wasting peoples times with your rants and FUD.
> > --
> > Dennis Gilmore, RHCE
>
> Great, how you proved your competence on privacy and replied to a PM on
> a list.
>
> I am expecting an excuse.
Ralf,
none of the valid discussions on implementing smolt which is optional
should be taken in private. Fedora Does not make its decisions in private.
They are made in public. As is all my communications with you.
--
Dennis Gilmore, RHCE
17 years, 4 months
Re: Smolt: firsboot revisited
by Dennis Gilmore
On Thursday 15 February 2007 07:13, you wrote:
> On Thu, 2007-02-15 at 06:48 -0600, Dennis Gilmore wrote:
> > Once upon a time Thursday 15 February 2007 2:43 am, Ralf Corsepius wrote:
> > > Yes, but this thread started with "Shall smolt be installed by
> > > default", so the question wasn't "opt-in/opt-out", it was "installed by
> > > default"
> > >
> > > I expressed my opinion and said: No, ...
> >
> > by installed by default we want to give users the option at first boot to
> > send in their profile if they so choose. nothing more
> >
> > Stop making this about more than it is
>
> Gradually I am loosing patience. Are you smolt guys really so narrow
> minded and blind?
Don't take things off list please you need to look at the code of not use
smolt i don't care either way. no one is making you use smolt so don't
>
> I perceive smolt as SPYWARE, spying at data which I am not interested in
> to communicate to anybody, nor being traded nor whatelse. Neither to
> Fedora nor to RH nor the NSA the FSB or anybody nor a hacker having
> cracked into anywhere inbetween.
>
>
> And before you start shoot at me accusing you to implement spyware, you
> want look up spyware in Wikipedia:
>
> http://de.wikipedia.org/wiki/Spyware:
>
> "Als Spyware wird üblicherweise Software bezeichnet, die persönliche
> Daten eines PC-Benutzers ohne dessen Wissen oder Zustimmung an den
> Hersteller der Software (Call Home) oder an Dritte sendet oder dazu
> genutzt wird, dem Benutzer direkt Produkte anzubieten."
>
> Rough, almost literal translation:
>
> "Spyware is the common naming of software, which transmits a PC-users's
> personal data without his knowledge or consent to the manufacturer of
> the software (Call Home) or to third parties or which is being used to
> directly offer a user products."
>
> That is, they key it to "transmission" and the definition of "personal
> data".
Smolt does not transmit anything without anyones consent and there is
nothing personaly identifiable in there. unless you give the key out i.e
your UUID. all data is transmitted with the full consent of the user only.
> Now compare this to the one found on the English wikipedia. They differ
> substantially.
>
> Yet another indication for a major cultural/natural background.
> Apparently one, preventing people at RH to understand what all this fuzz
> is about.
I personally have nothing to do with RH im not a employee nor am I a share
holder.
Ralf,
I'm going to ask you to stop what you are doing now as you are making yourself
look like an idiot. everything you say smolt should do it does. its opt in,
it has nothing personally identifiable. you don't listen to anybody and you
don't base your arguments on facts. the code to smolt is released under the
GPL you are free to audit it at any point in time and file bugs for things.
you are not being forced to use it. Open your narrow mind and see the big
picture here.
for now shut up and stop wasting peoples times with your rants and FUD.
--
Dennis Gilmore, RHCE
17 years, 4 months
Wiki outage (upgrade)
by Mike McGrath
I'll be doing a wiki upgrade from 8:00 a.m. to 5:00 p.m. (CST) on
February 21st (Wed). I'll be trying to minimize downtime and, in
theory, the wiki won't every be unavailable, just un-writeable. During
our tests it has been determined that there are very few changes that
need to be made so we'll just fix things as they come up.
-Mike
17 years, 4 months
BuildRoot in spec files?
by Steve G
Hi,
Why is BuildRoot in spec files? (Don't say tradition.) It seems to me that its a
_build system_ tunable and not something that each spec file should do
differently. Can we define that in rpmmacros and take it out of all spec files?
The fact that it comes up in spec file reviews and we are supposed to have the
_same thing_ in each file just screams to be relocated to a central place and no
longer controlled by each spec file.
-Steve
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
17 years, 4 months
/tmp filling up
by Michel Salim
Has anyone else experienced their /tmp directory filling up with
tmpXXXXXX.tmp files? It reliably occurs on two separate installs of F7
I've done after several hours of usage, entirely filling up the
partition (how I wished I'd put /tmp on a separate partition).
Incidentally, what's the rule determining when the space reclaimed by
deleting a file on a full partition is actually made available?
Restarting does the trick, and sometimes logging out works as well.
--
Michel Salim
http://hircus.wordpress.com/
My theology, briefly, is that the universe was dictated but not signed.
-- Christopher Morley
17 years, 4 months
Switching to ncurses
by Bernardo Innocenti
Are we still planning to completely replace termcap with
ncurses in Fedora?
While I welcome reducing the number of dupe packages, I'm
worried by the impact of this change on the size and
performance of many core programs.
libncurses is much bigger than libtermcap, and also has
oddly large .bss and .data sections:
bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2
text data bss dec hex filename
319006 56608 3592 379206 5c946 /lib64/libncurses.so.5
10483 788 112 11383 2c77 /lib64/libtermcap.so.2
this is going to impact very negatively on the RSS of several
critical programs such as bash and python.
I'm also worried that the overall time required spent for a
fork may increase considerably.
But maybe ncurses can easily be fixed to avoid global data and
buffers?
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
17 years, 4 months
Can we make readahead more robust to package updates?
by Jef Spaleta
Okay its come to my attention that the readahead configs have a
difficult time being kept in sync as package updates roll out. For fc6
right now for example readahead is out of sync with firefox libraries.
Can we update readahead's implementation so we can get per package
control of the default configs? Is a readahead.d/ structure
appropriate here?
I want to point out that we lose significant value with read-ahead if
we can't ensure that the listings will be in-sync as package updates
are issued. And re-spinning readahead updates periodically to attempt
to sync a centralized config file is horrible inefficient and may
never be perfectly in-sync considering the churn of updates during a
release cycle.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203329
-jef
17 years, 4 months
