12:01 a.m.
Well, it's long overdue, but here's something.
Posted at http://fedora.redhat.com/participate/schedule/
is a preliminary draft of a schedule for Fedora Core 3, reproduced
below. (Please ignore the GNOME 2.6 typo in the online version;
that will be corrected.)
Obviously, a schedule doesn't say much about what's in it.
Here at Red Hat we're working on various things for Fedora Core 3:
- GCC 3.4 - those that have looked at rawhide will have noticed this
- GNOME 2.8
- KDE 3.3
- SELinux, yet again. This includes a new 'targeted' policy that
monitors specifc daemons with less intrusion than the strict
policy in use before.
https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096...
- IIIMF - continued evolution of the new input framework
- Indic language support
- Various desktop-related features, including, but not limited to:
- Pango support for Mozilla
- Remote desktops using VNC
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
- Printing improvements
http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00370.html
- Evolution 2.0
And, random other stuff, of course.
I'm sure there's other stuff people would like to see. What sorts
of things?
Bill
PRELIMINARY Fedora Core 3 Schedule
This schedule is preliminary; it may be modified at any time.
Test users should continue to file bug reports against each test release
even after we have frozen for the next test release; all feedback is
helpful.
+------------------------------------------------------------------------+
| Day | Month | Event |
|-----+-------+----------------------------------------------------------|
| 12 | July | test1 |
|-----+-------+----------------------------------------------------------|
| | | String change deadline (data provided) |
| 25 | Aug | New major version slush (will be exceptions, like GNOME |
| | | 2.8) |
| | | test2 devel freeze |
|-----+-------+----------------------------------------------------------|
| 6 | Sept | test2, string build freeze (builds completed) |
|-----+-------+----------------------------------------------------------|
| 16 | Sept | Translation deadline (data provided) |
| | | test3 devel freeze |
|-----+-------+----------------------------------------------------------|
| 27 | Sept | test3, translation build freeze (builds completed) |
|-----+-------+----------------------------------------------------------|
| | ... | Continual freeze, only critical bugs fixed until release |
|-----+-------+----------------------------------------------------------|
| 6 | Oct | Absolute devel freeze |
|-----+-------+----------------------------------------------------------|
| 13 | Oct | Export approval, mirror master populated by EOD |
|-----+-------+----------------------------------------------------------|
| 14 | Oct | Release to mirrors (morning) |
|-----+-------+----------------------------------------------------------|
| 18 | Oct | Release open, announced |
+------------------------------------------------------------------------+
12:33 a.m.
I'm sure there's other stuff people would like to see. What
sorts
of things?
I'm sure most of this will be included in gnome 2.8. But things I would
like to see:
- Better integration between evolution-data-server and gnome-desktop
- Project Utopia is making huge steps with HAL and D-Bus. would love to
see that included
- Totem
- Mono
- eclipse
Just suggestions. :)
--
Scott Sloan <devscott(a)charter.net>
12:48 a.m.
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
And, random other stuff, of course.
Full udev support?
Please? Pretty please?
What, do you expect me to go and get the whole community to adopt a
common device naming standard first before you will do this?
{sigh}
greg k-h
3:41 a.m.
On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote:
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
>
> And, random other stuff, of course.
Full udev support?
Please? Pretty please?
What, do you expect me to go and get the whole community to adopt a
common device naming standard first before you will do this?
Can you give feedback on what changes you would like to see to the
current fedora development rpm?
Thanks a lot,
Florian La Roche
4:03 a.m.
On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote:
On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote:
> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
> >
> > And, random other stuff, of course.
>
> Full udev support?
>
> Please? Pretty please?
>
> What, do you expect me to go and get the whole community to adopt a
> common device naming standard first before you will do this?
Can you give feedback on what changes you would like to see to the
current fedora development rpm?
Use it to manage /dev and not /udev?
Make it required?
If this has been changed, I apologize, the last version I looked at did
not.
thanks,
greg k-h
4:31 a.m.
Greg KH wrote:
On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote:
>On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote:
>
>>On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
>>
>>>And, random other stuff, of course.
>>
>>Full udev support?
>>
>>Please? Pretty please?
>>
>>What, do you expect me to go and get the whole community to adopt a
>>common device naming standard first before you will do this?
>
>Can you give feedback on what changes you would like to see to the
>current fedora development rpm?
Use it to manage /dev and not /udev?
udev-026-04 does that ... (development tree)
Make it required?
If this has been changed, I apologize, the last version I looked at did
not.
thanks,
greg k-h
--
Harald Hoyer, Senior Software Engineer <harald(a)redhat.com>
gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542
http://haraldhoyer.blogspot.com http://people.redhat.com/harald
Red Hat GmbH : http://www.redhat.de
4:44 a.m.
Make it required?
There are many items that users should be able to choose:
some people want to scan all their devices
at bootup, some don't. E.g. mainframe people say they
want to scan for VOLSER (volumne serial numbers) of
their devices for backups, but I am sure in certain
environments you don't want to scan all devices and
rather just want to have a fast bootup and work with
the "old-style" devices.
It is user choice to enable this and use the benefits,
but should not become a requirement for installations.
We do look forward to improve our udev package.
Some additional config could go in, but stay disabled
per default. Maybe some other could be added that are
enabled by default.
greetings,
Florian La Roche
1:16 p.m.
Florian La Roche wrote:
It is user choice to enable this and use the benefits,
but should not become a requirement for installations.
We do look forward to improve our udev package.
Some additional config could go in, but stay disabled
per default. Maybe some other could be added that are
enabled by default.
How about on by default, and able to be disabled by the user?
That will get the bugs out much faster than anything else.
3:50 a.m.
On Fri, 2 Jul 2004 19:03, Greg KH <greg(a)kroah.com> wrote:
On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote:
> Can you give feedback on what changes you would like to see to the
> current fedora development rpm?
Use it to manage /dev and not /udev?
Make it required?
What if we make udev required for all dynamic creation of device nodes?
Having devices such as /dev/mapper/control being dynamically created through
shell scripts such as /etc/rc.d/rc.sysinit and programs such as "nash" does
not make any sense to me when udev seems perfectly designed for the task.
Making it mandatory for LVM users to also use udev does not seem like a
disadvantage to me.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
4:12 a.m.
On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote:
On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote:
> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
> >
> > And, random other stuff, of course.
>
> Full udev support?
>
> Please? Pretty please?
>
Me too.
> What, do you expect me to go and get the whole community to
adopt a
> common device naming standard first before you will do this?
Can you give feedback on what changes you would like to see to the
current fedora development rpm?
It would be nice if at least udevstart was called at installation
and/or boot time, I've filed bug 120605 on this some time ago. This
is kind of blocking the Utopia bits - you have to run udevstart
manually when using J5 packages.
Having a minimal /dev would be nice as well.
Many thanks,
David
4:40 a.m.
David Zeuthen wrote:
On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote:
>On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote:
>
>>On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
>>
>>>And, random other stuff, of course.
>>
>>Full udev support?
>>
>>Please? Pretty please?
>>
Me too.
>>What, do you expect me to go and get the whole community to adopt a
>>common device naming standard first before you will do this?
>
>Can you give feedback on what changes you would like to see to the
>current fedora development rpm?
>
It would be nice if at least udevstart was called at installation
and/or boot time, I've filed bug 120605 on this some time ago. This
is kind of blocking the Utopia bits - you have to run udevstart
manually when using J5 packages.
attached a patch for rc.sysinit to bug 120605
Having a minimal /dev would be nice as well.
Many thanks,
David
--
Harald Hoyer, Senior Software Engineer <harald(a)redhat.com>
gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542
http://haraldhoyer.blogspot.com http://people.redhat.com/harald
Red Hat GmbH : http://www.redhat.de
8:50 a.m.
So is this patch going to make my laptop take 2 minutes to run udevstart
like it already does?
Dan
On Fri, 2004-07-02 at 11:40 +0200, Harald Hoyer wrote:
> It would be nice if at least udevstart was called at
installation
> and/or boot time, I've filed bug 120605 on this some time ago. This
> is kind of blocking the Utopia bits - you have to run udevstart
> manually when using J5 packages.
attached a patch for rc.sysinit to bug 120605
8:53 a.m.
Followup: I just ran it on a dual Xeon 2.4 with 1GB of RAM, and it took
1:30m to start. What's being done to speed this up? If udevstart gets
run on startup, its probably going to be an unacceptable startup speed
hit to many users.
On Fri, 2004-07-02 at 09:50 -0400, Dan Williams wrote:
So is this patch going to make my laptop take 2 minutes to run
udevstart
like it already does?
Dan
On Fri, 2004-07-02 at 11:40 +0200, Harald Hoyer wrote:
> > It would be nice if at least udevstart was called at installation
> > and/or boot time, I've filed bug 120605 on this some time ago. This
> > is kind of blocking the Utopia bits - you have to run udevstart
> > manually when using J5 packages.
>
> attached a patch for rc.sysinit to bug 120605
11:53 a.m.
On Fri, Jul 02, 2004 at 09:53:44AM -0400, Dan Williams wrote:
Followup: I just ran it on a dual Xeon 2.4 with 1GB of RAM, and it
took
1:30m to start. What's being done to speed this up? If udevstart gets
run on startup, its probably going to be an unacceptable startup speed
hit to many users.
What is causing udevstart to take so long on your machine? On my dinky
little laptop it runs in less than 3 seconds. Odds are it's the rules
that you are using. Care to post the rules file?
thanks,
greg k-h
12:11 p.m.
On Fri, 2004-07-02 at 09:53 -0700, Greg KH wrote:
What is causing udevstart to take so long on your machine? On my
dinky
little laptop it runs in less than 3 seconds. Odds are it's the rules
that you are using. Care to post the rules file?
Sure. I'm running J5 packages, all up to date.
Dan
6:10 p.m.
On Fri, Jul 02, 2004 at 01:11:09PM -0400, Dan Williams wrote:
On Fri, 2004-07-02 at 09:53 -0700, Greg KH wrote:
> What is causing udevstart to take so long on your machine? On my dinky
> little laptop it runs in less than 3 seconds. Odds are it's the rules
> that you are using. Care to post the rules file?
Sure. I'm running J5 packages, all up to date.
I don't see anything odd in there. Do you have dm device nodes? That's
the only thing that could cause an external program to be started, and
udev has no control over how long that takes.
thanks,
greg k-h
11:17 a.m.
On Fri, 2004-07-02 at 13:11 -0400, Dan Williams wrote:
On Fri, 2004-07-02 at 09:53 -0700, Greg KH wrote:
> What is causing udevstart to take so long on your machine? On my dinky
> little laptop it runs in less than 3 seconds. Odds are it's the rules
> that you are using. Care to post the rules file?
Sure. I'm running J5 packages, all up to date.
Ugh, it's my fault then. The J5 packages includes hal, look at [1]. I
know why this happens too, working on a fix, stay tuned.
Thanks,
David
[1] :
[root@ixus root]# tree /etc/dev.d/
/etc/dev.d/
|-- default
| |-- hal.dev -> /usr/libexec/hal.dev
| |-- pam_console.dev
| `-- selinux.dev
`-- net
`-- hotplug.dev
2 directories, 4 files
[root@ixus root]# time udevstart
real 1m37.199s
user 0m2.015s
sys 0m3.292s
[root@ixus root]# mv /etc/dev.d/default/hal.dev /tmp
[root@ixus root]# tree /etc/dev.d/
/etc/dev.d/
|-- default
| |-- pam_console.dev
| `-- selinux.dev
`-- net
`-- hotplug.dev
2 directories, 3 files
[root@ixus root]# time udevstart
real 0m4.725s
user 0m1.787s
sys 0m2.955s
12:28 p.m.
On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote:
Full udev support?
Please? Pretty please?
Yeah.
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118861>
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
12:36 p.m.
Greg KH (greg(a)kroah.com) said:
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
>
> And, random other stuff, of course.
Full udev support?
Please? Pretty please?
What, do you expect me to go and get the whole community to adopt a
common device naming standard first before you will do this?
The problem is more or less this:
- Without a new device naming standard that offers persistent names,
what really does it gain you?
I'm not averse to using it, but if you're not changing the device
names, most of the useful functionality could be done just by
using the dev.d callouts without actually having udev manage
/dev.
Bill
2:55 p.m.
On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote:
Greg KH (greg(a)kroah.com) said:
> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
> >
> > And, random other stuff, of course.
>
> Full udev support?
>
> Please? Pretty please?
>
> What, do you expect me to go and get the whole community to adopt a
> common device naming standard first before you will do this?
The problem is more or less this:
- Without a new device naming standard that offers persistent names,
what really does it gain you?
I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's
just me :)
And I'm trying to move toward getting such a standard, but the people
who are supposed to be taking the next step, seem to have disappeared
again.
Time to go kick some DCL[1] members around again...
I'm not averse to using it, but if you're not changing the
device
names, most of the useful functionality could be done just by
using the dev.d callouts without actually having udev manage
/dev.
That's a good point, and should be worthy of allowing udev to be
installed by default. That way things like HAL and gnome-vfs can still
work properly, as they chain off of those callouts.
thanks,
greg k-h
[1] Data Center Linux project from OSDL:
http://www.osdl.org/lab_activities/data_center_linux/
of which Red Hat is a member, but doesn't seem to be taking an
active interest in :(
3:32 p.m.
Greg KH (greg(a)kroah.com) said:
> The problem is more or less this:
>
> - Without a new device naming standard that offers persistent names,
> what really does it gain you?
I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's
just me :)
And I'm trying to move toward getting such a standard, but the people
who are supposed to be taking the next step, seem to have disappeared
again.
Time to go kick some DCL[1] members around again...
Well, I'm not sure that the need for new, persistent, device names
is necessarily driven by DCL requirements (or CGL, for that matter.)
But that's a different issue. :)
Bill
6:09 p.m.
On Fri, Jul 02, 2004 at 04:32:45PM -0400, Bill Nottingham wrote:
Greg KH (greg(a)kroah.com) said:
> > The problem is more or less this:
> >
> > - Without a new device naming standard that offers persistent names,
> > what really does it gain you?
>
> I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's
> just me :)
>
> And I'm trying to move toward getting such a standard, but the people
> who are supposed to be taking the next step, seem to have disappeared
> again.
>
> Time to go kick some DCL[1] members around again...
Well, I'm not sure that the need for new, persistent, device names
is necessarily driven by DCL requirements (or CGL, for that matter.)
It's not driven by it at all. But it did fall out of them. So osdl
created the device_naming mailing list for all of us to try to figure it
all out. Hopefully suse comes back with a revised proposal in a decent
ammount of time.
thanks,
greg k-h
4:49 p.m.
On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote:
On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote:
> I'm not averse to using it, but if you're not changing the device
> names, most of the useful functionality could be done just by
> using the dev.d callouts without actually having udev manage
> /dev.
That's a good point, and should be worthy of allowing udev to be
installed by default. That way things like HAL and gnome-vfs can still
work properly, as they chain off of those callouts.
Basically, yes... and that then makes for a much smaller and simpler
udev. nanodev :) Basically, just the callouts so that HAL can be made
happy and you have a nice static /dev.
None of the complicated "which ruleset and set of shell scripts do I
need to run", etc. Makes things far more predictable, lower impact and
actually gives the real benefit that people are wanting to take
advantage of without the more controversial bits.
Jeremy
3:18 a.m.
On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote:
On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote:
> On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote:
> > I'm not averse to using it, but if you're not changing the device
> > names, most of the useful functionality could be done just by
> > using the dev.d callouts without actually having udev manage
> > /dev.
>
> That's a good point, and should be worthy of allowing udev to be
> installed by default. That way things like HAL and gnome-vfs can still
> work properly, as they chain off of those callouts.
Basically, yes... and that then makes for a much smaller and simpler
udev. nanodev :) Basically, just the callouts so that HAL can be made
happy and you have a nice static /dev.
None of the complicated "which ruleset and set of shell scripts do I
need to run", etc. Makes things far more predictable, lower impact and
actually gives the real benefit that people are wanting to take
advantage of without the more controversial bits.
Wow, 58kb is too big for you? :)
Sure, I could strip udev down to something even smaller like what you
mentioned, but I don't think it will be worth it to anyone, as you can
operate udev in that same mode today with no changes needed to it.
thanks,
greg k-h
1:21 p.m.
On Thu, 2004-07-08 at 01:18 -0700, Greg KH wrote:
On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote:
> On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote:
> > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote:
> > > I'm not averse to using it, but if you're not changing the device
> > > names, most of the useful functionality could be done just by
> > > using the dev.d callouts without actually having udev manage
> > > /dev.
> >
> > That's a good point, and should be worthy of allowing udev to be
> > installed by default. That way things like HAL and gnome-vfs can still
> > work properly, as they chain off of those callouts.
>
> Basically, yes... and that then makes for a much smaller and simpler
> udev. nanodev :) Basically, just the callouts so that HAL can be made
> happy and you have a nice static /dev.
>
> None of the complicated "which ruleset and set of shell scripts do I
> need to run", etc. Makes things far more predictable, lower impact and
> actually gives the real benefit that people are wanting to take
> advantage of without the more controversial bits.
Wow, 58kb is too big for you? :)
Binary size does not alone dictate complexity. And that's with a
completely separate libc from everything else in the world which then
also includes kernel headers for building? This does not count as small
and simple in my world.
Sure, I could strip udev down to something even smaller like what
you
mentioned, but I don't think it will be worth it to anyone, as you can
operate udev in that same mode today with no changes needed to it.
Except that with the _ability_ to do so, people think that's how they
should be doing it and then you end up needing to be able to pull
anything into an early boot environment. This is especially the case
since all of these little utilities are part of udev.
Why not have udev just be the bit for the callouts and then both HAL and
some dynamic-deviced hook into it? (And then static dev is still a
perfectly reasonable alternative instead of having udev dictate a policy
of dynamic /dev ;)
Jeremy
2:08 p.m.
On Thu, 2004-07-08 at 14:21 -0400, Jeremy Katz wrote:
On Thu, 2004-07-08 at 01:18 -0700, Greg KH wrote:
> On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote:
> > On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote:
> > > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote:
> > > > I'm not averse to using it, but if you're not changing the
device
> > > > names, most of the useful functionality could be done just by
> > > > using the dev.d callouts without actually having udev manage
> > > > /dev.
> > >
> > > That's a good point, and should be worthy of allowing udev to be
> > > installed by default. That way things like HAL and gnome-vfs can still
> > > work properly, as they chain off of those callouts.
> >
> > Basically, yes... and that then makes for a much smaller and simpler
> > udev. nanodev :) Basically, just the callouts so that HAL can be made
> > happy and you have a nice static /dev.
> >
> > None of the complicated "which ruleset and set of shell scripts do I
> > need to run", etc. Makes things far more predictable, lower impact and
> > actually gives the real benefit that people are wanting to take
> > advantage of without the more controversial bits.
>
> Wow, 58kb is too big for you? :)
Binary size does not alone dictate complexity. And that's with a
completely separate libc from everything else in the world which then
also includes kernel headers for building? This does not count as small
and simple in my world.
> Sure, I could strip udev down to something even smaller like what you
> mentioned, but I don't think it will be worth it to anyone, as you can
> operate udev in that same mode today with no changes needed to it.
Except that with the _ability_ to do so, people think that's how they
should be doing it and then you end up needing to be able to pull
anything into an early boot environment. This is especially the case
since all of these little utilities are part of udev.
Why not have udev just be the bit for the callouts and then both HAL and
some dynamic-deviced hook into it? (And then static dev is still a
perfectly reasonable alternative instead of having udev dictate a policy
of dynamic /dev ;)
Oh, please don't mix the 'low-level' udev with the recent desktop stuff.
I personally would draw a strong line between both environments. We need
to care about both. Isn't it more you, that wants to 'dictate', than the
ability to put rules in udev? :)
The creation of udev was mainly motivated as a replacement for devfs and
works pretty well as that. I spent many night to get all the stuff
working with klibc and the ability to run CALLOUTS even without _any_
shell present on the system. :)
The convincing point and the main goal of udev was and is to abstract
the kernel device enumeration from the users view of the devices. During
the creation of udev, we had contact to the guys at OSDL who are
managing boxes with several hundreds of hard disks. They seemed pretty
happy with the architecture and the scsi_id callout. You will never be
able to do something similar, without it.
Ok, I only have 3 boxes with just one disk each, but I'm really happy,
that I can connect a USB-storage device to my server for backup and it's
everytime the same dev-node, which is in hard coded in fstab. It works
pretty well and is far from 'bloat'.
The HAL and desktop stuff is a complete different area. In the near
future, no average desktop user will need to know anything about device
nodes. HAL will handle this for you.
We still have, and probably will have these two worlds forever. I'm
happy with the picture, HAL draws for the desktop, but I still use
shell-script to do my backups, even for my notebook and it's pretty nice
to have a reliable way to match my devices and create the corresponding
node with a stable name, so the scripts can just catch it.
udev is the 'bridge' between these two worlds, we intentionally removed
the dbus stuff from udev, for this reason. Any higher level application
should use the information available from HAL, but things like bus-
devices connected to a headless box, are clearly the field for udev and
it's nice not to rely on several daemons to do a simple task like this.
What exactly is the problem, you are talking about? Please come back to
a sane discussion. I don't have any feeling about the use of udev in
initrd, but I'm happy to do any needed changes to udev, if it has more
substance than 'strip it down'.
Thanks,
Kay
3:49 a.m.
On Fri, 2004-07-02 at 01:01 -0400, Bill Nottingham wrote:
- Various desktop-related features, including, but not limited to:
- Remote desktops using VNC
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
I seriously hope this isn't on by default. That'll be asking for
trouble.
Rui
6:43 a.m.
On Fri, 2004-07-02 at 01:01 -0400, Bill Nottingham wrote:
And, random other stuff, of course.
metadata support by all pkging tools:
http://linux.duke.edu/metadata/
-sv
7:11 a.m.
Bill Nottingham wrote:
- GCC 3.4 - those that have looked at rawhide will have noticed this
- GNOME 2.8
- KDE 3.3
- SELinux, yet again. This includes a new 'targeted' policy that
monitors specifc daemons with less intrusion than the strict
policy in use before.
https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096...
- IIIMF - continued evolution of the new input framework
- Indic language support
- Various desktop-related features, including, but not limited to:
- Pango support for Mozilla
- Remote desktops using VNC
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
- Printing improvements
http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00370.html
- Evolution 2.0
And, random other stuff, of course.
I'm sure there's other stuff people would like to see. What sorts
of things?
Adding Firefox 1.0 as the default webbrowser
8:27 a.m.
On Fri, 2004-07-02 at 09:21 -0400, Alan Cox wrote:
> Adding Firefox 1.0 as the default webbrowser
Seems a strange thing to do for a gnome desktop when gnome has a web
browser
I've not yet seen anyone who's been happy with epiphany. And when
compiled correctly and used with the right theme, firefox looks very
much like a gnome app.
Regards,
--
Konstantin Ryabitsev
Duke University Physics
8:28 a.m.
On Fri, 2004-07-02 at 09:27, Konstantin Ryabitsev wrote:
On Fri, 2004-07-02 at 09:21 -0400, Alan Cox wrote:
> > Adding Firefox 1.0 as the default webbrowser
>
> Seems a strange thing to do for a gnome desktop when gnome has a web
> browser
I've not yet seen anyone who's been happy with epiphany. And when
compiled correctly and used with the right theme, firefox looks very
much like a gnome app.
oh cmon, I love having a web browser with so few features that I can't
even remove an invalid ssl cert...
it's a blast.
-sv
8:32 a.m.
On Fri, 2004-07-02 at 09:28 -0400, seth vidal wrote:
oh cmon, I love having a web browser with so few features that I
can't
even remove an invalid ssl cert...
Features? You're crazy. What next? Being able to edit menus in Gnome?
/me ducks :)
--
Konstantin Ryabitsev
Duke University Physics
8:30 a.m.
On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote:
I've not yet seen anyone who's been happy with epiphany. And
when
You have - me
If Firefox can be persuaded to behave _exactly_ as a gnome application
then it might have potential once its at 1.0, has all the language
translations caught up etc
9:06 a.m.
Le ven 02/07/2004 à 15:35, Konstantin Ryabitsev a écrit :
On Fri, 2004-07-02 at 09:30 -0400, Alan Cox wrote:
> > I've not yet seen anyone who's been happy with epiphany. And when
>
> You have - me
I mean real users,
Well! We now know that Alan Cox is not a real user... I had suspected
this myself for quite some time =:-D
As an almost real user:
- DVB modules that are usable with the up to date userland tools would
be nice. And access to DVB devices that don't require being root.
- Firewire (I made my first DVDs from captured DVB on a Firewire DVD-R
last weekend in FC1)
- the unichrome driver for VIA CLE266
- a built in graphical boot screen that works
- nedit and pico installed by default (I hate vi and emacs...)
Cheers
Tony Grant
--
www.tgds.net Art centre library management software toolkit
10:02 a.m.
On Friday 02 July 2004 17:09, Charles R. Anderson wrote:
On Fri, Jul 02, 2004 at 04:06:16PM +0200, Tony Grant wrote:
> - nedit and pico installed by default (I hate vi and emacs...)
The GNU nano clone replaced pico due to licensing issues with
pine/pico.
And there is mcedit (part of Midnight Commander). It would be nice
to have the patch that Leonard den Ottolander
<leonard[at]den[dot]ottolander[dot]nl>
suggested (which works for me with RH9, FC1 and FC2):
--- cut ---
As a side note, for users of Fedora Core there is a test src rpm
featuring Vladimir's utf-8 improvements at
http://www.ottolander.nl/opensource/srpms/fc1/mc-4.6.0-14.10n.src.rpm .
The changelog in the spec file is incomplete. Essentially 6 hunks of the
Fedora patches have been merged with Vladimir's patches and were dropped
from the original patches.
Leonard.
--- cut ---
--
Regards,
Doncho N. Gunchev Registered Linux User #291323 at counter.li.org
GPG-Key-ID: 1024D/DA454F79
Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79
2:17 p.m.
Hi Doncho,
And there is mcedit (part of Midnight Commander). It would be
nice
to have the patch that Leonard den Ottolander
<leonard[at]den[dot]ottolander[dot]nl>
suggested (which works for me with RH9, FC1 and FC2):
I guess Jakub will be happy to include the improved UTF-8 patches (note
that the author is Vladimir Nadvornik, I just made some suggestions on
what to fix), but I'd rather see some of Red Hat and SUSE's patches
merged upstream so we can bump to 4.6.1. Pavel Roskin has indicated to
me that he doesn't want to merge the UTF-8 patches yet, but that
shouldn't be a problem to use them downstream, as I am sure SUSE also
will. They do need some more testing however.
For now I first have to see which parts of the patches have already been
merged with CVS and which not, so I can propose some more of them for
upstream inclusion. But things are coming along nicely.
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
10:23 a.m.
Le ven 02/07/2004 à 16:19, Dan Williams a écrit :
On Fri, 2004-07-02 at 16:06 +0200, Tony Grant wrote:
> - a built in graphical boot screen that works
What problems are you experiencing with rhgb (i assume that's what you
mean)? Bugs filed in bugzilla would be appreciated...
It just kind of stopped one day. If I switch to Ctrl-Alt-F8 sometimes I
can see it. It stopped awhile back for no obvious reasons - reboot
machine no more graphical boot.
I don't mind living without it but my other half has taken to using my
machine to read her web mail and she is reassured where as normal text
boot screen is "intimidating" for her...
Cheers
Tony
--
www.tgds.net Library management software toolkit
10:41 a.m.
You sure you've got it installed and that "rhgb" is on your kernel boot
line?
On Fri, 2004-07-02 at 17:23 +0200, Tony Grant wrote:
Le ven 02/07/2004 à 16:19, Dan Williams a écrit :
> On Fri, 2004-07-02 at 16:06 +0200, Tony Grant wrote:
> > - a built in graphical boot screen that works
>
> What problems are you experiencing with rhgb (i assume that's what you
> mean)? Bugs filed in bugzilla would be appreciated...
It just kind of stopped one day. If I switch to Ctrl-Alt-F8 sometimes I
can see it. It stopped awhile back for no obvious reasons - reboot
machine no more graphical boot.
I don't mind living without it but my other half has taken to using my
machine to read her web mail and she is reassured where as normal text
boot screen is "intimidating" for her...
Cheers
Tony
--
www.tgds.net Library management software toolkit
10:45 a.m.
Le ven 02/07/2004 à 17:41, Dan Williams a écrit :
You sure you've got it installed and that "rhgb" is on
your kernel boot
line?
# locate rhgb
/usr/bin/rhgb
/usr/bin/rhgb-client
title Fedora Core (2.6.3)
root (hd0,0)
kernel /vmlinuz-2.6.3 ro root=LABEL=/ rhgb quiet
...
Tony
--
www.tgds.net Library management software toolkit
8:49 a.m.
On Fri, 02 Jul 2004 10:19:43 -0400, Dan Williams wrote:
What problems are you experiencing with rhgb (i assume that's
what you
mean)? Bugs filed in bugzilla would be appreciated...
Is it going to be finished off at any point so:
- no kernel text at all is seen on startup
- there is graphical shutdown
- a minimal X server is used (maybe just skip that and make GTK use the
framebuffer) - right now startup time is increased somewhat because the
nVidia drivers take ages to initialize
thanks -mike
9:13 a.m.
On Sun, 4 Jul 2004 23:49, Mike Hearn <mike(a)navi.cx> wrote:
- no kernel text at all is seen on startup
Presumably that would imply that there would be no way to diagnose the problem
if the graphics did not work properly...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
9:50 a.m.
On Mon, 2004-07-05 at 00:13 +1000, Russell Coker wrote:
Presumably that would imply that there would be no way to diagnose
the problem
if the graphics did not work properly...
Sure there is, just have a startup option to disable it like you can do
with mem=nopentium and the like.
10:21 a.m.
On Sun, Jul 04, 2004 at 03:50:44PM +0100, Mike Hearn wrote:
Sure there is, just have a startup option to disable it like you can
do
with mem=nopentium and the like.
The very first few lines are printed out before the command line is
parsed (indeed the grub and loader ones before the kernel is uncompressed)
Alan
--
In ximian did mad miguel a mighty mail client decree
Where nat the crazy hacker ran
Through source code measureless to man
And never core dump free
9:55 a.m.
Am So, den 04.07.2004 schrieb Russell Coker um 16:13:
On Sun, 4 Jul 2004 23:49, Mike Hearn <mike(a)navi.cx> wrote:
> - no kernel text at all is seen on startup
Presumably that would imply that there would be no way to diagnose the problem
if the graphics did not work properly...
Why not (while using rhgb) a nice Progress bar like in win2k? Or maybe a
progress bar that is mostly unseeable on fast machines (like in XP).
Currently with rhgb I seem things like
audit(1088959155.953:0): initialized
Setting default font
Welcome to Fedora-Core
And then X starts. Those are not helpfull and could be avoided IMHO
/me runs away
CU
thl
12:50 p.m.
On Sun, 2004-07-04 at 15:49, Mike Hearn wrote:
On Fri, 02 Jul 2004 10:19:43 -0400, Dan Williams wrote:
> What problems are you experiencing with rhgb (i assume that's what you
> mean)? Bugs filed in bugzilla would be appreciated...
Is it going to be finished off at any point so:
- no kernel text at all is seen on startup
you consider the one "booting linux kernel" kernel line that does show
up too much ????
- a minimal X server is used (maybe just skip that and make GTK use
the
framebuffer) - right now startup time is increased somewhat because the
nVidia drivers take ages to initialize
that sounds like a bug in nv.....
4:19 p.m.
On Sun, 2004-07-04 at 14:49 +0100, Mike Hearn wrote:
- no kernel text at all is seen on startup
Any kernel text showing up with the current 'quiet' mode could be
considered a bug :)
- there is graphical shutdown
I'd rather just make the shutdown fast enough that no one cares.
Keeping X running makes a few things difficult and it would be easier
just to speed up the process, imho
- a minimal X server is used (maybe just skip that and make GTK use
the framebuffer) - right now startup time is increased somewhat
because the nVidia drivers take ages to initialize
Unfortunately, framebuffers + accelerated X servers have a habit of
triggering neat new bugs :( Even things as simple as vga16fb.
Jeremy
5:02 p.m.
On Tue, Jul 06, 2004 at 05:19:58PM -0400, Jeremy Katz wrote:
Any kernel text showing up with the current 'quiet' mode
could be
considered a bug :)
Speaking of which -- is there a way to make the 'quiet' mode into a
'spinner' mode or an 'increasing dot dot dot' mode? On some systems, it
takes a while, and I've had to disable it here, since I had _several_
different people thinking their computer was locked at boot and just hitting
the reset button over and over instead of waiting.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:47 a.m.
Matthew Miller wrote:
On Tue, Jul 06, 2004 at 05:19:58PM -0400, Jeremy Katz wrote:
>Any kernel text showing up with the current 'quiet' mode could be
>considered a bug :)
Speaking of which -- is there a way to make the 'quiet' mode into a
'spinner' mode or an 'increasing dot dot dot' mode? On some systems, it
takes a while, and I've had to disable it here, since I had _several_
different people thinking their computer was locked at boot and just hitting
the reset button over and over instead of waiting.
I once made a kernel patch, which printed a "." for every line that would have
been printed.
This gives you a nice feedback, that your machine actually is doing s.th.
8:41 a.m.
On Wed, 07 Jul 2004 10:47:42 +0200, Harald Hoyer <harald(a)redhat.com> wrote:
I once made a kernel patch, which printed a "." for every
line that would have been printed.
This gives you a nice feedback, that your machine actually is doing s.th.
So in a fine grained kernel bootup verbosity world perhaps we should
have a few more modes:
school-library-silent :
Absolutely no talking from the kernel or it goes to detention
juggling-penquin-ascii-animated-statusbar:
Far far better than just silly little "."'s
just-tell-me-what-I-think-is-worth-a-text-notice:
Something close to the current quiet mode, using mindreading
technology that I have
patented to give a modicum of textual scroll based on what the user
"thinks" is worth
reporting.
graphical:
yawn, boring
subliminal:
why ruin the pretty graphical bootup with text I can actively read.
sublimal messaging will
be far more effective and far less instrusive on the eye.
peepd:
translate all textual or graphical information about statup into a
soundscape...
too bad the netpeep project appears to be dead.
-jef"uses the go-get-coffee mode when he reboots his boxes"spaleta
12:39 p.m.
On Wed, Jul 07, 2004 at 10:47:42AM +0200, Harald Hoyer wrote:
I once made a kernel patch, which printed a "." for every
line that would
have been printed.
This gives you a nice feedback, that your machine actually is doing s.th.
Yeah, sounds like exactly what I'd like to see.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:26 p.m.
On Wed, Jul 07, 2004 at 01:39:05PM -0400, Matthew Miller wrote:
On Wed, Jul 07, 2004 at 10:47:42AM +0200, Harald Hoyer wrote:
> I once made a kernel patch, which printed a "." for every line that would
> have been printed.
> This gives you a nice feedback, that your machine actually is doing s.th.
Yeah, sounds like exactly what I'd like to see.
(And ideally, if you hit a key, it'd spit out everything that it had hidden
before, and go back to normal mode.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:50 p.m.
Jeremy Katz wrote:
On Sun, 2004-07-04 at 14:49 +0100, Mike Hearn wrote:
[snip]
>- there is graphical shutdown
I'd rather just make the shutdown fast enough that no one cares.
Keeping X running makes a few things difficult and it would be easier
just to speed up the process, imho
[snip]
Jeremy
I noticed something in FC2 with regards to shutdown...
Most of the time, shutting down from a Gnome desktop or from GDM, I see
the listing of services being killed (the one with the [OK] thing,
similar to the startup process).
But there are times when I don't see this. What happens is all the Gnome
stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting
down is my wallpaper. When X gets killed, I see the standard console
login prompt for a moment. Then shutdown. No service shutdown listing.
Very clean. It seems not as I get it maybe 1 out of 10 shutdowns.
dex
12:14 a.m.
On Tue, 2004-07-06 at 20:50, Dexter Ang wrote:
[snip]
I noticed something in FC2 with regards to shutdown...
Most of the time, shutting down from a Gnome desktop or from GDM, I see
the listing of services being killed (the one with the [OK] thing,
similar to the startup process).
But there are times when I don't see this. What happens is all the Gnome
stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting
down is my wallpaper. When X gets killed, I see the standard console
login prompt for a moment. Then shutdown. No service shutdown listing.
Very clean. It seems not as I get it maybe 1 out of 10 shutdowns.
Indeed, I get this as well on FC2. The messages are actually being
displayed on VT7, but "focus" (for lack of a better word) is actually on
VT1.
Greg
1:50 p.m.
Dexter Ang (thepoch(a)mydestiny.net) said:
Most of the time, shutting down from a Gnome desktop or from GDM, I
see
the listing of services being killed (the one with the [OK] thing,
similar to the startup process).
But there are times when I don't see this. What happens is all the Gnome
stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting
down is my wallpaper. When X gets killed, I see the standard console
login prompt for a moment. Then shutdown. No service shutdown listing.
Very clean. It seems not as I get it maybe 1 out of 10 shutdowns.
I believe it depends on what VTs were active when you started X/gdm.
Bill
12:45 a.m.
Bill Nottingham wrote:
Dexter Ang (thepoch(a)mydestiny.net) said:
>Most of the time, shutting down from a Gnome desktop or from GDM, I see
>the listing of services being killed (the one with the [OK] thing,
>similar to the startup process).
>
>But there are times when I don't see this. What happens is all the Gnome
>stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting
>down is my wallpaper. When X gets killed, I see the standard console
>login prompt for a moment. Then shutdown. No service shutdown listing.
>Very clean. It seems not as I get it maybe 1 out of 10 shutdowns.
I just noticed my last sentence being weirdly phrased. I editted
something out and didn't change it. Anyway...
I believe it depends on what VTs were active when you started X/gdm.
Bill
OK. I was thinking that this might be a "nice" alternative for those
that complain that they want a shutdown screen to hide the "scary" stuff
from normal users. But this would most probably be troublesome for those
that need/want to see the shutdown sequence, having to quickly switch
VTs before the computer actually powers down.
If this is a bad idea and has been suggested/discussed before, I'd
appreciate a pointer to the discussion.
dex
1:51 a.m.
Le mar, 06/07/2004 à 17:19 -0400, Jeremy Katz a écrit :
On Sun, 2004-07-04 at 14:49 +0100, Mike Hearn wrote:
> - no kernel text at all is seen on startup
Any kernel text showing up with the current 'quiet' mode could be
considered a bug :)
> - there is graphical shutdown
I'd rather just make the shutdown fast enough that no one cares.
Keeping X running makes a few things difficult and it would be easier
just to speed up the process, imho
BTW the way it's done now does not seem overly robust WRT custom kernels
with radeonfb built-in.
On more than one such system I've seen the screen blanking out on reboot
(probably because we do not bother to restore some register when killing
X)
This is *very* annoying when the shutdown fails and you can't even look
at the system messages to figure out why.
Cheers,
--
Nicolas Mailhot
9:43 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 02 July 2004 07:06, Tony Grant wrote:
- DVB modules that are usable with the up to date userland
tools
would be nice. And access to DVB devices that don't require being root.
- Firewire (I made my first DVDs from captured DVB on a Firewire DVD-R
last weekend in FC1)
Firewire has been re-enabled in update FC2 kernel.s
- the unichrome driver for VIA CLE266
- a built in graphical boot screen that works
What doesn't work about RHGB for you? If you're talking 'built-in' like
SuSE's craptastic kernel framebuffer hack, puuu-leaze. We've been down
that road before (:
- nedit and pico installed by default (I hate vi and
emacs...)
nano.
- --
Jesse Keating RHCE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedoralegacy.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA5XSg4v2HLvE71NURAuIsAJ9BniDDX6fOSunR/f6AGHZww/LkzgCffGWd
6nszxpJrmqRNxSjS38cXshg=
=F+lR
-----END PGP SIGNATURE-----
9:47 a.m.
On Fri, Jul 02, 2004 at 04:06:16PM +0200, Tony Grant wrote:
- DVB modules that are usable with the up to date userland tools
would
be nice. And access to DVB devices that don't require being root.
Apart from Arjan leaving them out that really is an issue of what is in the
upstream kernel - and for permissions take a look at
/etc/security/console.perms
I would suspect adding DVB to this would do the job. If it does then post
the needed changes to bugzilla.
- the unichrome driver for VIA CLE266
The kernel bits are in the current tree and the driver is in FC2 (2D) although
the config tools seem to select vesa (just turn it to via)
- a built in graphical boot screen that works
Such as ?
- nedit and pico installed by default (I hate vi and emacs...)
pico is part of pine which is licensing issues. Nano is supposed to be free
and equivalent but I don't know much about it. Nedit seems a bit obscure
given that both KE and Gnome have basic graphical editors anyway ?
Alan
10:37 a.m.
Le ven 02/07/2004 à 16:47, Alan Cox a écrit :
/etc/security/console.perms
I would suspect adding DVB to this would do the job. If it does then post
the needed changes to bugzilla.
Oh cool thanks! I'll try that
> - the unichrome driver for VIA CLE266
The kernel bits are in the current tree and the driver is in FC2 (2D) although
the config tools seem to select vesa (just turn it to via)
Yes - it would be nice to be able to configure it with the normal tools
rather than hacking the config file by hand is what I was trying to say.
Nedit seems a bit obscure
given that both KE and Gnome have basic graphical editors anyway ?
I have standard Gnome menus in FC1 (I think) and there is no text editor
other than emacs under the "Programming" menu. I am not sure if the
standard Gnome text editor does code colouring for SQL or CCS or JSP???
And of course all those years of using jed, pico and nedit... My
preferred text editor all categories is of course BBedit.
Cheers
Tony Grant
--
www.tgds.net Library management software toolkit
10:54 a.m.
On Fri, Jul 02, 2004 at 05:37:26PM +0200, Tony Grant wrote:
I have standard Gnome menus in FC1 (I think) and there is no text
editor
other than emacs under the "Programming" menu. I am not sure if the
standard Gnome text editor does code colouring for SQL or CCS or JSP???
Gedit doesn't try and so stuff like code colouring - its an editor not a
programming environment. OTOH it works in lots of languages which isn't true
of a lot of the other editors
Alan
--
"Instead of creating snowflakes why not build a blizzard ?"
-- 'Ancient Brit'
2:59 p.m.
On Fri, Jul 02, 2004 at 05:37:26PM +0200, Tony Grant wrote:
Le ven 02/07/2004 à 16:47, Alan Cox a écrit :
> The kernel bits are in the current tree and the driver is in FC2 (2D) although
> the config tools seem to select vesa (just turn it to via)
Yes - it would be nice to be able to configure it with the normal tools
rather than hacking the config file by hand is what I was trying to say.
And the
kernel bits aren't actually there yet :-)
The X11 bits worked just ok for 3D last time I checked (which was in the
XFree86 days) once the right kernel drivers are installed.
Probably should just get someone (as in the guys who wrote the patches that
are around!) to push the patches into the upstream kernel, they're
pretty much stand-alone and seem to work just fine...
--
Pekka Pietikainen
3:02 p.m.
On Fri, Jul 02, 2004 at 10:59:49PM +0300, Pekka Pietikainen wrote:
Probably should just get someone (as in the guys who wrote the
patches that
are around!) to push the patches into the upstream kernel, they're
pretty much stand-alone and seem to work just fine...
All the needed bits are in Xorg cvs and the kernel patch was pushed upstream
last DRI push. Dunno if it was taken or not
Alan
--
"Facts stand alone. They only need to be noted.
Bullshit needs repeating."
-- Richard Johnson
4:21 p.m.
On Fri, 2004-07-02 at 17:37 +0200, Tony Grant wrote:
> > - the unichrome driver for VIA CLE266
>
> The kernel bits are in the current tree and the driver is in FC2
(2D) although
> the config tools seem to select vesa (just turn it to via)
Yes - it would be nice to be able to configure it with the normal
tools rather than hacking the config file by hand is what I was trying
to say.
File a bug against hwdata with the lspci information and which driver to
use. This should be easy to fix :)
Jeremy
4:23 a.m.
On Friday 02 July 2004 17:37, Tony Grant wrote:
Le ven 02/07/2004 à 16:47, Alan Cox a écrit :
> /etc/security/console.perms
>
> I would suspect adding DVB to this would do the job. If it does then post
> the needed changes to bugzilla.
Oh cool thanks! I'll try that
You must have created the devices nodes yourself anyway, they are not in the
dev package, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117145.
--
http://LinuxWiki.org/RonnyBuchmann
9:10 p.m.
Alan Cox wrote:
On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev
wrote:
>I've not yet seen anyone who's been happy with epiphany. And when
You have - me
If Firefox can be persuaded to behave _exactly_ as a gnome application
then it might have potential once its at 1.0, has all the language
translations caught up etc
https://bugzilla.fedora.us/show_bug.cgi?id=1617
Please help in the fixing and improvement of the firefox package. We
could use help in language pack integration, and perhaps fixing the
upstream bug that blocks issuing the 0.9.1 update.
Warren
10:31 p.m.
We need some clip art for open office. You can go to
openclipart.org Which is a part of freedesktop.org and
also it would be nice to have some templates in open
office. You can find open templates at openoffice.org.
Thanx,
John Mizell
10:37 p.m.
John Mizell wrote:
We need some clip art for open office. You can go to
openclipart.org Which is a part of freedesktop.org and
also it would be nice to have some templates in open
office. You can find open templates at openoffice.org.
I would suggest you work with the OOo community to help coordinate this,
since they're already moving in this direction.
11:54 a.m.
On Fri, Jul 02, 2004 at 08:37:01PM -0700, Mike Fedyk wrote:
>We need some clip art for open office. You can go to
>openclipart.org Which is a part of freedesktop.org and
>also it would be nice to have some templates in open
>office. You can find open templates at openoffice.org.
>
I would suggest you work with the OOo community to help coordinate this,
since they're already moving in this direction.
And wikipedia which has a very very nice list of public domain (particularly
US government) image material. Also sodipodi for the flags collection
10:27 p.m.
FireFox has been behaving perfectly for me. And I have to agree,
Epiphany hasn't impressed me much, sorry.
On Fri, 2004-07-02 at 09:30, Alan Cox wrote:
On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev
wrote:
> I've not yet seen anyone who's been happy with epiphany. And when
You have - me
If Firefox can be persuaded to behave _exactly_ as a gnome application
then it might have potential once its at 1.0, has all the language
translations caught up etc
--
Albert J. Hawker <ajhawk(a)adelphia.net>
12:40 a.m.
Albert J. Hawker wrote:
FireFox has been behaving perfectly for me. And I have to agree,
Epiphany hasn't impressed me much, sorry.
And I especially hate the bookmark management of Epiphany. It just seems
"weird". I know, very subjective. Just wanted to put that opinion in.
On Fri, 2004-07-02 at 09:30, Alan Cox wrote:
>/On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote:
>> I've not yet seen anyone who's been happy with epiphany. And when
>
>You have - me
>
>If Firefox can be persuaded to behave _exactly_ as a gnome application
>then it might have potential once its at 1.0, has all the language
>translations caught up etc/
>
6:33 a.m.
Dexter Ang wrote:
Albert J. Hawker wrote:
> FireFox has been behaving perfectly for me. And I have to agree,
> Epiphany hasn't impressed me much, sorry.
And I especially hate the bookmark management of Epiphany. It just
seems "weird". I know, very subjective. Just wanted to put that
opinion in.
>
> On Fri, 2004-07-02 at 09:30, Alan Cox wrote:
>
>> /On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote:
>>
>>> I've not yet seen anyone who's been happy with epiphany. And when
>>
>>
>> You have - me
>>
>> If Firefox can be persuaded to behave _exactly_ as a gnome application
>> then it might have potential once its at 1.0, has all the language
>> translations caught up etc/
>>
Why not just include firefox and make it selectabel in prefered
applications?
6:59 a.m.
On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang <thepoch(a)mydestiny.net> wrote:
Albert J. Hawker wrote:
> FireFox has been behaving perfectly for me. And I have to agree,
> Epiphany hasn't impressed me much, sorry.
And I especially hate the bookmark management of Epiphany. It just seems
"weird". I know, very subjective. Just wanted to put that opinion in.
There's been talk of making extentions for Epiphany to enable
different (dare I say "classical") methods of bookmark management.
Personally, I love Epiphany; I tried Firefox 0.90 but it didn't
impress me enough to sway me.
--
Ben Steeves
ben.steeves(a)gmail.com
GPG ID: 0xB3EBF1D9
http://www.metacon.ca/
11:55 a.m.
New subject: Browsers [was: Fedora Core 3]
On Mon, 2004-07-05 at 13:59, Ben Steeves wrote:
On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang
<thepoch(a)mydestiny.net> wrote:
> Albert J. Hawker wrote:
<snip>
Personally, I love Epiphany; I tried Firefox 0.90 but it didn't
impress me enough to sway me.
This boils down to personal preference really.
Could the browser be a candidate for /etc/alternatives ?
Or maybe an env var?
Regards,
--
Tarjei
1:48 p.m.
New subject: Browsers [was: Fedora Core 3]
On Tue, 06 Jul 2004 18:55:54 +0200, Tarjei Knapstad
<tarjei.knapstad(a)predichem.com> wrote:
On Mon, 2004-07-05 at 13:59, Ben Steeves wrote:
> On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang <thepoch(a)mydestiny.net> wrote:
>
This boils down to personal preference really.
Could the browser be a candidate for /etc/alternatives ?
Or maybe an env var?
I don't think you can ship the OS without a web-browser in Core. Of
course, everyone and his dog will have an opinion on which browser
that should be. I'm inclined to recommend sticking with Epiphany, not
just 'cos it's my favorite, but because it's the GNOME project's.
--
Ben Steeves
ben.steeves(a)gmail.com
GPG ID: 0xB3EBF1D9
http://www.metacon.ca/
2:33 p.m.
New subject: Browsers [was: Fedora Core 3]
Ben Steeves wrote:
On Tue, 06 Jul 2004 18:55:54 +0200, Tarjei Knapstad
<tarjei.knapstad(a)predichem.com> wrote:
>On Mon, 2004-07-05 at 13:59, Ben Steeves wrote:
>
>
>>On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang <thepoch(a)mydestiny.net>
wrote:
>>
>>
>>
>This boils down to personal preference really.
>
>Could the browser be a candidate for /etc/alternatives ?
>
>Or maybe an env var?
>
>
I don't think you can ship the OS without a web-browser in Core. Of
Nobody's saying to remove all browsers from core, but to allow switching
of the main browser with /etc/alternatives, which is a mechanism having
nothing to do with core, extras or alternatives. They just happen to be
named similarly...
course, everyone and his dog will have an opinion on which browser
that should be. I'm inclined to recommend sticking with Epiphany, not
just 'cos it's my favorite, but because it's the GNOME project's.
People switch to Mozilla/Firefox/Thunderbird on win32 to be able to gain
interface familiarity with a program. Firefox is the future of the
Mozilla project, why not integrate with them instead of duplicating
work? There are already efforts to use gtk2 in firefox and mozilla,
just use that.
But I'm sorry to say, that won't happen for a long time, if ever. Only
time, and the epiphany developer's whims will tell.
5:05 p.m.
New subject: Browsers [was: Fedora Core 3]
On Tue, Jul 06, 2004 at 12:33:38PM -0700, Mike Fedyk wrote:
Nobody's saying to remove all browsers from core, but to allow
switching
of the main browser with /etc/alternatives, which is a mechanism having
nothing to do with core, extras or alternatives. They just happen to be
named similarly...
I don't know if you've looked at the Fedora Extras Firefox package, but it's
nicely integrated so that in Gnome, you can choose it as a 'preferred web
browser', and you get it instead of Mozilla when you hit the web browser
button or any other time Gnome wants to show a web page.
Unlike /etc/alternatives, this is a per user choice, which makes more sense
for an application like this.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:50 a.m.
New subject: Browsers [was: Fedora Core 3]
Matthew Miller wrote:
On Tue, Jul 06, 2004 at 12:33:38PM -0700, Mike Fedyk wrote:
>Nobody's saying to remove all browsers from core, but to allow switching
>of the main browser with /etc/alternatives, which is a mechanism having
>nothing to do with core, extras or alternatives. They just happen to be
>named similarly...
I don't know if you've looked at the Fedora Extras Firefox package, but it's
nicely integrated so that in Gnome, you can choose it as a 'preferred web
browser', and you get it instead of Mozilla when you hit the web browser
button or any other time Gnome wants to show a web page.
Unlike /etc/alternatives, this is a per user choice, which makes more sense
for an application like this.
I hope we won't see paperclip dialogs like: "Firefox does not seem your default
browser. Would you..."
4:05 a.m.
New subject: Browsers [was: Fedora Core 3]
On Wed, 2004-07-07 at 10:50 +0200, Harald Hoyer wrote:
Matthew Miller wrote:
> On Tue, Jul 06, 2004 at 12:33:38PM -0700, Mike Fedyk wrote:
>
>>Nobody's saying to remove all browsers from core, but to allow switching
>>of the main browser with /etc/alternatives, which is a mechanism having
>>nothing to do with core, extras or alternatives. They just happen to be
>>named similarly...
>
>
> I don't know if you've looked at the Fedora Extras Firefox package, but
it's
> nicely integrated so that in Gnome, you can choose it as a 'preferred web
> browser', and you get it instead of Mozilla when you hit the web browser
> button or any other time Gnome wants to show a web page.
>
> Unlike /etc/alternatives, this is a per user choice, which makes more sense
> for an application like this.
>
I hope we won't see paperclip dialogs like: "Firefox does not seem your default
browser. Would you..."
How do you feel about talking staplers? We've found in our usability
studies that people are much more friendly to staplers instead of those
nasty paper clips. ;-)
--
Bryan Clark <bclark(a)redhat.com>
Red Hat Desktop Design Ninja
9:09 a.m.
New subject: Browsers [was: Fedora Core 3]
Once upon a time, Bryan Clark <bclark(a)redhat.com> said:
How do you feel about talking staplers? We've found in our
usability
studies that people are much more friendly to staplers instead of those
nasty paper clips. ;-)
But it has to be a red Swingline. "Excuse me, I believe you have my
stapler..."
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
5:06 a.m.
New subject: Browsers [was: Fedora Core 3]
On Wed, 2004-07-07 at 10:50 +0200, Harald Hoyer wrote:
> I don't know if you've looked at the Fedora Extras
Firefox package, but it's
> nicely integrated so that in Gnome, you can choose it as a 'preferred web
> browser', and you get it instead of Mozilla when you hit the web browser
> button or any other time Gnome wants to show a web page.
>
> Unlike /etc/alternatives, this is a per user choice, which makes more sense
> for an application like this.
>
I hope we won't see paperclip dialogs like: "Firefox does not seem your default
browser. Would you..."
No, the browser shouldn't check if it's default.
It just does it's job.
It depends on gnome/system what browser it starts or with what it opens
the links when user clicks on shortcuts. As said, preferred browser can
be set in Preferred Applications.
/etc/alternatives doesn't make sense for this.
--
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro
5:04 a.m.
New subject: Browsers [was: Fedora Core 3]
Marius Andreiana wrote:
On Wed, 2004-07-07 at 10:50 +0200, Harald Hoyer wrote:
>>I don't know if you've looked at the Fedora Extras Firefox package, but
it's
>>nicely integrated so that in Gnome, you can choose it as a 'preferred web
>>browser', and you get it instead of Mozilla when you hit the web browser
>>button or any other time Gnome wants to show a web page.
>>
>>Unlike /etc/alternatives, this is a per user choice, which makes more sense
>>for an application like this.
>>
>
>I hope we won't see paperclip dialogs like: "Firefox does not seem your
default browser. Would you..."
No, the browser shouldn't check if it's default. It just does it's job.
It depends on gnome/system what browser it starts or with what it opens
the links when user clicks on shortcuts. As said, preferred browser can
be set in Preferred Applications.
/etc/alternatives doesn't make sense for this.
What about kde, xfce? they do not use gconf... Isn't that a job for mime-types?
7:18 a.m.
New subject: Browsers [was: Fedora Core 3]
On Wed, 2004-07-07 at 12:04 +0200, Harald Hoyer wrote:
What about kde, xfce? they do not use gconf... Isn't that a job
for mime-types?
AFAIK, mime-types tell what applications can open a type of file
(html,
http:// ... ), but don't allow a user to specify which is the default.
So how do KDE users choose which browser to use? (a la gnome preferred
apps). I guess it's different in every DE, which makes sense. In GNOME
default is epiphany, in KDE is konqueror.
--
Marius Andreiana
Galuna - Solutii Linux in Romania
http://www.galuna.ro
9:17 a.m.
New subject: Browsers [was: Fedora Core 3]
Once upon a time Wednesday 07 July 2004 7:18 am, Marius Andreiana wrote:
On Wed, 2004-07-07 at 12:04 +0200, Harald Hoyer wrote:
> What about kde, xfce? they do not use gconf... Isn't that a job for
> mime-types?
AFAIK, mime-types tell what applications can open a type of file (html,
http:// ... ), but don't allow a user to specify which is the default.
So how do KDE users choose which browser to use? (a la gnome preferred
apps). I guess it's different in every DE, which makes sense. In GNOME
default is epiphany, in KDE is konqueror.
KDE uses the KDE Control Center to specify default applications.
Dennis
9:13 a.m.
New subject: Browsers [was: Fedora Core 3]
On Wed, 07 Jul 2004 10:50:19 +0200, Harald Hoyer <harald(a)redhat.com> wrote:
I hope we won't see paperclip dialogs like: "Firefox does not seem your default
browser. Would you..."
No, Mozilla on Linux doesn't have that kind of support. But we could
add it if you want. :)
--Chris
1:58 a.m.
New subject: Browsers [was: Fedora Core 3]
On Tue, Jul 06, 2004 at 06:55:54PM +0200, Tarjei Knapstad wrote:
On Mon, 2004-07-05 at 13:59, Ben Steeves wrote:
> On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang <thepoch(a)mydestiny.net> wrote:
> > Albert J. Hawker wrote:
<snip>
>
> Personally, I love Epiphany; I tried Firefox 0.90 but it didn't
> impress me enough to sway me.
>
This boils down to personal preference really.
Could the browser be a candidate for /etc/alternatives ?
Or maybe an env var?
Fedora uses htmlview. It's thus possible to specify the preferable browser
for graphics, text, and console mode.
(Only submitting this now, as I assumed someone would mention it...)
Regards,
Luciano Rocha
10:45 a.m.
How about adding galeon as the default webbrowser ?
--- Konstantin Ryabitsev <icon(a)linux.duke.edu> wrote:
On Fri, 2004-07-02 at 09:21 -0400, Alan Cox wrote:
> > Adding Firefox 1.0 as the default webbrowser
>
> Seems a strange thing to do for a gnome desktop when gnome has a
web
> browser
I've not yet seen anyone who's been happy with epiphany. And when
compiled correctly and used with the right theme, firefox looks very
much like a gnome app.
Regards,
--
Konstantin Ryabitsev
Duke University Physics
ATTACHMENT part 1.2 application/pgp-signature name=signature.asc
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
9:37 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 02 July 2004 15:11, dragoran wrote:
>I'm sure there's other stuff people would like to see.
What sorts
>of things?
>
>
Adding Firefox 1.0 as the default webbrowser
I prefer mozilla. I have them both, but mozilla is more stable for
now, and it will not be good to force all users to use it. A BROWSER
environment variable can be used to select the preferred web browser.
I do not like sendmail for example, but I would not ask FC3 to be with
postfix as default, I just ask for an option not to install sendmail
at all or just use postfix as default mail server if this is desired.
However, while there is mozilla included, I would not care too much
which one is the default - I will be able to change this.
As I mentioned postfix, there's problem with sendmail's aliases file
and the postfix's one (as discussed before). Postfix, when delivering
mail locally with procmail (as it is in FC2) can not deliver mail to
root (security reasons). I was thinking what about if postfix delivers
mail to 'postfix', and it is hardlinked with root's mailbox? Both files
can be owned by different users and both users can write to the file
they own. If this is acceptable (I wonder if this can be security/locking
problem with this) then both sendmail and postfix (and probably exim) can
share one aliases file. Does this look acceptable?
- --
Regards,
Doncho N. Gunchev Registered Linux User #291323 at counter.li.org
GPG-Key-ID: 1024D/DA454F79
Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA5XM6oInLFdpFT3kRAs0nAKCff0g2AtXoNPGbXx27RJRzCip9mACguPFl
qjAuo8IY6A2EliOsrI9RFkM=
=/Z8n
-----END PGP SIGNATURE-----
7:11 a.m.
On Fri, 2004-07-02 at 01:01, Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
I would like to see a reasonable /etc/asound.conf file that turns on
DMIX, so sound works "out of the box".
Now that gstreamer 0.8.2 is out, everything should work properly.
Marc.
7:42 a.m.
Le ven, 02/07/2004 à 08:11 -0400, Marc Deslauriers a écrit :
On Fri, 2004-07-02 at 01:01, Bill Nottingham wrote:
> I'm sure there's other stuff people would like to see. What sorts
> of things?
I would like to see a reasonable /etc/asound.conf file that turns on
DMIX, so sound works "out of the box".
I would like to see gnome mixer utils that a luser like me can use to
control alsa sound. After all this time I still have to use alsamixer as
root to do anything useful with my sound card, because I still haven't
figured how to tell the gnome mixer to nuke OSS compat controls and use
SPDIF as main output (and believe me, I tried).
alsamixer interface is very user-unfriendly but even it is better than
the gnome mixer mess right now.
Cheers,
--
Nicolas Mailhot
10:05 a.m.
Nicolas Mailhot wrote:
Le ven, 02/07/2004 à 08:11 -0400, Marc Deslauriers a écrit :
>On Fri, 2004-07-02 at 01:01, Bill Nottingham wrote:
>
>
>>I'm sure there's other stuff people would like to see. What sorts
>>of things?
>>
>>
>I would like to see a reasonable /etc/asound.conf file that turns on
>DMIX, so sound works "out of the box".
>
>
I would like to see gnome mixer utils that a luser like me can use to
control alsa sound. After all this time I still have to use alsamixer as
root to do anything useful with my sound card, because I still haven't
figured how to tell the gnome mixer to nuke OSS compat controls and use
SPDIF as main output (and believe me, I tried).
alsamixer interface is very user-unfriendly but even it is better than
the gnome mixer mess right now.
Cheers,
Talking about user-friendly , I would like to see a gnome mixer with
less options... On a sound blaster live card , it shows dozens of
controls.. I wonder what's the reaction of a normal user when seeing it
for the first time... (by normal user , I mean a user who has never
worked as a sysdamin or a linux developer)
--
Pedro Macedo
7:55 a.m.
It sounds like it might be a bit late to make the cut for Fedora Core 3,
but Firefox 1.0 should be ready some time in September. I'm sure there
would be lots of people who would like to see it as a default.
Steven Garrity
7:57 a.m.
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
Evolution 2.0 will include connector I assume ?
If so then OpenGroupware so there is a working backend too.
OpenOffice 1.2 so that we get the extra languages
Theora + Totem built against gstreamer and/or the GPL'd realplayer
And if possible to find enough old packages that have few users that can
be pushed into Fedora Extras to get back down to 3 CD's
8:23 a.m.
On Fri, 2004-07-02 at 08:57, Alan Cox wrote:
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
> I'm sure there's other stuff people would like to see. What sorts
> of things?
Evolution 2.0 will include connector I assume ?
If so then OpenGroupware so there is a working backend too.
OpenOffice 1.2 so that we get the extra languages
Theora + Totem built against gstreamer and/or the GPL'd realplayer
And if possible to find enough old packages that have few users that can
be pushed into Fedora Extras to get back down to 3 CD's
All this w/i 10 days until test 1...
/me giggles profusely
-sv
5:17 p.m.
On Fri, 2004-07-02 at 05:57, Alan Cox wrote:
OpenOffice 1.2 so that we get the extra languages
I don' t think there will be such a release :P
We're at 1.1.2 now, and will probably be just nice at 1.1.3 for
inclusion in FC3
OOo plans are at
http://development.openoffice.org/releases/OpenOffice_org_1_x.html
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
5:39 p.m.
On Fri, Jul 02, 2004 at 03:17:03PM -0700, Colin Charles wrote:
On Fri, 2004-07-02 at 05:57, Alan Cox wrote:
> OpenOffice 1.2 so that we get the extra languages
I don' t think there will be such a release :P
We're at 1.1.2 now, and will probably be just nice at 1.1.3 for
inclusion in FC3
Ok 1.1.2 with the Welsh language stuff thats now in the builds for 1.1.2
5:55 p.m.
On Fri, 2 Jul 2004, Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
I'd like to see the text terminals fixed up again so that Home and End
keys work in emacs -nw, joe, jed, whatever other places that are under
ncurses controls.
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton(a)redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
-- Kenneth Brown, President, Alexis de Tocqueville Institution
4:43 p.m.
Cristian Gafton (gafton(a)redhat.com) said:
> I'm sure there's other stuff people would like to see.
What sorts
> of things?
I'd like to see the text terminals fixed up again so that Home and End
keys work in emacs -nw, joe, jed, whatever other places that are under
ncurses controls.
Text? Not xterm/gnome-terminal/etc?
I thought all the complaints were about the latter.
Bill
4:50 p.m.
Bill Nottingham wrote:
Cristian Gafton (gafton(a)redhat.com) said:
>>I'm sure there's other stuff people would like to see. What sorts
>>of things?
>>
>>
>I'd like to see the text terminals fixed up again so that Home and End
>keys work in emacs -nw, joe, jed, whatever other places that are under
>ncurses controls.
>
>
Text? Not xterm/gnome-terminal/etc?
I thought all the complaints were about the latter.
There seems to be no least common denominator terminfo that can be
called "xterm" that satisfies the gnome-terminal, konsole, and xorg
xterm camp all at the same time. I believe that the best solution may be
to leave the xterm definition in the terminfo as stock, and set the TERM
to point to a more specific entry, if one can be deduced, during term
shell initialization.
4:52 p.m.
On Tue, 2004-07-06 at 17:50 -0400, Adrian Havill wrote:
There seems to be no least common denominator terminfo that can be
called "xterm" that satisfies the gnome-terminal, konsole, and xorg
xterm camp all at the same time. I believe that the best solution may
be to leave the xterm definition in the terminfo as stock, and set the
TERM to point to a more specific entry, if one can be deduced, during
term shell initialization.
Which then leads to all sorts of annoying bogus nonsense when you log
into older systems that don't have this "new" entry.
Jeremy
5 p.m.
Jeremy Katz wrote:
On Tue, 2004-07-06 at 17:50 -0400, Adrian Havill wrote:
>There seems to be no least common denominator terminfo that can be
>called "xterm" that satisfies the gnome-terminal, konsole, and xorg
>xterm camp all at the same time. I believe that the best solution may
>be to leave the xterm definition in the terminfo as stock, and set the
>TERM to point to a more specific entry, if one can be deduced, during
>term shell initialization.
>
>
Which then leads to all sorts of annoying bogus nonsense when you log
into older systems that don't have this "new" entry.
Good point. In that case, leaving TERM alone if COLORTERM is not set is
better.
5:02 p.m.
On Tue, 6 Jul 2004, Adrian Havill wrote:
Bill Nottingham wrote:
>Cristian Gafton (gafton(a)redhat.com) said:
>
>
>>>I'm sure there's other stuff people would like to see. What sorts
>>>of things?
>>>
>>>
>>I'd like to see the text terminals fixed up again so that Home and End
>>keys work in emacs -nw, joe, jed, whatever other places that are under
>>ncurses controls.
>>
>>
>
>Text? Not xterm/gnome-terminal/etc?
>
>I thought all the complaints were about the latter.
>
>
There seems to be no least common denominator terminfo that can be
called "xterm" that satisfies the gnome-terminal, konsole, and xorg
xterm camp all at the same time. I believe that the best solution may be
to leave the xterm definition in the terminfo as stock, and set the TERM
to point to a more specific entry, if one can be deduced, during term
shell initialization.
Is there somewhere besides the source that it is documented where the defaults
are set? I would really like to be able to know the correct way to do the
customizations via a ks-cfg file.
Tom
12:30 p.m.
On Tue, 6 Jul 2004, Bill Nottingham wrote:
Cristian Gafton (gafton(a)redhat.com) said:
> > I'm sure there's other stuff people would like to see. What sorts
> > of things?
>
> I'd like to see the text terminals fixed up again so that Home and End
> keys work in emacs -nw, joe, jed, whatever other places that are under
> ncurses controls.
Text? Not xterm/gnome-terminal/etc?
Well, actually it turns out that we managed to break it all around. This
is annoying enough to make me transform this into my personal crusade to
get it fixed again. The most confusing thing is logging into older system
and having everything work OK and then having the frustrating behavior on
the latest release...
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton(a)redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Linux is a leprosy; and is having a deleterious effect on the U.S. IT
industry because it is steadily depreciating the value of the software
industry sector."
-- Kenneth Brown, President, Alexis de Tocqueville Institution
7:02 p.m.
Bill Nottingham wrote:
- Remote desktops using VNC
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
Beautiful!
I will definitely be an active tester.
What is the current status? I haven't seen anything about this since I
read the archives (I joined the list just a few days after it was posted).
Is it in Rawhide?
Will it be in FC3 Test1?
What is the base project for VNC in Fedora? Real, Tight, or what?
4:44 a.m.
On Fri, Jul 02, 2004 at 05:02:01PM -0700, Mike Fedyk wrote:
What is the base project for VNC in Fedora? Real, Tight, or what?
For standalone VNC we use RealVNC, since it compiles against xorg-x11
-- TightVNC still builds against XFree86 3.3.x (!).
But the "remote desktops using VNC" means using the VNC protocol, not
the RealVNC implementation, at least as far as I'm aware.
Tim.
*/
12:52 p.m.
Mike Fedyk wrote :
Bill Nottingham wrote:
> - Remote desktops using VNC
> http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
>
Beautiful!
I will definitely be an active tester.
Yeah, this is really neat, finally like using "screen" in graphical mode!
This is probably not the proper place to discuss it, but after trying it :
- I also have the gdm freezing problem when debug is not enabled (on FC2)
- I was able to use the "Shutdown" command of the GNOME menu when logged in
remotely as a regular user... probably not something which is wanted ;-)
Other than that... really cool!
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3
Load : 0.24 0.15 0.19
8:02 p.m.
Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
A utility that asks you to choose a mirror for the updates.
The second you type any yum command for the first time, you hit the red
hat servers and that's slow as fsck.
A mirrors.fedora.redhat.com dns alias that points to mirrors (and is in
the default FC3 setup) would be another option.
Mike
10:01 p.m.
New subject: Fedora Core 3 (update mirrors)
--On Friday, July 02, 2004 6:02 PM -0700 Mike Fedyk <mfedyk(a)matchmail.com>
wrote:
A utility that asks you to choose a mirror for the updates.
The second you type any yum command for the first time, you hit the red
hat servers and that's slow as fsck.
A mirrors.fedora.redhat.com dns alias that points to mirrors (and is in
the default FC3 setup) would be another option.
I was thinking about this problem for another system, maps for online
games, and it occurred to me that a redirect server might be a good
solution. Instead of using DNS to spread the load, create a module running
under Apache that knows what servers have what modules and returns a 302
with a Location header to a randomly-chosen mirror. This could also address
the issue of some mirrors being slower to update than others.
3:51 a.m.
Le ven, 02/07/2004 à 18:02 -0700, Mike Fedyk a écrit :
Bill Nottingham wrote:
>I'm sure there's other stuff people would like to see. What sorts
>of things?
A clear statement/warning that by FC4 time any app that still does not
use fontconfig for its font needs will be kicked out of the
distribution.
Shipping xfs is ok. Giving people the impression they can rely on it ad
vitam eternam is wrong. Having to baby-sit the xfs config for the few
that still need it on my system is driving me nuts.
This, btw is the last straw that made me choose in the vi/emacs debate.
Regards,
--
Nicolas Mailhot
7:34 p.m.
On Fri, 2 Jul 2004, Mike Fedyk wrote:
Bill Nottingham wrote:
>I'm sure there's other stuff people would like to see. What sorts
>of things?
>
A utility that asks you to choose a mirror for the updates.
The second you type any yum command for the first time, you hit the red
hat servers and that's slow as fsck.
At some point yum will get the mirror-list support that is already in
up2date...
-- Elliot
The daring is in the doing
http://people.redhat.com/sopwith/
7:48 p.m.
On Mon, 2004-07-05 at 20:34 -0400, Elliot Lee wrote:
On Fri, 2 Jul 2004, Mike Fedyk wrote:
> Bill Nottingham wrote:
>
> >I'm sure there's other stuff people would like to see. What sorts
> >of things?
> >
> A utility that asks you to choose a mirror for the updates.
>
> The second you type any yum command for the first time, you hit the red
> hat servers and that's slow as fsck.
At some point yum will get the mirror-list support that is already in
up2date...
It's already there in cvs-HEAD of yum. It even parses the $ARCH variable
that adrian put in. (it reads it as $basearch instead of $arch, in
yum.conf variable-speak)
however, it's kinda superfluous the new config parsing has
include=url://to/some/file parsing that acts just like a heredoc.
so you can have an entire repository section defined that way.
-sv
8:51 p.m.
On Jul 5, 2004, Elliot Lee <sopwith(a)redhat.com> wrote:
On Fri, 2 Jul 2004, Mike Fedyk wrote:
> A utility that asks you to choose a mirror for the updates.
> The second you type any yum command for the first time, you hit
the red
> hat servers and that's slow as fsck.
At some point yum will get the mirror-list support that is already
in
up2date...
But the mirror-list support in up2date sucks just as much as far as
web proxies as concerned. If each client makes the decision on which
server to use by itself, odds are that each one behind the same web
proxy will be hammering a different server, instead of sharing/reusing
the downloads.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120365
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
10:24 p.m.
Alexandre Oliva wrote:
But the mirror-list support in up2date sucks just as much as far as
web proxies as concerned. If each client makes the decision on which
server to use by itself, odds are that each one behind the same web
proxy will be hammering a different server, instead of sharing/reusing
the downloads.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120365
About the same behaviour , there's also the problem described in bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126667 , which happens when one of
the mirrors is not in synch and you have the bad luck of up2date choosing to use the bad
mirror to download the packages.
--
Pedro Macedo
10:24 a.m.
On Mon, Jul 05, 2004 at 10:51:30PM -0300, Alexandre Oliva wrote:
But the mirror-list support in up2date sucks just as much as far as
web proxies as concerned. If each client makes the decision on which
server to use by itself, odds are that each one behind the same web
proxy will be hammering a different server, instead of sharing/reusing
the downloads.
So hash the mirror choice by the top 3 bytes of the address (making sure
10.0.0 hashes to a big box).
12:53 a.m.
On Tue, 2004-07-06 at 02:34, Elliot Lee wrote:
> A utility that asks you to choose a mirror for the updates.
well that or a smart rotating DNS alias to which a lot of mirrors
"subscribe", say updates.mirror.fedora.redhat.com
11:30 a.m.
In my experience, some mirrors pick up debug rpms and less used
architectures, some don't, and some are a day or so behind the main
sites. Rotating the complete mirror list (that exists today) will cause
people to see things like the second of two sequential yum commands
issued from the same machine failing because the second dns lookup
might return an older archive, or an archive that doesn't have certain
deps that the previous one did, etc.
So if someone does this, maybe there ought to be clear standards about
what mirrors must do to go into the rotating list.
On Jul 5, 2004, at 10:53 PM, Arjan van de Ven wrote:
On Tue, 2004-07-06 at 02:34, Elliot Lee wrote:
>> A utility that asks you to choose a mirror for the updates.
well that or a smart rotating DNS alias to which a lot of mirrors
"subscribe", say updates.mirror.fedora.redhat.com
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
10:39 p.m.
New subject: usermode without root password [was Re: Fedora Core 3]
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
I would really like to see my usermode patch to enable auth-as-user on a
per group basis included.
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188>
(It wouldn't have to be activated or enabled right away -- it's very
non-intrusive that way. And it's a pretty small patch, with hugely
beneficial results.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
8:01 a.m.
New subject: usermode without root password [was Re: Fedora Core 3]
Matthew Miller wrote:
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
>I'm sure there's other stuff people would like to see. What sorts
>of things?
I would really like to see my usermode patch to enable auth-as-user on a
per group basis included.
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188>
(It wouldn't have to be activated or enabled right away -- it's very
non-intrusive that way. And it's a pretty small patch, with hugely
beneficial results.)
This looks nice!
Florian, what do you think of this extension?
12:07 p.m.
New subject: usermode without root password [was Re: Fedora Core 3]
On Mon, Jul 05, 2004 at 03:01:43PM +0200, Harald Hoyer wrote:
><https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86188>
This looks nice!
Thanks. I've updated it to apply cleanly to the 1.70-6 package in rawhide,
by the way.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:19 a.m.
Bill Nottingham írta:
And, random other stuff, of course.
I'm sure there's other stuff people would like to see. What sorts
of things?
1. Integration of linuxconsole.sourceforge.net full multihead
capability. With 'integration' I mean not only the changes to
the kernel console subsytem but:
- changing /etc/security/console.perms so not only the first
logged in user can use certain 'shared' devices, like sound card
CD-RW, etc. maybe with the ability to assign them to certain consoles,
so one can have multiple CD/DVD drives and sound cards.
- changing system-config-display so it can discover multiple keyboards
(consoles), mice and videocards and it can configure multiple layouts
for different heads.
- integration of the PCI isolation patch from Debian's XOrg.
I am running x86_64 FC2 with this PCI isolation and it works nicely
on two Radeons.
2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the Java and
Flash plugins do not exist in 64 bit version say half time between FC3
test1 and test2. Change default through alternatives.
Best regards,
Zoltán Böszörményi
2:28 a.m.
There should be better multimedia keyboard support in FC3 (like in FC1).
In FC2 i can't get all keys working (have tried 3 differnt keyboards).
I just see such messages in dmesg after pressing a key:
atkbd.c: Unknown key released (translated set 2, code 0xbe on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e03e <keycode>' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0xc3 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e043 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0xc3 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e043 <keycode>' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0xc4 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e044 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0xc4 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e044 <keycode>' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0xd7 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e057 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0xd7 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e057 <keycode>' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0xd8 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e058 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0xd8 on
isa0060/serio0).
atkbd.c: Use 'setkeycodes e058 <keycode>' to make it known.
Should this be posted in bugzilla?
3:55 a.m.
Le sam, 03/07/2004 à 09:28 +0200, dragoran a écrit :
There should be better multimedia keyboard support in FC3 (like in
FC1).
As I understand it there already exists gnome utils for this.
What I'd like is a similar utility to map the supplementary mouse
buttons (> wheel+2) you find on trackballs and other new mice.
Cheers,
--
Nicolas Mailhot
4:10 a.m.
Nicolas Mailhot schrieb:
Le sam, 03/07/2004 à 09:28 +0200, dragoran a écrit :
>There should be better multimedia keyboard support in FC3 (like in
>FC1).
>
>
As I understand it there already exists gnome utils for this.
What I'd like is a similar utility to map the supplementary mouse
buttons (> wheel+2) you find on trackballs and other new mice.
Cheers,
The gnome utils doesn't work because the kernel keymap doesn't have
entries for some(many) of this keys. (some keys are working some not)
9:34 a.m.
On Sat, Jul 03, 2004 at 08:19:18AM +0200, Zoltan Boszormenyi wrote:
1. Integration of linuxconsole.sourceforge.net full multihead
capability. With 'integration' I mean not only the changes to
This is something that has to happen upstream. Multiconsole support is
a topic for the kernel summit and desktop summit since kernel folk,
DRI folk and X folk will all be present
- integration of the PCI isolation patch from Debian's XOrg.
What does this do ?
2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the Java
and
Flash plugins do not exist in 64 bit version say half time between FC3
test1 and test2. Change default through alternatives.
Does anything actually stop you removing the x86-64 mozilla and installing
the x86-32 one with FC2. I've not tried this but can't see any obvious
reason to fail
9:57 a.m.
Alan Cox writes:
> 2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the
Java and
> Flash plugins do not exist in 64 bit version say half time between FC3
> test1 and test2. Change default through alternatives.
Does anything actually stop you removing the x86-64 mozilla and installing
the x86-32 one with FC2. I've not tried this but can't see any obvious
reason to fail
A few weeks ago I played dumb and wrote an innocent E-mail to Macromedia:
hey, it looks like your download page is broken: its browser/platform
detection logic gets it wrong - it's giving me the 32bit version of the
Flash plugin, but I'm running the 64bit version of Mozilla. What's the
direct link to the 64bit plugin for Opteron?
12:23 p.m.
Alan Cox írta:
On Sat, Jul 03, 2004 at 08:19:18AM +0200, Zoltan Boszormenyi wrote:
>1. Integration of linuxconsole.sourceforge.net full multihead
>capability. With 'integration' I mean not only the changes to
This is something that has to happen upstream. Multiconsole support is
a topic for the kernel summit and desktop summit since kernel folk,
DRI folk and X folk will all be present
>- integration of the PCI isolation patch from Debian's XOrg.
What does this do ?
It provides two new options, IsolateDevice and SingleCard,
both restrict Xorg-X11 to reset other video cards than the
one(s) it drives, e.g.:
Option IsolateDevice "busID"
says it explicitely or
Option SingleCard "on"
says to only reset the first device in the layout.
I think this is a preliminary solution as X should do it by default.
I think it would be best to leave the device reset to driver internals.
I attach it here for reference.
>2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the
Java and
>Flash plugins do not exist in 64 bit version say half time between FC3
>test1 and test2. Change default through alternatives.
Does anything actually stop you removing the x86-64 mozilla and installing
the x86-32 one with FC2. I've not tried this but can't see any obvious
reason to fail
I was considering it to do on my FC2 installation but has not had
the time yet. But as I watched both 32 and 64 bit Mozillas to render
some (very) long pages, the 64 bit version definitely wins, I would keep
it if the plugins were available as 64 bit.
There is a question, though: is there any dependency on Mozilla's
libraries? If yes, I then have to "downgrade" those, too. I don't want
to bring half of my system back to 32 bits just to be able to use
the Flash plugin.
$Id: 080_pci_isolate_device_feature.diff 1325 2004-04-28 08:41:01Z branden $
Implement IsolateDevice and SingleCard layout options for XF86Config, and
-isolateDevice command-line flag for XFree86 X server. Useful for
multi-card setups where different X servers run on each card.
This patch by Aivils Stoss <Aivils.Stoss(a)unibanka.lv>; copyright and
license as below. Minor modifications by Andreas Schuldei and Branden
Robinson; documentation added by Branden Robinson.
Copyright 2003 Aivils Stoss.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
--- xc/programs/Xserver/hw/xfree86/xorg.conf.man~ 2004-03-26 18:10:22.000000000 -0500
+++ xc/programs/Xserver/hw/xfree86/xorg.conf.man 2004-03-26 18:53:20.000000000 -0500
@@ -1592,7 +1592,7 @@
section provides information specific to the whole session, including
session-specific
.BR Options .
-The
+In addition to options specific to this section (described below), the
.B ServerFlags
options (described above) may be specified here, and ones given here
override those given in the
@@ -1678,12 +1678,30 @@
.RE
.TP 7
.B Options
-Any option permitted in the
+In addition to the following, any option permitted in the
.B ServerFlags
section may also be specified here. When the same option appears in both
places, the value given here overrides the one given in the
.B ServerFlags
section.
+.TP 7
+.BI "Option \*qIsolateDevice\*q \*q" bus\-id \*q
+Restrict device resets to the specified
+.IR bus\-id .
+See the
+.B BusID
+option (described in
+.BR "DEVICE SECTION" ,
+above) for the format of the
+.I bus\-id
+parameter. This option overrides
+.BR SingleCard ,
+if specified. At present, only PCI devices can be isolated in this manner.
+.TP 7
+.BI "Option \*qSingleCard\*q \*q" boolean \*q
+As
+.BR IsolateDevice ,
+except that the bus ID of the first device in the layout is used.
.PP
Here is an example of a
.B ServerLayout
--- xc/programs/Xserver/hw/xfree86/Xorg.man~ 2004-03-26 19:04:30.000000000 -0500
+++ xc/programs/Xserver/hw/xfree86/Xorg.man 2004-03-26 19:10:42.000000000 -0500
@@ -192,6 +192,19 @@
this are downgraded from fatal errors to warnings. This option should
be used with care.
.TP 8
+.B \-isolateDevice \fIbus\-id\fP
+Restrict device resets to the device at
+.IR bus\-id .
+The
+.I bus\-id
+string has the form
+.IB bustype : bus : device : function
+(e.g., \(oqPCI:1:0:0\(cq).
+At present, only isolation of PCI devices is supported; i.e., this option
+is ignored if
+.I bustype
+is anything other than \(oqPCI\(cq.
+.TP 8
.B \-keeptty
Prevent the server from detaching its initial controlling terminal.
This option is only useful when debugging the server. Not all platforms
diff -urN xc/programs/Xserver/hw/xfree86/common~/xf86Config.c
xc/programs/Xserver/hw/xfree86/common/xf86Config.c
--- xc/programs/Xserver/hw/xfree86/common~/xf86Config.c 2004-03-26 18:29:19.000000000
-0500
+++ xc/programs/Xserver/hw/xfree86/common/xf86Config.c 2004-03-26 19:02:42.000000000
-0500
@@ -1416,6 +1416,20 @@
return TRUE;
}
+typedef enum {
+ LAYOUT_ISOLATEDEVICE,
+ LAYOUT_SINGLECARD
+} LayoutValues;
+
+static OptionInfoRec LayoutOptions[] = {
+ { LAYOUT_ISOLATEDEVICE, "IsolateDevice", OPTV_STRING,
+ {0}, FALSE },
+ { LAYOUT_SINGLECARD, "SingleCard", OPTV_BOOLEAN,
+ {0}, FALSE },
+ { -1, NULL, OPTV_NONE,
+ {0}, FALSE },
+};
+
/*
* figure out which layout is active, which screens are used in that layout,
* which drivers and monitors are used in these screens
@@ -2213,6 +2227,8 @@
const char *filename;
char *searchpath;
MessageType from = X_DEFAULT;
+ char *scanptr;
+ Bool singlecard = 0;
if (getuid() == 0)
searchpath = ROOT_CONFIGPATH;
@@ -2283,6 +2299,29 @@
}
}
+ xf86ProcessOptions(-1, xf86ConfigLayout.options, LayoutOptions);
+
+ if ((scanptr = xf86GetOptValString(LayoutOptions, LAYOUT_ISOLATEDEVICE))) {
+ ; /* IsolateDevice specified; overrides SingleCard */
+ } else {
+ xf86GetOptValBool(LayoutOptions, LAYOUT_SINGLECARD, &singlecard);
+ if (singlecard)
+ scanptr = xf86ConfigLayout.screens->screen->device->busID;
+ }
+ if (scanptr) {
+ int bus, device, func, stroffset = 0;
+ if (strncmp(scanptr, "PCI:", 4) != 0) {
+ xf86Msg(X_WARNING, "Bus types other than PCI not yet isolable.\n"
+ "\tIgnoring IsolateDevice option.\n");
+ } else if (sscanf(scanptr, "PCI:%d:%d:%d", &bus, &device, &func)
== 3) {
+ xf86IsolateDevice.bus = bus;
+ xf86IsolateDevice.device = device;
+ xf86IsolateDevice.func = func;
+ xf86Msg(X_INFO,
+ "Isolating PCI bus \"%d:%d:%d\"\n", bus, device, func);
+ }
+ }
+
/* Now process everything else */
if (!configFiles(xf86configptr->conf_files) ||
diff -urN xc/programs/Xserver/hw/xfree86/common~/xf86Globals.c
xc/programs/Xserver/hw/xfree86/common/xf86Globals.c
--- xc/programs/Xserver/hw/xfree86/common~/xf86Globals.c 2004-03-26 18:29:19.000000000
-0500
+++ xc/programs/Xserver/hw/xfree86/common/xf86Globals.c 2004-03-26 18:29:40.000000000
-0500
@@ -215,6 +215,7 @@
#endif
PropertyPtr *xf86RegisteredPropertiesTable = NULL;
Bool xf86inSuspend = FALSE;
+PciBusId xf86IsolateDevice;
#ifdef DLOPEN_HACK
/*
diff -urN xc/programs/Xserver/hw/xfree86/common~/xf86Init.c
xc/programs/Xserver/hw/xfree86/common/xf86Init.c
--- xc/programs/Xserver/hw/xfree86/common~/xf86Init.c 2004-03-26 18:29:19.000000000 -0500
+++ xc/programs/Xserver/hw/xfree86/common/xf86Init.c 2004-03-26 19:17:21.000000000 -0500
@@ -1590,6 +1590,25 @@
xf86AllowMouseOpenFail = TRUE;
return 1;
}
+ if (!strcmp(argv[i], "-isolateDevice"))
+ {
+ int bus, device, func;
+ if (++i >= argc)
+ return 0;
+ if (strncmp(argv[i], "PCI:", 4)) {
+ ErrorF("Bus types other than PCI not yet isolable\n");
+ return 0;
+ }
+ if (sscanf(argv[i], "PCI:%d:%d:%d", &bus, &device, &func) == 3)
{
+ xf86IsolateDevice.bus = bus;
+ xf86IsolateDevice.device = device;
+ xf86IsolateDevice.func = func;
+ return 2;
+ } else {
+ ErrorF("Invalid isolated device specifiation\n");
+ return 0;
+ }
+ }
/* OS-specific processing */
return xf86ProcessArgument(argc, argv, i);
}
@@ -1650,6 +1669,7 @@
#endif
ErrorF("-bestRefresh choose modes with the best refresh rate\n");
ErrorF("-ignoreABI make module ABI mismatches non-fatal\n");
+ ErrorF("-isolateDevice bus_id restrict device resets to bus_id (PCI
only)\n");
ErrorF("-version show the server version\n");
/* OS-specific usage */
xf86UseMsg();
diff -urN xc/programs/Xserver/hw/xfree86/common~/xf86Priv.h
xc/programs/Xserver/hw/xfree86/common/xf86Priv.h
--- xc/programs/Xserver/hw/xfree86/common~/xf86Priv.h 2004-03-26 18:29:19.000000000 -0500
+++ xc/programs/Xserver/hw/xfree86/common/xf86Priv.h 2004-03-26 18:29:40.000000000 -0500
@@ -53,6 +53,7 @@
extern Gamma xf86Gamma;
extern char *xf86ServerName;
extern Bool xf86ShowUnresolved;
+extern PciBusId xf86IsolateDevice;
/* Other parameters */
diff -urN xc/programs/Xserver/hw/xfree86/common~/xf86pciBus.c
xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c
--- xc/programs/Xserver/hw/xfree86/common~/xf86pciBus.c 2004-03-26 18:29:19.000000000
-0500
+++ xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c 2004-03-26 19:04:03.000000000
-0500
@@ -160,7 +160,10 @@
int num = 0;
pciVideoPtr info;
Bool mem64 = FALSE;
+ int DoIsolateDeviceCheck = 0;
+ if (xf86IsolateDevice.bus || xf86IsolateDevice.device || xf86IsolateDevice.func)
+ DoIsolateDeviceCheck = 1;
pcrpp = xf86PciInfo = xf86scanpci(0);
getPciClassFlags(pcrpp);
@@ -182,7 +185,11 @@
subclass = pcrp->pci_sub_class;
}
- if (PCIINFOCLASSES(baseclass, subclass)) {
+ if (PCIINFOCLASSES(baseclass, subclass) &&
+ (DoIsolateDeviceCheck ?
+ (xf86IsolateDevice.bus == pcrp->busnum &&
+ xf86IsolateDevice.device == pcrp->devnum &&
+ xf86IsolateDevice.func == pcrp->funcnum) : 1)) {
num++;
xf86PciVideoInfo = xnfrealloc(xf86PciVideoInfo,
sizeof(pciVideoPtr) * (num + 1));
4:31 p.m.
On Sat, Jul 03, 2004 at 07:23:28PM +0200, Zoltan Boszormenyi wrote:
+.IB bustype : bus : device : function
+(e.g., \(oqPCI:1:0:0\(cq).
Would need fixing to do PCI domains to start with. Otherwise it looks
like stuff that Debian needs to propogate upstream to Xorg and possibly
quite useful indeed.
8:10 p.m.
On Sat, 3 Jul 2004, Alan Cox wrote:
Does anything actually stop you removing the x86-64 mozilla and
installing the x86-32 one with FC2. I've not tried this but can't
see any obvious reason to fail
You'll need to install many iX86 RPMs, mostly for libs obviously,
many of which overwrite files belonging to the x86_64 versions of
those RPMs. Mostly documentation and headers admittedly, not a big
deal, but some binaries too, which is annoying. (eg
/usr/sbin/iconvconfig in glibc RPM).
Why on earth weren't /(usr)?/bin64 directories created for the FC2
x86_64 port for x86_64 binaries to be installed to? ;) PATH is far
easier to manipulate than all those preexisting RPMs. (hindsight
20/20 possibly).
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam(a)dishone.st
Fortune:
The MGs ran out of gas.
1:20 a.m.
Am So, den 18.07.2004 um 2:10 Uhr +0100 schrieb Paul Jakma:
On Sat, 3 Jul 2004, Alan Cox wrote:
> Does anything actually stop you removing the x86-64 mozilla and
> installing the x86-32 one with FC2. I've not tried this but can't
> see any obvious reason to fail
You'll need to install many iX86 RPMs, mostly for libs obviously,
???
For Firefox (32bit) from fedora.us I needed no special libs from iX86 on
x86_64. But Galeon was a real problem and I don't know if mozilla is
that easy. Installing a second mozilla from the mozilla.org precompiled
tar File should be easy (does it still exists?).
many of which overwrite files belonging to the x86_64 versions of
those RPMs. Mostly documentation and headers admittedly, not a big
deal, but some binaries too, which is annoying. (eg
/usr/sbin/iconvconfig in glibc RPM).
Why on earth weren't /(usr)?/bin64 directories created for the FC2
x86_64 port for x86_64 binaries to be installed to? ;) PATH is far
easier to manipulate than all those preexisting RPMs. (hindsight
20/20 possibly).
Yes, often, this is annoying. QT had such a problem also IIRC. Was hard
to get a 32bit xine run on an 64bit FC2 (now there are 64bit xine
available at livna.org this is easier again)... But I don't think /usr/
bin64 or something like that is specified somewhere (LSB)? Maybe this
could be solved by
/usr/bin/qtconfig-32
/usr/bin/qtconfig-64
and a script or link that points to the right Version?
CU
thl
12:30 p.m.
On Sun, 18 Jul 2004, Thorsten Leemhuis wrote:
For Firefox (32bit) from fedora.us I needed no special libs from
iX86 on x86_64.
You'd be mistaken. It will need a whole bunch of i.86 libs: glibc,
various X related libraries, freetype, various GTK related libs,
libstdc++.
These ix86 RPMs come on the CDs admittedly (or are, strangely,
located in the x86_64 arch RPM directory on fedora.us), and are
installed by default but they're still i.86. The problem is that many
many of these RPMs contain non-arch-specific files. Maybe yum uses
--nodoc and --prefix when installing them, but i doubt it. The real
problem though is where you need or want to install both i386 and
x86_64 versions of an RPM or library RPMs that install binaries to
(/usr)?/bin.
Yes, often, this is annoying. QT had such a problem also IIRC. Was
hard
to get a 32bit xine run on an 64bit FC2 (now there are 64bit xine
available at livna.org this is easier again)... But I don't think /usr/
bin64 or something like that is specified somewhere (LSB)? Maybe this
could be solved by
/usr/bin/qtconfig-32
/usr/bin/qtconfig-64
and a script or link that points to the right Version?
bin64 is the only sane way really.
CU
thl
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam(a)dishone.st
Fortune:
186,282 miles per second:
It isn't just a good idea, it's the law!
12:36 p.m.
On Mon, 2004-07-19 at 18:30 +0100, Paul Jakma wrote:
bin64 is the only sane way really.
Except that anything that ends up with different paths for binaries
isn't exactly sane ;) Sure, you get them both installed, but switching
between them is impossible (not to mention problems with things like
"what does the menu item for gedit launch?")
Jeremy
6:25 p.m.
On Mon, 19 Jul 2004, Jeremy Katz wrote:
Except that anything that ends up with different paths for binaries
isn't exactly sane ;)
Well, it's slightly less insane than the alternative, which is to
have both i386 and x86_64 RPMs install binaries to the same
directory. Given that the idea (i guess) was to allow installation of
i386 RPMs with the minimum of pain (ie not having to go back and
modify all i386 RPMs presumably), x86_64 I think possibly should have
gone with bin64 directories. It would have avoided the
glibc/gcc/binutils/etc.. i386/x86_64 problems where both RPMs wish to
install binaries to .../bin.
I havnt yet managed to get x86_64 RPM gcc package to build -m32
binaries without installing conflicting RPMs, and in using yum to
install the needed i386 packages i ended up with quite a few i386
binaries in my bin/ directories that previously had been x86_64.
Sure, you get them both installed, but switching between them is
impossible (not to mention problems with things like "what does the
menu item for gedit launch?")
Well, that'd be determined by PATH surely, it would even allow one to
express a preference for i386 vs x86_64. How do i install both 32 and
64 bit versions of binaries?
I agree it's ugly, but it's less worse (IMHO) to have bin32 (which
wouldnt work for existing i386 RPMs i guess) or else bin64 for a
multiarch system, and guarantees i386 and x86_64 packages wont
clobber each other (yum and rpm at moment are quite happy to allow
i386 packages to clobber x86_64).
My preference in an ideal world would be for bin/, lib/ simply to be
defined as always being native, maybe having a /usr/$ARCH/{bin,lib}
directory scheme for i386 ABI stuff (ARCH = i386 or ia32, whatever
people prefer.) or alternatively to fix up all the RPMs so that
config files and docs are in seperate RPMs from libraries which
should be in seperate RPMs from binaries and make rpm and/or yum not
allow RPMs to clobber each other's files, regardless of arch. (the
latter approach still wouldnt allow me to install both 32 and 64
versions of software though).
I dont know the answer exactly, but the current situation is
annoying.
Jeremy
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam(a)dishone.st
Fortune:
This life is a test. It is only a test. Had this been an actual life, you
would have received further instructions as to what to do and where to go.
12:54 p.m.
Am Mo, den 19.07.2004 um 18:30 Uhr +0100 schrieb Paul Jakma:
On Sun, 18 Jul 2004, Thorsten Leemhuis wrote:
> For Firefox (32bit) from fedora.us I needed no special libs from
> iX86 on x86_64.
You'd be mistaken. It will need a whole bunch of i.86 libs: glibc,
various X related libraries, freetype, various GTK related libs,
libstdc++.
Maybe I should have laid out my meaning of "special" here a bit more
exactly. We mean the same ;-)
[...]
> Yes, often, this is annoying. QT had such a problem also IIRC. Was hard
> to get a 32bit xine run on an 64bit FC2 (now there are 64bit xine
> available at livna.org this is easier again)... But I don't think /usr/
> bin64 or something like that is specified somewhere (LSB)? Maybe this
> could be solved by
> /usr/bin/qtconfig-32
> /usr/bin/qtconfig-64
> and a script or link that points to the right Version?
bin64 is the only sane way really.
Is it specified somewhere or is it you opinion? /usr/lib64 is specified
AFAIK and also used by other distros.
/usr/bin64 is not and nobody uses it until now (both AFAIK) -- google
only returns 5 results. One of them:
http://lists.debian.org/debian-amd64/2003/11/msg00015.html
I think nobody really want a special fedora(-island)-solution in this
area, or? I don't want one...
--
Thorsten Leemhuis <fedora(a)leemhuis.info>
7:17 p.m.
On Mon, 19 Jul 2004, Thorsten Leemhuis wrote:
Is it specified somewhere or is it you opinion?
My opinion, given that there is a huge body of existing RPMs out
there for i386 and they're unlikely to be going away, and i'd like to
be able to install them without fear of overwriting x86_64 binaries.
Shifting x86_64 to bin64 would be one line in .rpmmacros and an
overnight rebuild of the x86_64 RPMS. RedHat almost certainly have
the build system in place to do this overnight. Punting i386 RPMs to
bin32 directories OTOH would be almost impossible. (paths in cpio
RPMs, huge body of existing i386 RPMs scattered around net that
install to bin). Ie, bin64 is the easiest answer, though i agree it's
not the prettiest, but less ugly than what we have now. See below.
You could fix rpm to not clobber, but then how do you install either
bad packages that contain binaries in lib related packages (eg glibc,
undoubtedly others) or simply dont have a -lib package or install
both i386 and x86_64 versions of software?
/usr/bin64 is not and nobody uses it until now (both AFAIK) --
google only returns 5 results. One of them:
http://lists.debian.org/debian-amd64/2003/11/msg00015.html
I think nobody really want a special fedora(-island)-solution in this
area, or? I don't want one...
Well, the king of ABI changes, IRIX on MIPS, used /usr/{bin/lib} for
native (ie n32 for any recent IRIX) and then /usr/$ABI/ for other
ABIs such as o32 (the deprecated 32bit MIPS ABI) and n64 (64bit).
Packages potentially would contain executable and shared binary
objects for multiple ABIs, and you could choose which ABIs to
install, eg mozilla package might contain sub-packages for docs,
config, n32 libs, n64 libs, n64 binaries and n32 binaries, you could
install one of n32 or n64, the other or both, or install the n32
binaries and libs and just the n64 libs (for compiling n64 and
resolving link references against).
It worked quite well and is useful as it allows you to compile for
ABIs even if the system does not support it (eg n64 on O2 systems, as
you could easily install n64 bits), or to install o32 versions of
software (eg because o32 is all that was available, or to install o32
libraries from a package to compile against).
I dont know what the answer is, all I'm saying is:
- i386 is going to be around a long time, hence i386 packages too,
and i'm guessing Fedora would like to support these packages with
the minimum of fuss (the entire reason why we have lib64).
- Allowing i.86 and x86-64 packages to clobber each other's files is
bad
- It should be possible to compile i386 packages on x86-64
- I dont know if x86_64 supports it, but if it does, it might be nice
to be able to support x86_64 native binaries that use 32bit
addressing (ie able to access the extra registers and the 64bit R..
forms of x86_64 registers, but using 32bit addressing). I'm
guessing x86_64 supports this, but that there is no ABI defined for
it, and that there possibly never will be, but such an ABI
potentially could be useful.
- it would be nice to be able to install both i386 and x86-64
architecture binaries alongside each other. (for testing if nothing
else).
the current situation is annoying, $something needs to be done. Be
it:
- a drive to fix up packages and split up non-arch-specific,
libraries and binaries into seperate packages and have RPM refuse to
clobber files (by default) no matter what, as it currently does for
files belonging to different packages of same architecture.
This would do for being able to install all the bits needed to
support i386 binaries and be able to compile i386 versions of
software. And I get impression it's already ongoing.
This would not address installing the different arch versions of
essentially the same binaries.
- Define seperate directories for different ABIs.
Eg, let /bin and /lib be native. And lib/$ABI or /usr/$ABI/{bin/lib}
or whatever. PATH and LD_LIBRARY_PATH exist for a reason ;)
This essentially would allow complete flexibility, including for
support of future ABIs (eg an ILP32 but otherwise x86-64 long mode
using ABI, with 64bit doubles.)
It would though require some support from rpm. At present the cpio
archives in RPM packages contain the full path, the path would need
to be abstracted somewhat to allow rpm to install binaries and libs
to the correct directories for the architecture, to allow i386 to be
installed.
One could avoid this though by defining /bin and /lib to be i386 and
/bin64 and /lib64 for x86-64, but i agree that is ugly, as I said
above. However it would allow x86-64 to stay compatible with the
fairly large body of 3rd party software packaged for Fedora i386. bin
as native and bin32 or /usr/i386 for i386 is slightly cleaner, but a
huge compatibility problem. bin64 is ugly, but will work fine and
allow perfect compatibility with i.86. Take your pick.
anyway, the current situation is annoying. Annoying enough to make me
switch to the first distro that does multiarch correctly, or even
just gets gcc -m32 right without having to clobber files. ;)
But i'd prefer to help fix it in FC, whatever the right way may be.
regards,
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam(a)dishone.st
Fortune:
Pushing 30 is exercise enough.
11:29 p.m.
On Tue, 20 Jul 2004 10:17, Paul Jakma <paul(a)dishone.st> wrote:
On Mon, 19 Jul 2004, Thorsten Leemhuis wrote:
> Is it specified somewhere or is it you opinion?
My opinion, given that there is a huge body of existing RPMs out
there for i386 and they're unlikely to be going away, and i'd like to
be able to install them without fear of overwriting x86_64 binaries.
Why would you want to have both i386 and AMD64 binaries installed at the same
time?
Surely if you have a 64bit version of a program then the correct thing to do
is just not install the 32bit version!
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7:26 a.m.
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
A groupware suite please (also very much needed for RHEL4 IMHO).
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
7:46 a.m.
On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote:
- Remote desktops using VNC
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
And what about NX <http://www.nomachine.com/>;, of which the server
part is now also Open Source?
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
10:53 a.m.
On Fri, 2004-07-02 at 00:01, Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
CVS repository for Fedora Core, please. Or at least change the
Participate webpage to say "This is intended to be available by the
release of Fedora Core 3".
josh
9:55 a.m.
On Jul 2, 2004, Bill Nottingham <notting(a)redhat.com> wrote:
- Remote desktops using VNC
http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html
Are we going to have client-side counterparts to that, such that you
don't have to log in locally and start a local desktop to compete with
the remote desktop for virtual desktop switching keystrokes and such
stuff?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
1:35 p.m.
I'm sure there's other stuff people would like to see. What
sorts
of things?
NX instead of VNC.... ( http://www.nomachine.com/download.php )
2:02 p.m.
On Sun, Jul 04, 2004 at 08:35:26PM +0200, Arjan van de Ven wrote:
> I'm sure there's other stuff people would like to see. What sorts
> of things?
NX instead of VNC.... ( http://www.nomachine.com/download.php )
Commercial ware? How does that fit in with the goals of Fedora?
Or are you suggesting that Red Hat buy them out and Open Source the
technology?
2:09 p.m.
Charles R. Anderson wrote:
On Sun, Jul 04, 2004 at 08:35:26PM +0200, Arjan van de Ven wrote:
>>I'm sure there's other stuff people would like to see. What sorts
>>of things?
>
>NX instead of VNC.... ( http://www.nomachine.com/download.php )
Commercial ware? How does that fit in with the goals of Fedora?
Or are you suggesting that Red Hat buy them out and Open Source the
technology?
FYI, NX is GPL. Check the download page, bottom-right.
dex
2:23 p.m.
On Mon, Jul 05, 2004 at 03:09:36AM +0800, Dexter Ang wrote:
FYI, NX is GPL. Check the download page, bottom-right.
Why the License: Commercial tag? Why the "free evaluation" version?
Are there commercial components? I do not see the COPYING file
included with the binaries, which AFAIK is a requirement of the GPL.
3:09 p.m.
On Sun, Jul 04, 2004 at 03:23:12PM -0400, Charles R. Anderson wrote:
On Mon, Jul 05, 2004 at 03:09:36AM +0800, Dexter Ang wrote:
> FYI, NX is GPL. Check the download page, bottom-right.
Why the License: Commercial tag? Why the "free evaluation" version?
Are there commercial components? I do not see the COPYING file
included with the binaries, which AFAIK is a requirement of the GPL.
The core software (client *and* server) is Open Source, I think the
server part was GPL'ed very recently (two weeks ago or so).
This does not mean that all of the software you see there is Open
Source. Some of the "sugar" included in the binaries is not Open
Source, so it is is not strange that you don't see a COPYING.
Furthermore, it might be dual-licensed (don't know if this is the
case here), so that the commercially packaged software does not
need to include the GPL.
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
3:33 p.m.
On Sun, Jul 04, 2004 at 08:35:26PM +0200, Arjan van de Ven wrote:
> I'm sure there's other stuff people would like to see.
What sorts
> of things?
NX instead of VNC.... ( http://www.nomachine.com/download.php )
NX is lacking clients, NX doesn't work well with high latency links.
Its certainly not an instead of IMHO.
12:21 p.m.
New subject: GFS in FC3? was: Fedora Core 3
Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
GFS!
Fedora is for the latest Open Source technologies, and I don't know what
qualifies more than GFS.
Want testers? You've got 'em right here in fedora.
8:08 p.m.
New subject: GFS in FC3? was: Fedora Core 3
Request seconded!
Ohh, and does anybody know if Oracle's OCFS is being ported to the 2.6
kernel?
checking for directory with kernel source...
/lib/modules/2.6.6-1.435.2.3/build
checking for kernel version... 2.6.6-1.435.2.3
configure: error: This module only supports kernel version 2.4.x
Mike Fedyk wrote:
Bill Nottingham wrote:
> I'm sure there's other stuff people would like to see. What sorts
> of things?
>
GFS!
Fedora is for the latest Open Source technologies, and I don't know
what qualifies more than GFS.
Want testers? You've got 'em right here in fedora.
9:34 p.m.
New subject: GFS in FC3? was: Fedora Core 3
On Tuesday 06 July 2004 21:08, Naoki wrote:
Request seconded!
Make that at least 3 :-)
GFS and the whole cluster suite RH just released under the GPL would be great
- it's one of those features that proprietary unix vendors charge the big
bucks for...
Peter.
--
http://www.dealrover.com
3:33 a.m.
New subject: GFS in FC3? was: Fedora Core 3
Le mer 07/07/2004 à 04:34, Peter Arremann a écrit :
On Tuesday 06 July 2004 21:08, Naoki wrote:
> Request seconded!
Make that at least 3 :-)
GFS and the whole cluster suite RH just released under the GPL would be great
Cluster Project Page :
http://sources.redhat.com/cluster/
GFS rpm for FC2 :
http://www2.wantstofly.org/gfs/
- it's one of those features that proprietary unix vendors charge
the big
bucks for...
Peter.
--
http://www.dealrover.com
1:39 p.m.
Bill Nottingham wrote:
I'm sure there's other stuff people would like to see. What
sorts
of things?
I was just thinking of this last night. LKCD!
I have a system at home, that I'm still running 2.6.5 on because it
always crashes with one of the screen savers.
The problem is that it doesn't crash in non-3d mode so I can never see
an oops (or even know if there is one!). :(
LKCD could save the oops to a floppy, or several other outputs IIRC for
those who don't have anything to connect to a serial console.
3:32 p.m.
On Mon, Jul 12, 2004 at 11:39:18AM -0700, Mike Fedyk wrote:
The problem is that it doesn't crash in non-3d mode so I can
never see
an oops (or even know if there is one!). :(
If you can then login remotely and just run the screensavers one by one
from the screensavers directory till it explodes. If you have a matrox
Gx00 card its a known bug
5:20 p.m.
Alan Cox wrote:
On Mon, Jul 12, 2004 at 11:39:18AM -0700, Mike Fedyk wrote:
>The problem is that it doesn't crash in non-3d mode so I can never see
>an oops (or even know if there is one!). :(
>
>
If you can then login remotely and just run the screensavers one by one
from the screensavers directory till it explodes.
How will I get an oops if I do that? The screen will have the 3d screen
saver on it, and no text oops...
The keyboard locks completely, and sysrq-s-u-b doesn't respond either.
Is sysrq in fc2 kernels?
If you have a matrox
Gx00 card its a known bug
It's an ATI Rage 128.
5:22 p.m.
On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote:
How will I get an oops if I do that? The screen will have the 3d
screen
saver on it, and no text oops...
You'll know which screensaver
>If you have a matrox
>Gx00 card its a known bug
>
It's an ATI Rage 128.
Does it occur with the update kernel or with the i586 kernel ?
6:01 p.m.
Alan Cox wrote:
On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote:
>How will I get an oops if I do that? The screen will have the 3d screen
>saver on it, and no text oops...
>
>
You'll know which screensaver
I know which screen saver, just not the name yet, have to go through the
list...
>>If you have a matrox
>>Gx00 card its a known bug
>>
>>
>>
>It's an ATI Rage 128.
>
>
Does it occur with the update kernel or with the i586 kernel ?
I have run three fc2 kernels on this machine, two 2.6.6 based, and one
2.6.5 based (well it's really 2.6.x + 1 rc, but whatever) and the only
one that doesn't crash overnight is the 2.6.5 kernel.
I'll check what it's optimized for when I get home.
Mike
6:43 p.m.
On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote:
Alan Cox wrote:
>If you can then login remotely and just run the screensavers one by one
>from the screensavers directory till it explodes.
>
How will I get an oops if I do that? The screen will have the 3d screen
saver on it, and no text oops...
The keyboard locks completely, and sysrq-s-u-b doesn't respond either.
Is sysrq in fc2 kernels?
Does the network go down too, though? If not, and you're have an ssh
connection into the crashing computer from another computer, then you
will be able to use "dmesg" to view the oops.
-Barry K. Nathan <barryn(a)pobox.com>
6:47 p.m.
Barry K. Nathan wrote:
On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote:
>Alan Cox wrote:
>
>
>
>>If you can then login remotely and just run the screensavers one by one
>>
>>
>>from the screensavers directory till it explodes.
>
>
>How will I get an oops if I do that? The screen will have the 3d screen
>saver on it, and no text oops...
>
>The keyboard locks completely, and sysrq-s-u-b doesn't respond either.
>Is sysrq in fc2 kernels?
>
>
Does the network go down too, though? If not, and you're have an ssh
connection into the crashing computer from another computer, then you
will be able to use "dmesg" to view the oops.
Probably, but I'll let you know.
Mike
7281
days inactive
7299
days old
167 comments
68 participants
participants (68)
-
Adrian Havill -
Alan Cox -
Albert Hawker -
Alexandre Oliva -
Andres Petralli -
Arjan van de Ven -
Barry K. Nathan -
Ben Steeves -
Bill Nottingham -
Bryan Clark -
Chris Adams -
Chris Blizzard -
Chuck Anderson -
Colin Charles -
Cristian Gafton -
Dan Williams -
David Zeuthen -
Denis Leroy -
Dennis Gilmore -
Dexter Ang -
Doncho N. Gunchev -
dragoran -
Elliot Lee -
Florian La Roche -
Féliciano Matias -
George J Karabin -
Greg KH -
Gregory Leblanc -
Harald Hoyer -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
John Mizell -
Jos Vos -
Josh Boyer -
Kay Sievers -
Kenneth Porter -
Konstantin Ryabitsev -
Leonard den Ottolander -
Luciano Miguel Ferreira Rocha -
Marc Deslauriers -
Marius Andreiana -
Matthew Miller -
Matthias Saou -
Mike Fedyk -
Mike Hearn -
Miloslav Trmač -
Naoki -
Nicolas Mailhot -
Paul Jakma -
Pedro Fernandes Macedo -
Pekka Pietikäinen -
Peter Arremann -
Ricardo Ariel Gorosito -
Ronny Buchmann -
Rui Miguel Silva Seabra -
Russell Coker -
Sam Varshavchik -
Scott Sloan -
seth vidal -
Steven Garrity -
Tarjei Knapstad -
Thorsten Leemhuis -
Tim Waugh -
Tom Diehl -
tony -
Warren Togami -
Zoltan Boszormenyi