yum fails on kernel package update
by Josh Boyer
Anybody ever seen anything like what I have below? It only happens when
I am trying to update the kernel package. I doubt the box is really out of
memory... I haven't been able to update my kernel since 2.6.3-1.110.
josh
[root@localhost root]# yum -y -C update kernel*
Gathering header information file(s) from server(s)
Server: Fedora Core 1.90 - Development Tree
Finding updated packages
Downloading needed headers
Resolving dependencies
Dependencies resolved
I will do the following:
[install: kernel 2.6.3-1.118.i686]
[install: kernel-source 2.6.3-1.118.i386]
Downloading Packages
Running test transaction:
/etc/security/selinux/src/policy/file_contexts/file_contexts: No such file or
directory
memory alloc (4 bytes) returned NULL.
[root@localhost root]#
20 years, 2 months
rawhide report: 20040303 changes
by Build System
Removed package ICAClient
Updated Packages:
Omni-0.9.1-5
------------
* Tue Mar 02 2004 Tim Waugh <twaugh(a)redhat.com> 0.9.1-5
- Fix the foomatic data generator (bug #115586).
a2ps-4.13b-35
-------------
* Tue Mar 02 2004 Tim Waugh <twaugh(a)redhat.com> 4.13b-35
- Prevent "error: conflicting types for 'malloc'".
apr-util-0.9.4-10
-----------------
* Tue Mar 02 2004 Joe Orton <jorton(a)redhat.com> 0.9.4-10
- rename sdbm_* symbols to apu__sdbm_*
gnome-media-2.5.4-2
-------------------
* Tue Mar 02 2004 Alexander Larsson <alexl(a)redhat.com> 2.5.4-2
- fixed schemas list
gnome-panel-2.5.91-1
--------------------
* Tue Mar 02 2004 Mark McLoughlin <markmc(a)redhat.com> 2.5.91-1
- Update to 2.5.91
- Split off a -devel package (#108618)
- Add a scrollkeeper PreReq and scrollkeeper, intltool and
libpng-devel BuildRequires. (#110928, Maxim Dzumanenko)
gqview-1.4.1-1
--------------
* Tue Mar 02 2004 Dams <anvil[AT]livna.org> 1.4.1-1
- Fixed configure Xinerama.h checking (with patch)
* Mon Mar 01 2004 Warren Togami <wtogami(a)redhat.com> 1.4.0-1
- upgrade to 1.4.0
- massive spec cleanup, BuildRequires, etc.
hwdata-0.110-1
--------------
* Mon Mar 01 2004 Mike A. Harris <mharris(a)redhat.com> 0.110-1
- Added 3Dfx Voodoo Graphics and Voodoo II entries to the Cards database, both
pointing to Alan Cox's new "voodoo" driver which is now included in XFree86
4.3.0-62 and later builds in Fedora development. Mapped their PCI IDs to
the new Cards entry in pcitable.
- Updated the entries for 3Dfx Banshee
redhat-artwork-0.93-1
---------------------
* Tue Mar 02 2004 Alexander Larsson <alexl(a)redhat.com> 0.93-1
- Fix shuttle in cursor theme
- Remove redhat-main-menu icon
- Rename redhat-config-* icons to system-config-*
- Fix multihead issue in gtk2 theme
rpm-4.3-0.14
------------
* Sun Feb 22 2004 Jeff Johnson <jbj@jbj,org> 4.3-0.14
- add ia32e arch.
- stable sort for policy specifications, patterns before paths.
- set "rpm_script_t" exec type for scriptlets iff /bin/sh, else default.
- force FD_CLOEXEC on 1st 100 inherited fdno's.
* Fri Feb 20 2004 Jeff Johnson <jbj(a)jbj.org> 4.3-0.13
- fix: only first "mkdir -p" directory had context set.
* Wed Feb 18 2004 Jeff Johnson <jbj(a)redhat.com> 4.3-0.12
- python: add patch to rpm-4_3 to initialize RE contexts.
rpmdb-fedora-1.90-0.20040303
----------------------------
20 years, 2 months
Re: package shepherding
by Jef Spaleta
Mark McLoughlin wrote:
> Yeah, I can appreciate that - I'm still figuring it out too. It
> would be good though if we could have a general
> "bugzilla.redhat.com policy" doc or something. Would you have the >
time to start compiling that?
No, I don't have time, but its near the top of the list of things i
don't have time for. I'm desperately in search for a sucker..err
volunteer that is interested in producing documentation, so I don't
have to keep pretending like i know what I'm doing. And I think,
considering how things are actually developing, it probably a stretch to
call any document of this sort that i might write "policy" in the sense
that developers are actually going to be encouraged by leadership to
follow what's written. At best its more like "Jef's bugzilla for
dummies" or "Jef's fireside bugzilla ghost stories" as a companion piece
to "Jef's 12 easy steps to applying cat herding techniques to open
source developer management"
> e.g. we were discussing today on irc whether its valid to mark a
> RHEL bug as a dup of a Fedora bug. The conclusion we came to was:
You are going to hate me, as much as I like see exactly this sort of
discussion, and I'm more than happy to take the fruits of discussion
that I'm not actively involved with(I'm an invented anywhere but by me
sort of person)...its very difficult to actually keep track with nuggets
of information like this if I have to pick them up from the
fedora-devel-list. I will lose track of them in the noise on the list,
guaranteed. I'd tell you to subscribe to the not really used triage
list and post there but I don't know if you really want to be a part of
yet another list...so if you really want to make sure I see this sort of
discussion about what to do about classes of bugs it might be best for
you to email me directly with a clever topic that i can filter, like
"Fedora Triage: much ado about RHEL bugs or other such descriptive
text".
> <markmc> if its sufficient to be fixed in a future release
> <markmc> mark it as a dup
> <markmc> if it needs to be fixed now, then leave it open
> <markmc> and include a link to the dup
These are the sort of judgement calls that are difficult to codify.
And really require active discussion between package maintainer and the
triagers who want to help with a specific package. Don't really want to
encourage a situation where a triager is deciding what should and should
not be fixed now without feedback from the maintainer, and conversely
don't want to encourage a situation where a triager is demanding a
significant amount of time from developers
to get feedback about whether or not a collection of bugs are close now
or keep open. As guidance for developers and package maintainers this
makes sense. As guidance for triagers looking to help maintainers, this
is probably not something i want to start with.
-jef
20 years, 2 months
In the service of Aunt Tillie -- Zero-configuration networking
by Eric S. Raymond
There has been much discussion recently on the Fedora mailing list
about how to improve Linux's ease of use in scenarios like printer
setup. (Thank you, everyone, for picking up on the content of my rant
so constructively when you very well might have dismissed it as
carping.)
I have just become aware of a technology which could represent a long
step towards addressing the usability problem. It is a set of small
patches to the IP infrastructure that support zero-configuration
networking -- you just plug in an IP-capable device and it
self-configures an IP address, becomes available in a local DNS
namespace, and other devices automatically discover its presence
and the services it offers.
This technology is called "zeroconf", and is described at
http://zeroconf.org. The first component of Zeroconf, self-assigned
link-local addresses, has been shipping since Mac OS 8.5 in 1998,
and the other two components, Multicast DNS and Service Discovery,
shipped starting in OS X 10.2, a year and a half ago. Since then
almost every maker of IP-over-Ethernet-capable printers printers
has adopted Zeroconf and incorporated it into their firmware, and
just about any network printer you can buy today has it. There is
a mature open-source implementation which is part of the Darwin/OS X
codebase.
The zeroconf stuff uses existing services like DHCP and DNS if they
exist -- and, just as importantly, doesn't mess them up when you plug
a zeroconf-enabled device into a normal, manually-configured network
-- but it doesn't need them. It uses a few simple, clever
multicasting tricks and a technique for detecting IP address
collisions. The total volume of code is not large, basically
consisting of one zeroconf responder daemon and a handful of small
patches to other services. Less than 100K all told, and that's
*with* multihoming and IPv6 and all the bells and whistles.
The effect is a lot like the Chooser application on the Mac (this is
not accidental; zeroconf was written to replicate Chooser's behavior
in a TCP/IP world). You plug Ethernet cables together and stuff just
works -- no more complicated ritual dances with ifconfig, DHCP, and
DNS. Your IP-enabled devices even magically appear in your DNS
namespace, with a DNS name ending in ".local". Home networks using
Linux would become zero-administration; Aunt Tille would love it.
The inventor of zeroconf, Stuart Cheshire, tells me the technical
problems are all solved and the solutions well tested, but he doesn't
understand the politics of getting the Linux community to generally
adopt zeroconf. He's anxious to help.
I suggest that full integration of zeroconf should be added to Fedora's
to-do list. For this to actually happen, somebody will need to step
forward and become zeroconf's champion. Any volunteers?
The source code (which already runs on Linux -- just do a "make
os=linux; sudo make install") can be checked out from Apple's Darwin
repository. Check out top-of-tree; Stuart tells me the tarball is a
little out of date doesn't contain the latest fixes:
<http://developer.apple.com/darwin/projects/rendezvous/>
The documentation in the mDNSPosix folder should be fairly clear. If not,
Stuart Cheshire requests that you email him <cheshire(a)apple.com> and Marc
Krochmal <marc(a)apple.com> with any questions, or you can ask on the
public Rendezvous list:
<http://lists.apple.com/mailman/listinfo/rendezvous>
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Let us hope our weapons are never needed --but do not forget what
the common people knew when they demanded the Bill of Rights: An
armed citizenry is the first defense, the best defense, and the
final defense against tyranny.
If guns are outlawed, only the government will have guns. Only
the police, the secret police, the military, the hired servants of
our rulers. Only the government -- and a few outlaws. I intend to
be among the outlaws.
-- Edward Abbey, "Abbey's Road", 1979
20 years, 2 months
FreeWnn Status?
by Keith G. Robertson-Turner
I'm doing a package audit, and I'm trying to track down specific reasons
for various packages being depreciated over the years.
FreeWnn is currently in FC1, but there are other associated packages which
seem to have disappeared after RH8, specifically cWnn, kWnn, and tWnn.
I read the RH9 release notes, and spent around an hour googling for the
above packages, but could find nothing explaining why they have gone.
Can anyone shed any light on this?
Yes, I know nothing about xWnn stuff, so there may be an embarrassingly
obvious reason ;-)
Thanks,
-
K.
20 years, 2 months
Re: atmel drivers in the main distro?
by Martin Sevior
> Date: Tue, 2 Mar 2004 12:32:00 -0600
> From: Steven Pritchard <steve(a)silug.org>
> To: fedora-devel-list(a)redhat.com
> Subject: Re: atmel drivers in the main distro?
> Reply-To: fedora-devel-list(a)redhat.com
>
> On Wed, Mar 03, 2004 at 03:30:50AM +1100, msevior(a)physics.unimelb.edu.au
> wrote:
>> Is there a reason the atmel wireless drivers are not distributed with
>> the
>> main Fedora disto?
>
> There are a lot of wireless drivers that aren't integrated into the
> kernel. I'd suggest bugging the upstream developers about getting
> their driver into Linus's tree.
>
> In the mean time, there are other open-source wireless drivers in
> fedora.us QA (at least my kernel-module-hostap package and a
> kernel-module-prism54 package I noticed yesterday). I'd love to see
> more. (Actually, I'd love to see the existing ones make it through QA
> even more. :-)
>
> Steve
It certainly makes sense for the these to be rolled into the 2.4 and 2.6
kernels.
So what the best route to do this? How do I let whoever know that the
atmel drivers WorksForMe?
I also think these should be put into whatever Kernel Fedora is rolling
for FC 2. Since this is RedHat's perogative, I'll happily email the person
doing this if (s)he isn't reading this list or missed my post.
Cheers
Martin
20 years, 2 months
mount & cfs
by Jurgen Botz
The most recent versions of mount (util-linux-2.12-4 from
fedora/core/development) seem to break Matt Blaze's cfs
<http://www.crypto.com/software/>. I get the following
error...
mount: failed to probe ports on NFS server localhost
I'll try blindly hacking at the probe bits in nfsmount.c to
see if I can learn more, but meanwhile I thought I should
report this.
:j
--
Jürgen Botz | While differing widely in the various
jurgen(a)botz.org | little bits we know, in our infinite
| ignorance we are all equal. -Karl Popper
20 years, 2 months
Fedora for IA-64
by Lucas Peetz Dulley
Hi everyone,
Now that I have installed RedHat AS 3 BETA for IA64 (only "free" distro
I was able to successfully install) I know that my Itanium2 machine is
working :)
I'm gonna start porting fedora to IA64 if no one is against it...
But before anything else I would like to know what is procedure for
becoming a fedora-developer: what are the requirements? what info should
I provide? how do I submit the work I have done? etc...
Thanks.
--
Lucas Peetz Dulley <dulley(a)lsi.usp.br>
Virtual Reality Center - CAVERNA Digital
LSI - POLI - USP Tel: +55-11-3091-5374
Av. Prof. Luciano Gualberto, 158 trav. 3
CEP: 05508-900 - Sao Paulo - SP - Brazil
20 years, 2 months
Wireless keyboard and Fedora
by Daniel Clemente Roman
Hi
I am going to buy a wireless keyboard, such a Logitech Corless Desktop
Deluxe (Keyboard + mouse)
Anyone have this?, and it work fine with fedora?
Thanks
-----------------------------------------------------------------------
Edición Limitada del nuevo disco de David Bisbal: Bulería. Consíguelo
con un 18% de decuento, solo por 15,50
http://www.eresmas.com/banners/promo.html?zanox
20 years, 2 months
Self-Introduction: Michel Blanc
by Michel Blanc
1. Full Legal Name: Michel Blanc
2. Country, City: Saint Clément les Places, France
3. Profession: Network Engineer
4. Company: Département du Rhône
5. Goals in the Fedora Project
Maintain the pikt specfiles
Do you want to do QA : yes (network stuff)
6. Historical qualifications
Other projects : Worked on PIKT (http://pikt.org) developping add-ons
and packaging for several rpm based distros.
Languages : Perl, PHP, few forgotten ones
Skills : {network,system} administration
7. GPG KEYID and fingerprint
pub 1024D/24B35C22 2003-06-11 Michel Blanc <mblanc(a)erasme.org>
Empreinte de la clé = FA67 4EDA D648 9E50 BFA4 3F29 FDF5 4971 24B3 5C22
sub 1024g/2EA26768 2003-06-11
sub 1536R/45CB76FC 2004-01-19
sub 1536R/0DBFDFA7 2004-01-19
M
--
Michel Blanc
Systemes/Reseaux Erasme
Erasme/CG69/Saint Clement les Places/FR69930
T 0474706840/mblanc(a)erasme.org
20 years, 2 months