Missing update advisories
by Bernd Bartmann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
After FC3 final has been released several updates have been pushed out
to the mirrors and yet again we haven't seen any announcement for some
of them. Some announcements for FC2 and even FC1 are still missing too:
FC1:
gaim-0.77-2.FC1
gaim-0.80-1.FC1
gaim-0.81-1.FC1
postfix-2.0.16-1
recode-3.6-12.0
FC2:
devhelp-0.9.1-0.2.2
epiphany-1.2.7-0.2.0
epiphany-1.2.7-0.2.2
fam-2.6.10-9.FC2
gaim-0.77-7
gaim-0.80-1.FC2
gaim-0.81-1.FC2
gaim-1.0.2-0.FC2
gnome-session-2.6.0-4
kernel-2.6.9-1.3_FC2
libxml-1.8.17-10.1.2
man-1.5o1-6
mozilla-1.7.2-0.2.0
mozilla-1.7.3-0.2.0
nfs-utils-1.0.6-22
ruby-1.8.1-5
slang-1.4.9-12
xinitrc-3.41-1
xorg-x11-6.7.0-9
FC3:
aspell-bg-0.50-7
bash-3.0-18
brltty-3.2-6
cvs-1.11.17-4
firefox-1.0-2.fc3
gamin-0.0.17-1.FC3
iptables-1.2.11-3.1.FC3
kernel-2.6.9-1.678_FC3
kernel-2.6.9-1.681_FC3
libselinux-1.19.1-3
libxml-1.8.17-12
man-1.5o1-7
man-pages-pl-0.23-4
policycoreutils-1.18.1-2
postfix-2.1.5-2.3.FC3
rhgb-0.15.1-1.FC3
shadow-utils-4.0.3-38
shadow-utils-4.0.3-40
slang-1.4.9-7
slang-1.4.9-13
udev-039-10.FC3.2
words-3.0-2
Besides this there were twice two announcements that had the same id:
FEDORA-2004-378:
kdelibs-3.3.1-2.2 for FC3
kdegraphics-3.3.1-2.1 for FC3
FEDORA-2004-407:
libxml2-2.6.16-3 for FC3
libxml2-2.6.16-2 for FC2
Best regards.
- --
Dipl.-Ing. (FH) Bernd Bartmann <Bernd.Bartmann(a)sohanet.de>
I.S. Security and Network Engineer
SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin
Fon: +49 30 214783-44 / Fax: +49 30 214783-46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBomTekQuIaHu84cIRAqzIAJ4llolT+CH3DuZKOYDtOlZx4lAgvACcCNgA
dh3N84SOm6UfumZKbMnZtZU=
=qDox
-----END PGP SIGNATURE-----
19 years, 4 months
i486 base architecture
by William M. Quarles
Hi,
Earlier this year on this list several of us were discussing the
possibility of adjustments being made to the architecture optimizations
of the Fedora Core packages. One of the suggestions thrown around that
had zero opposition was changing the base architecture from i386 to
i486. Why has this not been done? This is especially poignant since
Fedora Core 1 finally broke i386 compatibility with its kernel.
I'm sending a related note on the Pentium 4.
Peace,
William
19 years, 4 months
/proc/bus/usb ??
by Brian Millett
I'm guessing that I should know this, sorry, but with the last initscripts
update, I now get a message like
"can't find /proc/bus/usb in /etc/fstab or /etc/mtab"
I have googled to see what should be in /etc/fstab and have found four
variations.
usbdev /proc/bus/usb usbdevfs defaults 0 0
usbdevfs /proc/bus/usb usbdevfs noauto 0 0
none /proc/bus/usb usbdevfs defaults 0 0
/proc/bus/usb /proc/bus/usb usbdevfs defaults 0 0
What should I have? I do have a /proc/bus/usb that is populated.
Thanks.
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpmATec-groupDOTcom Greg Glenn
19 years, 4 months
Eina - gtk2 replacement for xmms
by Michael A. Peters
xmms is (imho) the best music player that ships with FC simply from a
usability standpoint, small screen footprint etc.
However, it does not use the gtk2 interface and does not use the
gstreamer backend.
I found what I think would be a good replacement - it currently does
not work for me, so it has that against it, but that may be because I
updated my gstreamer plugins from stock fc3 (to 0.8.6) though that
hasn't effected other gstreamer apps.
It's called eina - http://bolgo.cent.uji.es/proyectos/eina-en
It has a very small screen footprint, and simple easy to use interface.
It works for me up to the point of actually playing a song, then it
hangs (I've only tried mp3 - I haven't tried flac or ogg). But I think
it is worth looking into for possible inclusion in Fedora Extras and
eventual replacement of xmms, which doesn't seem interested in gtk2 or
gstreamer support.
19 years, 4 months
openoffice.org-i18n size
by Ville Herva
> rpm -qi openoffice.org-i18n
Name : openoffice.org-i18n Relocations: (not relocatable)
Version : 1.1.2 Vendor: Red Hat, Inc.
Release : 12.7 Build Date: Tue Nov 23 23:38:11
2004
Install Date: Sat Nov 27 10:46:07 2004 Build Host:
tweety.build.redhat.com
Group : Applications/Productivity Source RPM:
openoffice.org-1.1.2-12.7.src.rpm
Size : 645925614 License: LGPL
^^^^^^^^^
Would it make sense to split openoffice.org-i18n up somewhat? For example,
I'm only interested in Finnish and not about Africaans, Catalan, Arabian and
what not. 650MB is pretty much for stuff that is not needed at all; it's a
huge download (although it compresses well), but also takes up disk space
quite much.
Or is it just infeasible idea to split it in smaller parts?
BTW: Anyone tried openoffice 2.0 beta yet? I don't suppose there are fedora
rawhide compatible rpm's for it somewhere?
-- v --
v(a)iki.fi
19 years, 4 months
print configuration
by Trever L. Adams
I am not entirely sure if this is how to do it. But, here goes:
In the past you could configure printers using the RedHat supplied tools
(as found in menus) in Samba. I am no longer seeing this. I have checked
the option in print conf to share the printers and autodiscover them. I
think this is a cups thing. However, this doesn't even seem to be
working with my systems. (I do have all the systems checked to discover
the shared printers.)
Even if this was working, this doesn't share them with the Windows
world.
In FC4 is it possible to add an option in printconf or what not that
will share them via Samba as well as cups method?
Trever
--
"What makes his world so hard to see clearly is not its strangeness but
its usualness. Familiarity can blind you." -- Robert M. Pirsig
19 years, 4 months
Suggestion for some network parameter defaults
by Ralf Ertzinger
Hi.
I have been using the following changes to some network parameters on all
of my machines for a long time, and I was wondering whether they ought to
be set by default.
net.ipv4.conf.all.rp_filter (current: 0, proposed: 1)
net.ipv4.conf.all.accept_redirects (current: 1, proposed: 0)
net.ipv4.icmp_echo_ignore_broadcasts (current: 0, proposed: 1)
net.ipv4.icmp_ignore_bogus_error_responses (current: 0, proposed: 1)
While I admit that the current values can serve a certain use in some
situations, I think that in the majority of configurations the proposed
values are more sensible.
--
"Carpe dentem! Seize the teeth!" -- Mrs Doubtfire
19 years, 4 months
Re: Elektrified X.org released (was: X configuration paradigm, and a proposal)
by Alan Cox
On Maw, 2004-11-30 at 18:23, Jim Gettys wrote:
> David,
>
> I agree with you and Kristian and I have started work, specifically on
> the input system side to do exactly what you suggest. Similar
> work ought to be done someday for the screens themselves (hotplug being
> a reality even for screens; today with PCMCIA and PCI express is just
> beginning to ship).
Mobility Electronics have been shipping cardbus hotplug video for about
5 or 6 years now (E1000V). They make fun toys for this sort of testing
and are cheap on ebay generally 8)
19 years, 4 months
Re: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support)
by Dave Jones
On Sun, Nov 28, 2004 at 05:42:41PM -0500, William M. Quarles wrote:
> A. I'm tired of Red Hat holding back on optimizations. The architecture
> tree/network that RPM consults is kind of screwed up. Not to mention
> that it is ridiculous to compile packages for i386 architecture that
> will never run on an i386, especially when the developers have dropped
> in MMX instrcutions in the assembly anyways, so the i386 designation is
> then meaningless.
Those applications should be doing the relevant cpuid checks at runtime
before using them. Fedora supports processors that don't have MMX.
If you have a list of applications that don't do this, file bugs
in bugzilla.
> It would be nice if RPM could call compilations for
> say pentium-mmx or pentium2 rather than forcing developers to insert
> this code manually via assembly
The number of packages using assembler is tiny compared to the
number of applications shipped. And no gcc options are going to
change that for the most part. gcc is getting better all the time,
but hand-written assembler is hard to beat for speed-critical
operations in packages that really need the speed.
> B. Red Hat developers were saying before that we need more optimization
> for the Pentium 4 because it is obviously not running as well on i686
> optimizations as it could. However, I have yet to see a Pentium 4
> optimized Fedora Core kernel come out. Perhaps they're busy debating
> about whether to call it pentium4 or i786.
The idea had crossed my mind to ship the 686 kernel as p4 optimised
the last time this discussion came around for benchmarking purposes.
Not around round tuits.
> C. If it doesn't hurt and it would probably help, I don't see what's the
> matter with making an Athlon-optimized kernel.
A number of reasons.
- It's one more column in the matrix of supported kernels to worry about.
This may seem insignificant, but it takes quite a while to push
a kernel package through the buildsystem given how many variants
it spits out. On a busy day (like for eg, just before release), it
can take the better part of a day to get packages built.
- The gain just isn't worth it over the 2.4 kernels.
Now that the runtime optimisations get performed in 2.6, theres only
one thing thats missing that would be in an Athlon optimised kernel,
and thats the optimised copy_page/clear_page, which are really only
a win when a lot of data is being copied back/forth between the kernel,
and even then, only under certain usage patterns. I'll be surprised
if this shows up on any real-world application.
- anyone this concerned about that last 1-2% of performance will want
to recompiling their own kernel anyway to disable such things as
highmem support when not needed, or selinux, or 4g4g, or..
> And considering the
> complaints that I have seen, it would make even more sense to make a
> Pentium 4-optimized kernel available even if the Athlon one was not
> available.
As above. A seperate kernel is probably overkill.
Compiling the 686 kernel with gcc tunings for p4 (but no instructions)
might make sense however.
Dave
19 years, 4 months
samba: printer list is wrong
by Dario Lesca
Is this a issue of new version of samba or a my wrong configuraton (the
smb.conf is a standard file released whit samba) ?
[lesca@lesca lesca]$ smbclient -L printerone
Password:
Domain=[DOM] OS=[Unix] Server=[Samba 3.0.9-1.fc3]
Sharename Type Comment
--------- ---- -------
tmp Disk Temporary file space
pubblica Disk Cartella pubblica x Tutti
IPC$ IPC IPC Service (Samba Server Printerone)
ADMIN$ IPC IPC Service (Samba Server Printerone)
hp4000N Printer laser1
hp4050N Printer laser2
hp4200N Printer laser3
lasri1 Printer lasri1
............
Printer share name IS laser1, descri is hp4000N ecc...
I have other printers whit the same description (hp4000N) but whit
different name:
[lesca@sispay ~]$ lpstat -v
device for laser1: socket://laser1:9100/
device for laser2: socket://laser2:9100/
device for laser3: socket://laser3:9100/
device for laser4: socket://laser4:9100/
device for laser5: socket://laser5:9100/
device for laser6: socket://laser6:9100/
device for lasri1: socket://lasri1:9100/
[root@sispay lesca]# grep -B 1 Info /etc/cups/printers.conf
<DefaultPrinter laser1>
Info hp4000N
--
<Printer laser2>
Info hp4050N
--
<Printer laser3>
Info hp4200N
--
<Printer laser4>
Info hp4200N
--
<Printer laser5>
Info hp4050N
--
<Printer laser6>
Info hp4050N
--
<Printer lasri1>
Info hp4200N
Many thanks
--
Dario Lesca <d.lesca(a)solinos.it>
19 years, 4 months