I read these comments but they are from year 2004 and 2005. And the
propoced patch was in some of the 2.6.25-rc versions.
This is not an extra functionallity but the only option (for some
of us) to run linux on our laptops. The ACPI code is quite
difficult to play with, so I don't see any "nightmare waiting to
happen" here. If at the end there are so many bug reports connected
with DSDT, then just drop the patch again.
I don't see that much bug reports on opensuse, ubuntu and mandriva
complaining about a kernel panic based on broken dsdt. Maybe Dave
Jones should reconsider his opinion about it. Or at least try to
explain to the notebook producers that they should test their bios
to work with linux, too.
Fedora is supposed to be "on the bleeding edge". so i really don't
see any reasons against (at least trying to) inserting this patch
in some RCs. Lets see what'll happen. it is always possible to
revert the patch.
Click to get a free auto insurance quotes from top companies.
Some time ago, it was discussed on an LSB face-to-face meeting that an
API should be developed that allows ISVs to install sotware packages
which integrate into the package manager - the "Berlin Packaging API".
While the idea seemed to be well received, there didn't seem much
progress since then, except for a wiki page with a rundimentary proposal
. Considering that third-party software installation is an undeniably
important weak spot of the Linux infrastructure, I found this was a
To reignite the the initiative, I decided to design and develop a
prototype implementation of the Berlin API, most creatively named the
"LSB Package API". It is designed as a simple D-Bus interface
accompanied with an XML-based package description format. A detailed
description and the source code can be found on this page:
The implementation currently supports integration into RPM and dpkg; due
to its modular nature, support for more package managers could be added
I hope this implementation will act as a starting point for resurrecting
the Berlin API process. Let us overcome the "Third-party software
installation on Linux sucks" problem and strive to a brave new world of
easily distributable Linux software! ;)
I had a serios problems with my bios and at the end it was the dsdt
table that was broken. this gave me alot of kernel panics untill i
figured it out. Now I have to recompile the kernel every time a new
one goes out in order to put in my custom dsdt table and enable it.
this takes about 30 min and I cannot use any of the devel kernels.
There is, however, a kernel patch at gaugusch.at/kernel.shtml which
enables the kernel to load a custom dsdt table from the initrd. and
this is alot faster than the previous method with the kernel
Will it be possible for this patch to go in the mainstream fedora
Some other distros are using it and I don't see any reason why
fedora shouldn't use it either. I know this kind of tainting the
kernel is "dangerous" but it is the only way for user (like me)
with broken bios/dsdt table to run their kernels. And because lots
of bioses are tested only on windows there are no other way than
inserting a custom dsdt for linux.
Any sugestions or downsides of this method that can prove the
exclusion of this patch from the mainstream fedora kernel?
Internet Security Software - Click here.
> On Mon, 2008-06-23 at 21:55 -0400, Tom "spot" Callaway wrote:
> > As the "super-op" for all things Fedora/Red Hat IRC, I agree with
> > pretty much everything Kevin has said. I've been planning to write
> > an IRC "code of conduct" for some time, but I've not yet gotten
> > that far down my todo list.
> I would be more than willing to assist in working on the "code of
> conduct" with you. It has one thing that I would have liked to see
> from day one.
I think we could work on such at a meeting and then run it by spot for
> > A few things we should consider:
> > 1. Office hours. People who sign up to be "official" helpers during
> > a regular shift can get +v, making them easily identifiable to
> > people looking for help. We can document this in the topic (or in a
> > FAQ URL).
> I am willing to take shifts as both "Official Helper" and/or OP as
> needed. I am in #fedora almost every night between 6pm and 11pm EST,
> so it would not be much of an issue.
Yeah, me too. Hopefully we get enough people to pull things off.
> > 2. Auditing. It might not be a bad idea to put a very simple
> > logging bot in #fedora which just logs the channel text. This would
> > also help us track abuse in a more reliable way than how it is now
> > ("This guy is being abusive.")
> I think auditing would be great, as most of us who help and/or
> participate currently as ops already do logging just so we see what
> the hot-topics are, and to identify potential trouble makers in the
> channel. Also most of the current ops communicate regularly which
Yeah, also good.
> > We may need to take a look at who the ops are currently. Folks who
> > haven't been active or helpful may need to be replaced.
> There are a few of those such as corwyn who is no longer involved in
> fedora or fedora-unity/
Yeah, the list will need updating.
> > WRT bots, we just need to keep the noise level from any bots to a
> > bare minimum. Perhaps tie it into a user list so that helpers and
> > chanops can have it speak in channel, and all other queries go to
> > the user in privmsg.
> I see this as important as once people determine there is a bot in the
> channel tend to play with the bot to see what it can do.
Agreed. It shouldn't normally answer users on channel at least.
> Scott Glaser
> On Mon, 2008-06-23 at 17:15 -0500, Arthur Pemberton wrote:
> > That seems the most feasible solution to me. Java applets to connect
> > to an appropriate channel from the fedora website would also be
> > useful (to ease the barrier to entry)
> As one of the current OP's #fedora, I think that starting with a basic
> #fedora channel guideline would be the best way to start. Then the
> users would know what is tolerated and what is not, it would also
> cover guidelines for the OP's as far as code of conduct and what is
> grounds for a ban/kick including time frames for each.
Agreed. Perhaps we can draft something rough this week and polish it
over the next few.
> When I became and OP 2 years ago it was here you go your an OP now.
> This was done due to the lack of OPs at the time. Several of us were
> thrown into this position this way. Not a good way to start in the
> channel. It would have been nice to have a reference at that time.
> I am also one of the "Helpers" in the channel, I help many people to
> the best of my ability. I do know quite a bit as I have been running
> *nix since 1998 but I still have many things to learn. So I agree
> with the proposed training sessions.
> I am also one of the founders of Fedora Unity and the reason we set it
> up was to document many of the items that could not be covered in the
> Installation Guide due to legalities. I think we have done a pretty
> good job but it would be nice if we could do better.
> I am all for the the changes and believe it needs to start with
> guidelines first, all the other things could be implemented at a later
> time but the guidelines are needed NOW!! The guidelines would
> instantly improve the quality of the channel in short time.
Agreed again. It seems that's the priority for the SIG.
> Scott Glaser
> Fedora Unity
I needed to print through a network printer a few days ago. But it
doesn't just work. Seems like the firewall need to be stopped and
cups-config-daemon need to be started (not sure bout the latter, coz i
simply start all cups related services).
This raises a question, as Fedora turns on firewall by default, what's
the plan for certain user services that requires firewall to be turned
off (cups, gnome file sharing) ?? Something like PolicyKit but for
firewall??. Ubuntu took the easy way of simply disabling firewall, and
I doubt Fedora will follow that path.
Mohd Izhar Firdaus Bin Ismail
天野晃 「あまの ひかる」
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
-----BEGIN PGP SIGNED MESSAGE-----
unfortunately, the upstream author has no time to maintain the kyum
So I have to retired this package in the Fedora collection.
If anyone wnat to resurrecting this package, they have to overtake the
project from sourceforge.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
I'm currently adding support for pungi to gather debuginfo packages
based on the other packages it gathered. However I see things like the
kernel where there are subpackages that have their own debuginfo.
Having to search for these will greatly increase the amount of time it
takes pungi to discover all the appropriate debuginfo packages it should
have. Is there any other package anybody is aware of other than the
kernel that has subpackage specific debuginfo?
Fedora -- Freedom² is a feature!
> On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes <hughsient(a)gmail.com>
>> On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote:
>> > The distro model is nice (and arguably better than the LSB Package API)
>> > if the packages you like to have are in the repos in sufficiently new
>> > versions. But if you need to go past that (bleeding edge versions, not
>> > widely spread apps), things get more difficult currently. Especially
>> > propietary applications just cannot be distributed by the distros
>> > directly.
>> Right. These packages are compiled against system versions of libraries.
>> Do we choose the F9 or rawhide version of xulrunner to link against?
>> There's substantial API and ABI changes between distro versions for the
>> majority of shared libraries.
>> > I don't think this is a corner case at all. For one thing, propietary
>> > applications might just don't play a role _because_ there is no really
>> > good distribution method for them - the typical chicken-and-egg problem.
>> Incorrect. Most closed-source applications I have to use are installed
>> with an installer binary or script, which just smatters files on the
>> hard drive in /opt. There's just no need to register these with the
>> native system package manager as there are no updates repositories nor
>> dependency tracking required.>
> You you like an opinion on this, well, that it is mine. For example, look
> ad Oracle Client 11g
> application : it. as released with a tarball or so, have on it:
> - a full stack of perl
> - a full stack of shared library : glibc in primisis.
> So what have to do un poor packager manager with this ? Disable the deps
> and hope the best. Other, as MQ client, are released with RPM : with deps
> disabled anyway. But not all
> are equal : for example websphere. Sure it is tricky to package it but
> almost don't force me to disable the deps: I DON'T WANT DISABLE THE DEPS.
> IMHO, YMMV as usual
I've put together a small ncurses application for removing unnecessary
packages and their dependencies from the system.
In a mutt-like interface it allows to browse through dependencies,
select packages and run rpm -e on them.
For those who don't want to start under root some random stuff downloaded
from internet, it can be used under a regular user too. On exit, when
asked to not try to run rpm -e, it will write to stdout the list of
Review request filed here: