rhgb no more
by Ray Strode
Hi guys,
One thing you will soon notice in F10 rawhide is that rhgb is no
longer around. We've blocked it and plan on replacing it for F10.
This is a continuation of our "BetterStartup" feature from a few
Fedoras ago (I would post a link but the wiki seems to be down). The
replacement for rhgb will be a mixture of two things:
1) Starting gdm as early as possible and fitting it to give boot
progress before asking for login. This is somewhat in line with the
early-login prototype feature some of you may remember from several
fedora releases ago.
2) Hiding boot messages before gdm unless escape key is pressed. For
graphics hardware that has drm modesetting, we'll be able to show some
sort of pretty graphics, and for everyone else we'll show a very
simple text mode progress.
Just a heads up,
Ray
15 years, 10 months
Re: Custom DSDT Table in the fedora kernel at boot time
by Joshua C.
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.
http://tagline.hushmail.com/fc/Ioyw6h4d8EIXAvwILUXMaz5GGa1ZtyyaAXI851HuaA...
15 years, 10 months
LSB Package API
by Denis Washington
Hi,
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
[1]. Considering that third-party software installation is an undeniably
important weak spot of the Linux infrastructure, I found this was a
shame.
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:
http://www.linuxfoundation.org/en/LSB_Package_API
The implementation currently supports integration into RPM and dpkg; due
to its modular nature, support for more package managers could be added
later on.
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! ;)
Best regards,
Denis Washington
[1] http://www.linuxfoundation.org/en/Berlin_Packaging_API
15 years, 10 months
Custom DSDT Table in the fedora kernel at boot time
by Joshua C.
Hello guys,
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
recompilation.
Will it be possible for this patch to go in the mainstream fedora
kernel?
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?
Cheers,
Joshua
--
Internet Security Software - Click here.
http://tagline.hushmail.com/fc/Ioyw6h4dJxHDn2puyZ3Jrv4LFpXqrJ3oKIWGfQomgs...
15 years, 10 months
Re: Fedora Support channels Improvement ideas
by Kevin Fenzi
> 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
correction/checkover.
> > 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
> helps.
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.
> V/R
>
> Scott Glaser
kevin
15 years, 10 months
Re: Fedora Support channels Improvement ideas
by Kevin Fenzi
> 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.
> V/R
>
> Scott Glaser
> Fedora Unity
kevin
15 years, 10 months
Firewall and user services that needs open ports
by Mohd Izhar Firdaus Ismail
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
Amano Hikaru
天野晃 「あまの ひかる」
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
15 years, 10 months
Package kyum retired.
by Jochen Schmitt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hallo,
unfortunately, the upstream author has no time to maintain the kyum
package.
So I have to retired this package in the Fedora collection.
If anyone wnat to resurrecting this package, they have to overtake the
upstream
project from sourceforge.net
Best Regards:
Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhf6iIACgkQT2AHK6txfgxmTwCfRH2hmboW6tz8TVICUDZVpSeA
PrkAnjSKbZguEiXqw1gMcDkWwWsatGWF
=8SLS
-----END PGP SIGNATURE-----
15 years, 10 months
debuginfo for subpackages
by Jesse Keating
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?
--
Jesse Keating
Fedora -- Freedom² is a feature!
15 years, 10 months
Re: LSB Package API
by devzero2000
> On Sun, Jun 22, 2008 at 11:00 PM, Richard Hughes <hughsient(a)gmail.com>
> wrote:
>
>> 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
>
15 years, 10 months