I think syslog-ng should probably be brought into Fedora Core to
In order to achieve that goal I've been told that making a good case for
why syslog-ng is beneficial to the distro needs to be added to this bug:
I'll be adding my own comments shortly, but if any of you have comments
to that regard please add them.
I'm only sending this to devel lists b/c using this release should be
for people who are:
1. comfortable with python tracebacks
2. comfortable with things breaking from time to time
3. comfortable with reporting bugs and using bugzilla.
So, with that in mind.
I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml-
based repository metadata (http://linux.duke.edu/metadata).
NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW
METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH
- all sorts of things, not the least of which is a huge percentage of
the code. :)
- I've not documented all the new things, if someone would like to
point out things, please, do so.
What's Known to be Broken:
- all the docs are wrong or somewhat wrong - if you want to know about
config variables read yum/config.py - that should be VERY clear
- all the groups functions do not work - they're just not hooked up
- all the clean functions do nothing
- the search and provides functions are not hooked up, either.
- when updating a kernel it will not make the new kernel the default
What's Known to Work:
What needs to be done:
- clean up some output
- group functions
- clean functions
- all sorts of goodies I've missed while writing infrastructure.
Where you get it:
Where you report bugs:
Where you send hatemail:
Either yum-devel list or fedora-devel-list.
Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in
a very odd way.
The current network configuration og the laptop I'm using, is a wireless
network card, and an normal network card (wirefull).
The funny thing is, that when i start the client on the wireless
interface, everything is fine, and everything works as it's supposed to.
If i then shifts to the wire, UDP packages suddently isn't comming
throug, but tcp connections work fine. That is, no name server
resolution, but I'm able to ping and access sites with the ip.
I know that the vpn client is Cisco's responsibility, but I thought I
would mention it to you, in case that it points to something gone bad in
the kernel. I have tried to do the same exercises with the -358 kernel
that ships with Fedora, and everything works in this kernel.
I hope this is of some use (And that a fix can be made :)
Ouuh... Everybody here has a six-pack, but all I've got is a keg...
I've been using FC2 and devel kernels for one of our dual-Opteron
systems and am very happy with recent improvements. Everything works
well for us including:
- AMD IDE interface
- tg3 driver (dual Broadcom BCM5704 GigE)
- 3w_9xxx driver (8-port 3ware SATA card)
The only request I have is that the following be added to the x86_64-SMP
I've been building custom kernels based on the testing SRPMs with just
this one small change and (for us at least) it works well on:
Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP
x86_64 kernels? I bow to the kernel experts, but it does appear to be a
reasonable default given the likelihood of SMP Opterons having more than
And I'll gladly add this to bugzilla if someone will recommend the best
topic for it.
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
Question: Shall Fedora Extras support ix86 optimized packages but
i386-compiled packages rsp. under shall circumstances shall Fedora
Extras support such packages?
Background: Some folks have started to add i686-built application
packages in addition to i386-built packages to Fedora Extras, claiming
these i686-built, "optimized packages" would result into much better
performance of these packages ("up to factor 2").
I'd rather prefer all packages to be built with RH/FC standard rpm
compilation flags (-march=i386 -mcpu=i686; rpmbuild --target=i386),
because this avoids a lot of the complexity and potential breakdowns of
shipping such "optimized packages" and to ship non-i386 packages only
where absolutely inevitable.
I.e. I'd like to Fedora Extras packaging policy to be extended to make
RH/FC's compilation flags mandatory to packages and to allow building
packages for other rpm-targets only in very rare exceptional cases.
For details of the discussion cf.
Registered Linux User #26 http://counter.li.org
I just put together a cheap Sempron system with an Abit VA-10 board
that has an onboard S3 Unichrome chipset. I installed FC2 and updated
to the latest rawhide hwdata, system-config-display, Xorg and kernel
system-config-display doesn't recognize the chipset at all and
suggests the VESA driver. Should I open a bug for this?
I edited xorg.conf and set it straight. X runs fine and 2D seems
accelerated but 3D is not. I thought Unichrome DRM had been merged
but I don't see a kernel module for it; is there any way to turn it
I'm quite happy that 2D is working; thanks to all who have made this
possible. A quick note, though: the video output on this board is
blurry and generally rather poor. I've tried several (Unichrome,
Intel, ProSavage) and have yet to find an onboard chipset that
produces reasonable video output.
00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01)
I'm using the 4.0.4.B-k9 version of the client. Downloading the latest
from Cisco didn't work either...
Denis Leroy wrote:
>Maybe i'm using a different version of vpnclient ? :
>>rpm -qf /usr/sbin/vpnclient
>--- "Kim B. Nielsen" <kbn(a)daimi.au.dk> wrote:
>>I've experienced my behaviour on two different laptops now. For some
>>reasen, the wireless has worked perfectly in both cases, but not the
>>The laptops are from two different manufacturers (Dell and IBM) So
>>somehow I don't think it's a unique problem related to one specific
>>laptop or network card.
>>Denis Leroy wrote:
>>>I'm also using the Cisco VPN client here at Sun, to connect my
>>>from home, but I'm not having the problem, for me things are
>>>correctly with the 521 kernel, at least on the wire (never quited
>>>worked with the wireless card though). Though i mainly use ssh, dns
>>>resolutions certainly work...
>>>--- "Kim B. Nielsen" <kbn(a)daimi.au.dk> wrote:
>>>>Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN
>>>>a very odd way.
>>>>The current network configuration og the laptop I'm using, is a
>>>>network card, and an normal network card (wirefull).
>>>>The funny thing is, that when i start the client on the wireless
>>>>interface, everything is fine, and everything works as it's
>>>>If i then shifts to the wire, UDP packages suddently isn't comming
>>>>throug, but tcp connections work fine. That is, no name server
>>>>resolution, but I'm able to ping and access sites with the ip.
>>>>I know that the vpn client is Cisco's responsibility, but I thought
>>>>would mention it to you, in case that it points to something gone
>>>>the kernel. I have tried to do the same exercises with the -358
>>>>that ships with Fedora, and everything works in this kernel.
>>>>I hope this is of some use (And that a fix can be made :)
>>>>Ouuh... Everybody here has a six-pack, but all I've got is a keg...
>>>>fedora-devel-list mailing list
>>"UNIX is user friendly, it's just selective about who its friends
>>fedora-devel-list mailing list
The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not
in FC3, callgrind is the actual calltree generating backend for
kcachegrind, while graphviz is used to draw the pretty calltree
Are there existing reasons why they are not in FC ? oversights or is
there licence issues, esp with graphviz ?
On Mon, 30 Aug 2004 14:37:11 +0100
Tim Waugh <twaugh(a)redhat.com> wrote:
> What on earth is /dev/uba? [...]
It's a block device driver for USB storage which I wrote recently.
Arjan enabled it in Rawhide, obviously to get reports such as yours.
> Buffer I/O error on device uba, logical block 2
> end_request: I/O error, dev uba, sector 6
> Buffer I/O error on device uba, logical block 3
> end_request: I/O error, dev uba, sector 48
> etc. etc.
For some reason hald sometimes loses its mind when it sees ub.
I have no idea what is happening. I run FC2 with updates, everything
seems operating normally when I debug ub. I did not see us shipping
device nodes for ub, so if hald manages to open ub, it must be creating
device nodes on the fly, by reading /proc/devices or /proc/partitions.
Userland is some crazy stuff these days...